消息落地 + 超时、重传、确认，上下两个半场都要可靠
《即时通讯架构核心技术》第 16 篇：MQ 如何实现消息必达。
MQ 能不能实现消息必达？
要想消息必达，架构设计上有两个核心设计点：
1. 消息落地；
2. 消息超时、重传、确认；
更具体的，要从MQ的架构与流程谈起。
MQ 的核心架构如何？
如上图所示，MQ的核心架构图分为三大块：
1. 发送方 -> 左侧粉色部分；
2. MQ核心集群 -> 中间蓝色部分；
3. 接收方 -> 右侧黄色部分；
粉色发送方又由两部分构成：
1. 业务调用方；
2. MQ-client-sender；
其中，后者向前者提供了两个核心API：
SendMsg(bytes[] msg)
SendCallback()
蓝色MQ核心集群由MQ-server，zk，db，管理后台web等一系列子系统组成。
黄色接收方也由两部分构成：
1. 业务接收方；
2. MQ-client-receiver
其中，后者向前者也提供了两个核心API：
RecvCallback(bytes[] msg)
SendAck()
MQ是一个系统间解耦的利器，它能够很好的解除发布订阅者之间的耦合，它将上下游的消息投递解耦成两个部分，如上述架构图中的箭头1和箭头2：
箭头1，上半场：发送方将消息投递给MQ；
箭头2，下半场：MQ将消息投递给接收方；
MQ既然将消息投递拆成了上下半场，为了保证消息的可靠投递，上下半场都必须尽量保证消息必达。
上半场，消息投递流程如何？
MQ消息投递上半场，流程见上图123：
1. sender将消息发送给MQ-server；
2. MQ-server将消息落地；
3. MQ-server回调sender；
上半场，如果消息丢了怎么办？
答：超时与重传。
MQ上半场的123如果丢失或者超时，sender内置的timer会重发消息，直到收到3。如果重传N次后还未收到3，则SendCallback向业务方回调发送失败。
下半场，消息投递流程如何？
MQ消息投递下半场，流程见上图456：
4. MQ-server回调receiver；
5. receiver收到消息，处理业务逻辑，将ACK发送给MQ-server；
6. MQ-server收到ACK，将之前已经落地的消息删除，流程结束；
下半场，如果消息丢了怎么办？
答：还是超时与重传。
MQ下半场的456如果丢失或者超时，MQ-server内置的timer会重发消息，直到收到5并且成功执行6。
上下半场都要超时重发，策略如何？
常见的策略有两种：
1. 定时重发，每隔10秒发一次，直到超出次数；
2. 指数退避，先隔x秒重发，2x秒重发，4x秒重发，以此类推；
总结
1. MQ是系统之间的解耦利器，它能解除消息发送方与接收方的直接耦合；
2. MQ将消息投递解耦成了上下两个半场；
3. MQ消息必达，架构上有两个核心设计点：
- 消息落库
- 消息超时、重传、确认
未尽事宜
消息重发可能导致收到重复的消息，如何进行架构幂等性设计，下次撰文另述。
检验一下
必达解决了，但超时重传会带来重复消息——消息幂等怎么设计，「下次撰文另述」的那一篇来了：第 17 篇，MQ 如何保证消息幂等。
知其然，知其所以然。思路比结论更重要。