RabbitMQ 面试题

9、如何确保消息不丢失？
消息持久化，当然前提是队列必须持久化
RabbitMQ 确保持久性消息能从服务器重启中恢复的方式是，将它们写入磁盘上
的一个持久化日志文件，当发布一条持久性消息到持久交换器上时，Rabbit 会在
消息提交到日志文件后才发送响应。
一旦消费者从持久队列中消费了一条持久化消息，RabbitMQ 会在持久化日志中
把这条消息标记为等待垃圾收集。如果持久化消息在被消费之前 RabbitMQ 重启，
那么 Rabbit 会自动重建交换器和队列（以及绑定），并重新发布持久化日志文件
中的消息到合适的队列。
10、使用 RabbitMQ 有什么好处？
1、服务间高度解耦
2、异步通信性能高
3、流量削峰
11、RabbitMQ 的集群
镜像集群模式
你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，然后
每次你写消息到 queue 的时候，都会自动把消息到多个实例的 queue 里进行消息
同步。
好处在于，你任何一个机器宕机了，没事儿，别的机器都可以用。坏处在于，第
一，这个性能开销也太大了吧，消息同步所有机器，导致网络带宽压力和消耗很
重！第二，这么玩儿，就没有扩展性可言了，如果某个 queue 负载很重，你加机
器，新增的机器也包含了这个 queue 的所有数据，并没有办法线性扩展你的 queue
12、mq 的缺点
系统可用性降低
系统引入的外部依赖越多，越容易挂掉，本来你就是 A 系统调用 BCD 三个系统的
接口就好了，人 ABCD 四个系统好好的，没啥问题，你偏加个 MQ 进来，万一
MQ 挂了咋整？MQ 挂了，整套系统崩溃了，你不就完了么。
系统复杂性提高
硬生生加个 MQ 进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？
怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已
一致性问题
A 系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要
是 BCD 三个系统那里，BD 两个系统写库成功了，结果 C 系统写库失败了，咋整？
你这数据就不一致了。
所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对
它带来的坏处做各种额外的技术方案和架构来规避掉，最好之后，你会发现，妈
呀，系统复杂度提升了一个数量级，也许是复杂了 10 倍。但是关键时刻，用，还
是得用的