RabbitMQ的一些总结以及疑问

最新推荐文章于 2023-11-30 21:56:47 发布

小象子

最新推荐文章于 2023-11-30 21:56:47 发布

阅读量241

点赞数

分类专栏： java专栏文章标签： MQ

本文链接：https://blog.csdn.net/weixin_41805792/article/details/102772598

版权

java专栏专栏收录该内容

52 篇文章 0 订阅

订阅专栏

1、上千万条消息在mq中积压了⼏个⼩时还没解决：

1）先修复consumer的问题，确保其恢复消费速度，然后将现有consumer都停掉；
2）新建⼀个topic，partition是原来的10倍，临时建⽴好原先10倍或者20倍的queue数量；
3）然后写⼀个临时的分发数据的consumer程序，这个程序部署上去消费积压的数据；
消费之后不做耗时的处理，直接均匀轮询写⼊临时建⽴好的10倍数量的queue；
4）接着临时征⽤10倍的机器来部署consumer，每⼀批consumer消费⼀个临时queue的数据；
5）这种做法相当于是临时将queue资源和consumer资源扩⼤10倍，以正常的10倍速度来消费数据；
6）等快速消费完积压数据之后，得恢复原先部署架构，重新⽤原先的consumer机器来消费消息。
总结：

修复并停掉consumer；
新建⼀个topic，partition是原来的10倍，建⽴临时queue，数量是原来的10倍或20倍；
写临时consumer程序，临时征⽤10倍的机器去消费数据；
消费完成之后，恢复原先consumer；

2、rabbitmq设置过期时间，部分消息丢失：

采取批量重导⽅法：将丢失的那批数据查询导⼊到mq⾥⾯。
3、RabbitMQ 上的⼀个 queue 中存放的 message 是否有数量限制？
可以认为是⽆限制，因为限制取决于机器的内存，但是消息过多会导致处理效率的下降。
4、分布式部署：
RabbitMQ⽆法容忍不同数据中⼼之间⽹络延迟，但是可以通过3种⽅式实现分布式部署：Federation和Shovel。

5、如何确保消息正确地发送⾄RabbitMQ？

RabbitMQ使⽤发送⽅确认模式，确保消息正确地发送到RabbitMQ。
发送⽅确认模式：将信道设置成confirm模式（发送⽅确认模式），则所有在信道上发布的消息都会被指派⼀个唯⼀的
ID。⼀旦消息被投递到⽬的队列后，或者消息被写⼊磁盘后（可持久化的消息），信道会发送⼀个确认给⽣产者（包含消息唯
⼀ID）。如果RabbitMQ发⽣内部错误从⽽导致消息丢失，会发送⼀条nack（not acknowledged，未确认）消息。
发送⽅确认模式是异步的，⽣产者应⽤程序在等待确认的同时，可以继续发送消息。当确认消息到达⽣产者应⽤程序，⽣
产者应⽤程序的回调⽅法就会被触发来处理确认消息。

6、如何确保消息接收⽅消费了消息？

接收⽅消息确认机制：消费者接收每⼀条消息后都必须进⾏确认（消息接收和消息确认是两个不同操作）。只有消费者确
认了消息，RabbitMQ才能安全地把消息从队列中删除。
这⾥并没有⽤到超时机制，RabbitMQ仅通过Consumer的连接中断来确认是否需要重新发送消息。也就是说，只要连接不
中断，RabbitMQ给了Consumer⾜够⻓的时间来处理消息。
特殊情况：
1、如果消费者接收到消息，在确认之前断开了连接或取消订阅，RabbitMQ会认为消息没有被分发，然后重新分发给下⼀
个订阅的消费者。（可能存在消息重复消费的隐患，需要根据bizId去重）
2、如果消费者接收到消息却没有确认消息，连接也未断开，则RabbitMQ认为该消费者繁忙，将不会给该消费者分发更多
的消息。

7、如何避免消息重复投递或重复消费？

在消息⽣产时，MQ内部针对每条⽣产者发送的消息⽣成⼀个inner-msg-id，作为去重和幂等的依据（消息投递失败并重
传），避免重复的消息进⼊队列；在消息消费时，要求消息体中必须要有⼀个bizId（对于同⼀业务全局唯⼀，如⽀付ID、订单
ID、帖⼦ID等）作为去重和幂等的依据，避免同⼀条消息被重复消费。

8、消息基于什么传输？

由于TCP连接的创建和销毁开销较⼤，且并发数受系统资源限制，会造成性能瓶颈。RabbitMQ使⽤信道的⽅式来传输数据。信道是建⽴在真实的TCP连接内的虚拟连接，且每条TCP连接上的信道数量没有限制。
1、RabbitMQ采⽤类似NIO（Non-blocking I/O）做法，选择TCP连接复⽤，不仅可以减少性能开销，同时也便于管理。
2、每个线程把持⼀个信道，所以信道服⽤了Connection的TCP连接。同时RabbitMQ可以确保每个线程的私密性，就像拥有
独⽴的连接⼀样。

9、如何确保消息不丢失？

消息持久化的前提是：将交换器/队列的durable属性设置为true，表示交换器/队列是持久交换器/队列，在服务器崩溃或重
启之后不需要重新创建交换器/队列（交换器/队列会⾃动创建）。
如果消息想要从Rabbit崩溃中恢复，那么消息必须：
1、在消息发布前，通过把它的 “投递模式” 选项设置为2（持久）来把消息标记成持久化
2、将消息发送到持久交换器
3、消息到达持久队列
RabbitMQ确保持久性消息能从服务器重启中恢复的⽅式是，将它们写⼊磁盘上的⼀个持久化⽇志⽂件，当发布⼀条持久性消息到持久交换器上时，Rabbit会在消息提交到⽇志⽂件后才发送响应（如果消息路由到了⾮持久队列，它会⾃动从持久化⽇志中移除）。⼀旦消费者从持久队列中消费了⼀条持久化消息，RabbitMQ会在持久化⽇志中把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前RabbitMQ重启，那么Rabbit会⾃动重建交换器和队列（以及绑定），并重播持久化⽇志⽂件中的消息到合适的队列或者交换器上。