消息队列 – 大总结

灵魂拷问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、kafka

kafka的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回答。