消息补偿。

消息可靠性保障

消息补偿机制

消息补偿。_第1张图片

步骤:

如果正常情况,生产者投递消息到队列,消费者监听队列消费,那就万事大吉,但是有很多不可控原因,网络波动,程序异常,等等,导致不是每次都正常投递消费,所以我们要做到消息可靠投递消费,采用消息补偿机制

  1. 生产者将数据写入到本地数据库
  2. 生产者投递消息到消息队列 Q1
  3. 过段时候生产者再次发送消息到队列 Q2,与第②步投递的消息相同
  4. 消费者监听队列 Q1,消费
  5. 消费者将消息写入到消费者的本地数据库
  6. 消费者将消息投递到另外一个队列 Q3
  7. 一个独立的回调检查服务会监听队列 Q3,监听 Q3 [消费者投递的消息] 里的消息,如果消费者正常消费,那么Q3肯定会有该消息
  8. 将监听的 Q3 的消息写入到回调检查的本地数据库
  9. 回调检查服务监听 Q2 [生产者延迟投递的消息]
  10. 将监听的 Q2 的消息写入到本地数据库,由于第⑧步已经写入过一次,所以肯定会主键冲突(一般消息都携带唯一主键),说明成功
  11. 如果 Q2 写入成功,说明第 8 步监听Q3 没有该消息,说明消息消费失败,通知生产者再次投递该消息

仍然有其他的问题:

  1. 假设第 2 步,第 3 步都投递失败,Q1 ,Q2 里都没有该消息,消费者不会消费,回调检查服务监听 Q2 也没有消息
    • 采用独立的定时检查服务,查看生产者的数据库与回调检查的数据库数据是否一致。如果回调检查的数据库数据少于生产者数据库,定时检查服务通知生产者投递
  2. 假设第④⑤⑥步网络波动,导致消费者消费完,过了很久10分钟才投递到 Q3,而第③步只延迟了5分钟,回调检查服务监听 Q2 Q3,当第5分钟的时候,发现 Q2 里有消息,就进行第⑩步,数据检查,发现回调服务的数据库里写入成功,以为消费者消费失败,通知了生产者重发,而生产者又发送了一条一样的消息。消费者有可能重复消费。
    产者重发,而生产者又发送了一条一样的消息。消费者有可能重复消费。
    • 幂等性保障

你可能感兴趣的:(RabbitMQ,rabbitmq)