MQ架构细节

问：什么时候用mq

1 解耦上游和下游时

2 上游做完逻辑之后，后面的动作不需要等待结果的返回

3 高并发时

4 数据依赖时，比如任务1的结果，是任务2需要的数据，任务3需要任务2支行完成的结果数据

5 上游关心结果，但是结果执行的时间比较长时。如图

 

 需要向公网发起请求，上游调用微信发起支付，调用成功之后程序就结束，微信这边收到钱之后，会主动返回结果给统一网关，统一网关把消息发送到mq，上游在消息mq做对应的处理

这里特别注意一下，不是统一网关，直接去通知上游，而是统一网关，推送消息给mq，上游从mq里面消费消息。这样在支付成功之后新增了其他逻辑时，就不需要改动统一网关了，只需要新增的逻辑去消息mq就行

这样就解耦了，”行业中有一句话，明明是你们的需求改变了，为什么修改代码的人是我（统一网关）“.

问：什么时候用mq，什么时候用rpc

rpc一般在需要及时返回结果时使用

mq一般是在不需要及时返回结果时使用

问：mq,消息必达架构的核心点：

1 消息落地

2 确认

3 重传

4 超时

大概的流和理这样：

 

 

1 mq接收方把消息传到mq_server,

2 mq_server把消息保存到数据库或者硬盘

3 保存成功之后，告诉mq接收方，消息已经入列成功

4 mq_server取出消息告诉mq的消费方

5 mq消费方成功拿到消息之后告诉mq_server我拿到了消息

6 mq_server操作数据库删除掉此条消息.结束

重传：mq有可能在1,4步重新发起,解决重复的问题，消息幂等性怎么保证，每一条消息，mq内部生成一个唯一的id，这样就可以去重了

但是第4步，mq_server重复发消息给了消费方，消费方怎么去重呢，所以业务层需要要消息数据里面生成一个唯一的标识，同一个标识只能被消费一次，用此标识去重

 

问：什么是幂等性？

 

 问：如果并发高，消费者这边达到了上限怎么办呢

 

 mq推模式变为消费方主推拉的模式，这样就能解决消费方上限的问题

问：消息延时业务场景怎么解决：

 

 解决方案

 

 

首先有个环形队列queue,比如从1秒到3600秒，相当于总共把这个圆圈分为3600个格子，时间从第1秒开始走

每一个格子保存了任务的集合set<task>，集合里面有两个关键的key，第1个key，圈数，第2个key，就是指哪个消息了。比如，我这个消息要延迟3小时10秒执行，如果消息入列的时刻，圆圈指针刚好走到1的位置，那么这个消息就放在第10秒的格子里面，并且集合里面的圈数

key设置为3，这样，刚好走3圈多时，3小时10秒，此消息拿出来消费了