消息队列之九问九答

问题1 为什么要用消息队列呀？

答：如下图所示，外呼系统需要将外呼结果发送给业务系统，如果采用rpc的调用方式；则带来的后果， 首先，1、外呼系统与业务系统严重耦合，多个业务系统需要外呼系统传输数据，如果有接口调用的方式，那无论是接入新的业务还是撤掉业务，都需要改动代码；

2、如果业务系统挂掉/访问超时，要保证不能影响其他业务系统；所以：需要利用消息队列解耦，这样做的好处：外呼系统和业务系统解耦，业务系统有需要，消费mq即可 外呼系统也无需关注业务系统的消费情况啦其次，如果采用rpc调用方式（同步），则总体耗时 = 在外呼系统的耗时 + 在审核系统的耗时 + 在天网的耗时。。总体耗时过长， 使用mq异步化之后，性能优化啦，总耗时 = 外呼系统的耗时 + 发送mq的耗时。

再次，如果不用mq，高峰期的时候，大量请求打入系统，万一系统的处理逻辑涉及到数据库，那么很容易挂掉，高峰期一过，系统压力又大大减小。<小知识，一般的mysql，一般能扛到每秒2000个请求> 所以使用mq削峰，系统慢慢从mq中拉取数据作处理，保证高峰期系统也不会挂掉，虽然有可能堆积消息，但是高峰期一过，请求就会被快速处理掉的。

问题2 消息队列的优点和缺点？

优点：如1所说，可以解耦、低耗时、削峰 缺点：

（1）、系统的可用性降低，mq一旦挂掉，提供者没办法发送消息了，消费者也无法接收到数据了

（2）、系统的复杂性提高，引入了mq，就要考虑消息重复、消息幂等、消息丢失、消息延迟、消息堆积、消息顺序错乱等问题 

（3）、系统的一致性问题，如果消费失败，那么有可能导致提供者与消费者状态不一致的问题

问题3 消息队列都有哪些类型，分别有什么优缺点呀？

（1）、常见的消息队列有 kafaka、activemq、rabbitmq、rocketmq （2）、消息队列的比较

问题4 如何保证消息队列的高可用呀？

（1）rabbitmq 非分布式 a、单机模式，只有一台机器。b、普通集群模式 rabbitmq 有三台机器，只有一台机器存了元数据和所有数据，如果有消费者需要消费数据，访问了a或c，那么a或c就会根据其元数据路由到b机器上。优点：可随便路由到某台机器，皆可访问；缺点：集群内部产生大量的数据传输，且万一某一个挂掉，则无法找回数据。c、镜像集群模式 在管理控制台新增一个策略，制定所有节点同步数据创建queue的时候，都选择该策略。每个rabbitmq节点上都有queue 元数据 和 所有数据。这样，生产者往queue里写数据，rabbitmq就会自动同步到其他节点上去，每个节点都有queue的完整镜像，消费者可从任一一个节点去消费，如果出现宕机，可以从其他节点去获取数据 

（2）rocketmq 分布式 采用 多master多slave模式 同步双写模式 

（3）kafka：纯分布式架构的mq。每个topic分为不同的partion，放在不同的机器上，所以每一台机器上都有部分topic数据，每个partion只会被一个消费者消费。高可用保证：replica 副本机制 每份数据都会有多个副本，会选举一个为leader，其他为follow，对于同一个topic下的partion，只有leader才可以提供读写。如果leader宕机，kafka会感知到，那么会重新选举新的follow为leader。

问题5 如何保证消息队列的幂等性？

幂等性：同样的数据只消费一次。为什么会发生消息重复消费的情况？如Kafka，如果在消费者准备提交的时候，被重启了，那么kafka是不知道消费者准确的消费到了哪条数据，就有可能会出现重复消费。总之，就是如果mq和消费者的信息不对等了，就会出现这个问题咯。那么，如何解决呢？1、如果是库表类的操作，用业务主键来去重；2、或者可以利用redis、内存等，用一个卫衣标识来保证消息的幂等性。例如：外呼系统中，业务系统拿到结果要落库表，可以用callid作为幂等性的保证。

问题6 如何保证消息的可靠传输？

1、rabbitmq 生产者->rabbitmq->消费者 可能会丢消息的情况：a、消息因为网络传输等原因没到mq就丢了。b、mq内部出错了，没保存下来。c、mq保存下来了，还没消费呢，mq挂了，被丢了。d、消费者消费到了数据，还没来得及处理，挂掉了，但是mq以为消费完了。如何解决呢？a的解决方案1：rabbitmq支持事物，生产者发消息之前开启一个事务，如果收到异常，就证明没发送成功，那么可以回滚，再重试发送；缺点是同步机制，需要等结果，比较耗时。a的解决方案2：开启confirm模式，生产者提供回调接口，mq接收到了消息去回调该接口通知接收是否成功。b和c的解决方案：把消息持久化到磁盘上。queue设置成持久化，消息的delivery mode 设置成2 d的解决方案：关闭消费者的autoack，不再自动告诉mq，OK了，而是等处理完了再告诉。

2、kafka 生产者->kafka->消费者 a、消费端弄丢数据，kafka自动提交offset，让kafka以为消费完了。解决方案，放弃自动提交，处理完之后再提交。b、kafka本身丢数据。设置四个参数。topic 的 replication factor > 1 ，每个partion至少有2个副本 min.insync.replicas >1 , 要求每一个leader至少有一个follow跟他保持联系 produce ack=all 每条数据必须写入到副本之后，才算写成功 retires = max（很大的值），如果写入失败，就进入无限重试，保证leader和follow切换时，不会丢失数据。

一般的开发过程，只要接入了mq，都会写一个补单脚本做对账。

问题7 如何保证消息的顺序性？

1、rabbitmq 为何会消息错乱呢？一个queue的数据被多个消费者消费，这时候就有可能会出现顺序错乱的情况。解决方案，多创造几个queue，把需要保证顺序的数据放在一个queue里，每一个queue只有一个消费者。2、kafkakafka的partion只能有一个消费者，但是如果消费者内部是多线程并发处理的，那么是可能会出现顺序错乱的问题。

把需要保证顺序的数据放在内存队列里，然后每个线程处理一个队列，这样就可以保证顺序执行啦。

问题8 如何解决消息队列的延时以及过期失效问题呀？

快速扩容呀。具体的方案可参考：（1）、新建一个topic，创建10倍的partion， （2）、消费者消费到数据之后，啥都不干，就只往新的topic里写数据， （3）、申请partion数量的机器，去处理里面的数据。

如果大量积压，又无法立刻解决的话，就开启丢消息的模式，后续低峰期的时候，把数据补偿回来。

问题9  如何设计消息队列中间件？

1、可伸缩性，支持快速扩容，增加吞吐量和容量。可参考kafka的设计方案 broker -> topic -> partion，如果需要扩容，增加partion和机器即可。

2、落磁盘，防止数据丢失。

3、可用性，leader和follow的模式

4、保证数据的0丢失。可结合灵魂拷问1-8回答。

原文链接：https://blog.csdn.net/cfy1024/article/details/105753042

更多信息请关注公众号：「软件老王」，关注不迷路，软件老王和他的IT朋友们，分享一些他们的技术见解和生活故事。