消息高可靠性投递成功方案 - 02

关注的重点不是消息能不能100%投递成功，而是在投递高可靠性消息的系统如果更加的减少消耗，提升性能。


个人理解：

Upstream service:上游服务，生产者

Downstream service:下游服务，消费者

Step1:在进行完业务操作并确认已落地BIZ DB后,生产者发送消息到MQ Broker

Step2: 生产者延迟再发送一条相同的消息到MQ Broker（设定延迟时间）

Step3: 消费者监听到了MQ Broker里的消息，接收消息

Step4: 消费者在内部重新编辑了一条消息confirm，返回给了MQ Broker

Step5: 回调服务Callback service，监听到消息Confirm，获取消息的状态，把消息持久化到MSG DB

Step6: 延迟投递的消息发送到MQ Broker，由回调服务Callback service监听到进行检查，到
MSG DB里查询该条消息记录，如果消费者已返回消息到MQ Broker并被回调服务Callback service持久化到MSG DB成功，那么这个延迟发送就检查完毕。如果在MSG DB中查询不到该消息，那么就证明消费者返回消息失败，那么需要进行补偿处理。

补偿：
回调服务Callback service会主动发送远程RPC调用上游服务生产者重新进行发送消息再走一边上述流程。

我们关注的点不是100%的消息投递成功，而是能抗住海量数据的量，所以需要进行系统的资源节省，减少消耗，通过异步的方式调用RPC来完成补偿操作，只进行了一次DB的提交，也就是业务操作所需的BIZ DB的提交，相比两次DB的提交大大减少了消耗。

把Callback服务和MSG DB抽取出来，作为一个补偿的服务，是单独的补偿机制，不在业务高峰时进行操作，高并发时实际执行的主流服务就是：业务落地，生产者发送消息到MQ Broker，消费者监听，消费者返回confirm消息。