消息100%投递的两种方案

前言：消息中间件 是用来 客户端 与 客户端之间通信的，那么就存在以下两个问题：

1. 如何避免消息重复消费（针对consumer）
2. 如何保证消息的可靠性投递（针对publisher）

对于问题1，看《防止消息重复消费》一文

下面讲问题2：保证消息的可靠性投递

---

上图是消息投递的整个流程，熟悉该流程有助于该文章的理解

要保证消息的可靠性投递，那么应满足以下几个条件：
1. message成功发出去
2. broker节点成功收到message
3. publisher成功收到broker节点的确认应答
4. 完善的消息补全机制，即能对因为网络或服务器宕机等问题而丢失的message进行补偿发送

常见的 可靠消息投递 方案主要有2种，下面先讲第1种（第2种是在第1种的基础上进行优化）

方案1，如下图示：

如上图示：
message有以下4种状态
status 0：初始状态
status 1：publisher收到broker 确认消息后的状态
status 2：消息被consumer成功消费后的状态
status 3：异常状态，需人工跟进处理

步骤如下：
step 1：message 入库（存进db），初始 status 为 0
step 2：publisher发送message到 broker
step 3：broker收到消息后返回 确认消息 给publisher
step 4：publisher收到确认消息后，更新 message 的 status 为 1
step 5：consumer从broker获取消息并执行
step 6：consumer执行成功后返回确认消息给broker
step 7：consumer执行成功后将message 的 status 更新为 2
step 8：定时任务(cronjob)扫描db中status为0的message
step 9：cronjob将status为0的message重新发送到publisher，重复前面的 step2 ~ step7
step 10：为避免cronjob无限重复发送message而拖垮服务，
         message发送次数大于3时，转为异常message，即status置为3


总结：
1. step2 这一步骤，有可能因为网络故障或者broker宕机而导致message丢失，
因此需要消息补偿机制(step8 ~ step10)，由定时任务(cronjob)实现

2. 上面方案如果在step3 or step4发生错误，可能会发生broker已收到消息，但status没能更新为1情况
此时就会进入消息补偿环节，导致broker中存在2条相同消息，造成重复投递问题
而在业务上，比如支付业务上，是不允许消息重复消费消息的。
此时就需要在 consumer 端来处理这问题，即问题1《如何避免消息重复消费》

3. 一条message，从创建到消费完毕，共经过 0，1，2 这三种消息状态，
需要进行3次db操作。而在实际业务中，造成服务瓶颈的往往是db操作，
3次耗时有点多，有没有优化方法？有的，看下面的 消息可靠投递方案2

方案2，如下图示：

如上图示：
'upstreamService'：上游服务，即消息生产者(下面简称'uss')
'downstreamService'：下游服务，即消息消费者(下面简称'dss')
'callbackService'：回调服务，确认消息已经被成功消费并更新入库消息(下面简称'cbs')

步骤如下：
step 1：uss入库消息后，第一次发送消息给 broker

step 2：uss第二次发送消息，第二条消息属于延迟检查消息。
检查第一条消息是否已经被成功消费，两次投递之间需要间隔时间，比如5分钟

step 3：dss从broker获取消息

step 4：dss消费消息后发送confirm消息，这里的confirm不是正常的ack响应，
而是重新生成一条消息，发送到broker中

step5 5：cbs监听dss发送的confirm消息，如果收到confirm消息，
说明消息已经被成功消费，更新消息的状态为成功消费

step 6：5分钟之后，cbs收到了uss发送的延迟检查消息，此时会去db中检查消息是否已经被成功消费。
如果成功，不需要做任何处理。
如果失败，cbs会发起rpc服务通知uss该条消息投递失败，需要重新发送。
uss收到rpc通知后会重新发送该消息，重走step1 ~ step5的流程

总结：
1. 方案2的step2和step6这两步骤，实现了消息补偿机制

2. 方案2消息的status经过 0(初始)，1(成功消费) 两种状态。只进行了2次db操作
相对前面的方案1 (3次db操作)，性能上提升了 1/3，能支持更高的并发量。

3. cbs调起rpc通知这一步，如果出现故障，会导致消息的丢失，可靠性并没有方案1高。
但在实际业务中，有时并不需要100%的消息投递，可能是要支持更高的并发量，此时可以采用方案2。
另外如果真需要100%的消息投递，可以在方案2的基础上机上方案1的cronjob补偿消息，提高消息投递的可靠性