消息可靠性投递方案

Step 1

Confirm Listener

Step 1：first Send

MQ Broker

Sender

如果再高并发的情况下，消息就不要入库了，延迟投递，可以不保证首次100%的成功，但是一定要保证性能。

Consumer

方案一、消息落库，对消息状态进行打标

Step 4：status ：1

Step 6：Check Detail

消息落库步骤：

Step 2：Second Delay Check

MSG DB

Callback service

Step 5：Listener Confirm

Step 7：Retry Count 3 status：2

Callback Service 作用就是一个补偿服务

Step 3：Listener Consume

Producer

Step 6：Retry Send

分布式定时任务

Step 3：broker confirm

Step 2：send message

BIZ DB

RPC ReSend Command

1、写入数据库，可能涉及多个库，业务库，消息库2、发送消息3、消息确认4、更新数据库消息状态5、定时任务获取数据库消息状态6、重试发送7、重试数量大于 3 次，修改状态

Step 5：get status：0

1、首次发送，一定等到业务数据入库之后再发送消息2、延迟发送刚发送消息的检查消息3、当消费者消费消息4、消息消费成功之后，发送一个确认消费消息5、CallBack 服务收到消费者的确认消息，消费成功之后，做消息的持久化存储6、CallBack 服务检查，处理第二步发送的检查消息，检查数据库是否有处理成功，如果处理成功了，那么就不用处理任何事情，如果处理失败了，Callback 服务再发送 RPC 通知 Producer 再次发送消息。

方案二、延迟投递