物联网平台Rabbitmq实际应用rabbitMQ的使用场景？消息队列产生严重消息堆积怎么处理？

Posted 2021-09-04 尽力漂亮

文章目录

• 前言
• • rabbitMQ的使用场景
  • 消息队列产生严重消息堆积怎么处理？
  • 如何应对严重消息堆积呢？
  • 例如有订单消息丢了，那就需要找出哪些订单消息丢了，然后重新发到队列。
  • 快速处理海量积压消息
  • 具体问题应用场景：因硬件系统内存不够（C盘内存只有40G），导致现在RabbitMQ里面积压了900多万的队列，数据消费不过来，平台不能正常接收数据。
• 总结

前言

实际场景：
之前平台项目接收器只采用了tcp来接受报文数据，最近结合了下rabbitmq，来提升平台性能，
本文主要介绍：
1.为啥要用rabbitmq，tcp的缺点。
2.rabbtimq用户实际使用过程会遇到的问题 以及如何解决

rabbitMQ的使用场景

1.同步变异步

可以使用线程池解决,但是缺点很明显:要自己实现线程池,并且强耦合 大多数是使用消息队列来解决2.低内聚高耦合:解耦----减少强依赖.
3.流量削峰—秒杀系统通过消息队列设置请求最大值,超过阀值的抛弃或者转到错误界面

4.rabbitmq采用信道通信。不采用tcp直接通信

1).tcp的创建和销毁开销大，创建3次握手，销毁4四次分手
2).高峰时成千上万条的链接会造成资源的巨大浪费，而且操作系统没秒处理tcp的数量也是有数量限制的，必定造成性能瓶颈
3).一条线程一条信道，多条线程多条信道，公用一个tcp连接。一条tcp连接可以容纳无限条信道（硬盘容量足够的话），不会造成性能瓶颈。

消息队列产生严重消息堆积怎么处理？

1. 为什么产生消息堆积？

大多是因为 Consumer 出问题了，没有及时发现，或者故障恢复需要较长的时间，导致大量消息积压在 MQ 中。

2. 消息堆积会有什么后果呢？

2.1 消息被丢弃
例如 RabbitMQ 有一个消息过期时间 TTL，过期的消息会被扔掉，这样消息就彻底没有了。

2.2 磁盘满了
如果堆积量太大，可能导致磁盘空间不足，那么新消息就进不来了。

2.3 海量消息待处理
如果消息没过期，并且磁盘空间也够用，那么就是产生海量消息等待被消费，Consumer 的噩梦。

如何应对严重消息堆积呢？

3.1 消息被丢弃的情况
首先，要实现防止消息过期问题，不应该设置过期时间。

如果就是设置了过期时间，导致了消息丢失，怎么补救呢？

那就只能在夜深人静，趁着访问量最低的时候，写一个临时程序来补消息了。

例如有订单消息丢了，那就需要找出哪些订单消息丢了，然后重新发到队列。

3.2 磁盘不足的情况
系统通常都是有监控的，达到空间阈值时就会发警报，这时就要马上处理了。

例如，在其他机器上创建临时的消息队列，再写一个临时的 Consumer，作为消息的中转，把消息积压队列中的消息取出来，放到临时队列里面去。

快速疏散积压的消息，让磁盘空间恢复正常水平。

快速处理海量积压消息

Consumer 恢复正常之后，面对堆积如山的消息，怎么处理呢？

如何按照之前正常情况处理的话，猴年马月才能消费完，此过程中还有新消息在不断进来。

例如，积压了 100 万条，有 3 个 Consumer，每一个每秒能处理 200 条，3 个 Consumer 每秒一共能处理 600 条。

大概需要一个多小时才能处理完。

这一个多小时又会积压多少新的消息呢？

所以正常处理肯定不行，需要提速。

例如 Kafka，这个消息积压的 Topic 有 3 个 Partition，那最多就能用 3 个 Consumer，所以增加 Consumer 没有用。

还是可以使用临时队列的方式。

新建一个 Topic，设置为 20 个 Partition

Consumer 不再处理业务逻辑了，只负责搬运，把消息放到临时 Topic 中

这 20 个 Partition 可以有 20个 Consumer 了，它们来处理原来的业务逻辑。

这 20 个 Consumer 每秒一共能处理 4000 条了，这样几分钟就可以处理完积压的 100 万条。

这几分钟新来的消息也不会太多，所以很快就可以恢复正常水平，之后，再把整体结构恢复为原来的形式。

---

具体问题应用场景：因硬件系统内存不够（C盘内存只有40G），导致现在RabbitMQ里面积压了900多万的队列，数据消费不过来，平台不能正常接收数据。

操作系统为window系统

解决方案
如果你的 MQ 和 DB 承载的是关键业务，那么与其考虑如何善后，可能更应该关心如何防止它们（全）挂掉。通常的做法就是冗余，好让即使其中一个或多个挂掉也不至于影响整个业务，然后想办法让挂掉的能自动或手动复活。冗余可以有很多级别：

• 在一台服务器上开多个同样的服务，应对一个服务挂了的场景
• 部署多台服务器跑同样的服务，应对一台服务器挂了的场景
• 在同一个地区部署多个机房，应对一个机房停电等场景
• 在多个地区部署机房，应对一个地区的所有机房被摧毁（比如地震）……

目前是另开一台服务器做备用方案，计划先由客户这边把原有的40G磁盘扩容到50G，保证这几天能正常接收数据先。然后下周一开始 先对旧数据库系统做数据备份，备份完成之后，再把原有的服务器做相应的扩容调整，改成linux的操作系统
风险：毕竟是2个系统，会丢失部分数据

---

总结

小结一下，消息积压还是比较麻烦的，最好是提前防范，做好硬件和消息系统的健康监控。如果出现消息丢失，就要人工查找丢失的消息，然后补上。在消费不过来的时候，可以考虑使用临时队列作为中转，提升处理能力。