RabbitMQ实现消息100%投递的详细设计和测试方案

目标

• 实现一个在相对恶劣的条件下，依旧保证消息百分百投递或消费的消息队列。

存在的挑战及简易方案

• 1.你说百分百投递，万一你mq挂了，怎么投递？
  使用镜像队列
• 2.那要是网络不稳定，消息没有送到exchange或者没有送到queue怎么办？
  conform模式 和 return模式 配合消息重发的线程池重发消息
  • 2.1.消息发送至某一台mq，但是这台mq突然停电，来不及同步到其他镜像队列怎办？
    消息持久化至硬盘，消息重启恢复
  • 2.2.如果消息刚到内存，还没来及固化到硬盘，此时发生故障，导致消息丢失怎么办？
    这次消息是真的丢失了，但是有补偿机制
• 3.消息执行（消费）失败，或者消费后消息没有发送至队列怎办？
  （1）发送消息时，除了发给消费端，还发给了补偿端做消息登记。 （2）消费端消费后，会把消息发送到补偿端进行同步。 （3）补偿机制会在间隔时间内重新发消息到补偿端，获取消息状态，要么重发，要么关闭。
• 4.那万一生产端多发了消息，或者补偿机制多发了消息，怎么保证幂等消费？
  redis分布式锁：Redisson实现消息幂等
• 5.大流量进入mq的时候，来不及消费怎么办？
  mq有削峰填谷的算法
• 6.上述百分百投递保障和单节点相比，对性能影响有多大？
  测试方案: （1）镜像队列在不同宕机条件下的消息可达性测试 （2）单节点和百分百投递队列的性能对比测试。
• 7.消息队列的类是交由spring管理的单例，如何保证在多处引用的时候，不会引起线程安全问题
  将scope改成request