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机来消费消息。
总结：
1. 修复并停掉consumer；
2. 新建个topic，partition是原来的10倍，建临时queue，数是原来的10倍或20倍；
3. 写临时consumer程序，临时征10倍的机去消费数据；
4. 消费完成之后，恢复原先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使信道的式来传输数
评论0