Can the message bus realize that the message must be reached?
1. Origin
The business application of the two-phase ring queue was discussed last week:
" Triggering Efficient Scheduled Tasks "
" Fast Implementation of Delayed Messages "
Both issues have a large number of readers asking questions:
Tasks and delayed messages are placed in memory. What if it restarts?
Can you guarantee that the message will arrive?
Today, I will briefly talk about the message accessibility architecture and process of the message queue ( MsgQueue ) .
2. Architecture direction
In order for MQ to try to reach the message as much as possible, there are two core design points in the architecture:
( 1 ) Message landing
( 2 ) message timeout, retransmission, confirmation
3. MQ core architecture
The above picture is a core architecture diagram of MQ , which can be basically divided into three parts:
( 1 ) Sender -> left pink part
( 2 ) MQ core cluster -> middle blue part
( 3 ) Receiver -> the yellow part on the right
The pink sender consists of two parts: the business caller and the MQ-client-sender
The latter provides the former with two core APIs :
SendMsg(bytes[] msg)
SendCallback()
The blue MQ core cluster is divided into four parts: MQ-server , zk , db , management background web
The yellow receiver also consists of two parts: the business receiver and the MQ-client-receiver
The latter provides the former with two core APIs :
RecvCallback(bytes[] msg)
SendAck()
MQ is a tool for decoupling between systems . It can well decouple the publishing and subscribers. It decouples the upstream and downstream message delivery into two parts, such as the 1 arrow and the 2 arrow in the above architecture diagram :
( 1 ) The sender delivers the message to MQ , the first half
( 2 ) MQ delivers the message to the receiver, the second half
Fourth, the core process of MQ message reliable delivery
Since MQ splits the message delivery into the upper and lower halves, in order to ensure the reliable delivery of messages, the message must be delivered as much as possible in the upper and lower halves .
In the first half of MQ message delivery , the process from MQ-client-sender to MQ-server is shown in Figure 1-3 above :
( 1 ) MQ-client sends the message to MQ-server (at this time, the business party calls the API : SendMsg )
( 2 ) MQ-server will land the message, and it will be sent successfully after landing
（3）MQ-server将应答发送给MQ-client（此时回调业务方是API：SendCallback）
MQ消息投递下半场，MQ-server到MQ-client-receiver流程见上图4-6：
（1）MQ-server将消息发送给MQ-client（此时回调业务方是API：RecvCallback）
（2）MQ-client回复应答给MQ-server（此时业务方主动调用API：SendAck）
（3）MQ-server收到ack，将之前已经落地的消息删除，完成消息的可靠投递
如果消息丢了怎么办？
MQ消息投递的上下半场，都可以出现消息丢失，为了降低消息丢失的概率，MQ需要进行超时和重传。
上半场的超时与重传
MQ上半场的1或者2或者3如果丢失或者超时，MQ-client-sender内的timer会重发消息，直到期望收到3，如果重传N次后还未收到，则SendCallback回调发送失败，需要注意的是，这个过程中MQ-server可能会收到同一条消息的多次重发。
下半场的超时与重传
MQ下半场的4或者5或者6如果丢失或者超时，MQ-server内的timer会重发消息，直到收到5并且成功执行6，这个过程可能会重发很多次消息，一般采用指数退避的策略，先隔x秒重发，2x秒重发，4x秒重发，以此类推，需要注意的是，这个过程中MQ-client-receiver也可能会收到同一条消息的多次重发。
MQ-client与MQ-server如何进行消息去重，如何进行架构幂等性设计，下一次撰文另述，此处暂且认为为了保证消息必达，可能收到重复的消息。
五、总结
消息总线是系统之间的解耦利器，但切勿滥用，未来也会撰文细究MQ的使用场景，消息总线为了尽量保证消息必达，架构设计方向为：
（1）消息收到先落地
（2）消息超时、重传、确认保证消息必达
有问题随时沟通交流，后续讲消息去重、幂等性设计、何时该使用MQ。