前言：消息中间件 是用来 客户端 与 客户端之间通信的，那么就存在以下两个问题：
- 如何避免消息重复消费（针对consumer）
- 如何保证消息的可靠性投递（针对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补偿消息，提高消息投递的可靠性
