高空之盾：构建系统韧性的高可用投递方案设计

系列文章目录

---

前言

MQ一直是系统开发中必不可少的组件，众所周知MQ有流量削峰，解耦，异步 三大特性。但是既然是第三方组件，那么如何保证消息投递性的可靠性，是我们开发人员必须要研究的。

一、如何保证消息投递的可靠性？

所谓消息投递的可靠性就是保证消息生成之后能准确的投递到消费者，并被消费者消费。而消息队列一般都是由生成者Producer,消费者Consumer，消费存放的地方Broker三个组成。所以讨论消息投递的可靠性，实则就是讨论如何保证消息在这三部分不丢失的问题。

二、什么是生产端的可靠性投递？

• 保障消息的成功发出
• 保障MQ节点的成功接收
• 发送端接收到MQ节点（Broker）确认应答
• 完善的消息补偿机制
  • 如何保障100%投递成功需要有补偿机制
  • 生产端在投递消息的时候失败了的处理机制
  • 生产端消息投递到MQ，但在MQ给生产返回应答时出现网络闪断这就导致生产端不知道消息是否送达

三、业界常用的高可靠投递方案

• 消息落库，对消息状态进行标记

  • 将消息发送状态落入DB中，比如发送中，发送成功
  • 对于没有发送成功的状态进行轮询检查，全部重新发送
  • 重新发送的消息也要进行一个最大异常重发次数的设置，比如3-5次，如果多次都不成功就要看消息体有什么问题，消息就不再重复发送，随后人工检查处理

• 消息的延迟投递，做二次确认，回调检查

消息落库，对消息状态进行标记

就拿我们的支付业务来说，首先我们需要生成一个订单，然后将这个订单先保存到数据库里面去并给他一个初始的状态，然后调用第三方的渠道进行支付，并再次更新订单的状态。支付一般都是异步支付，所以最终的结果还是要等到支付渠道通知给我们，再次更新状态。这样做的目的就是保证数据不丢失，不能等调用第三方之后再进行落库，因为网络永远是不可靠的，如果在这个过程中出现超时，或者第三方服务挂掉了，那我们的数据就找不到了。

消息的延迟投递，做二次确认，回调检查

这个也很好理解，我们可以通过回调的结果来进行相对应的处理，如果回调结果是失败了，我们就可以进行再次投递，但是需要限制次数，不然就是浪费资源。但是这种重试机制会导致幂等性问题，这个我们会在接下来的章节去讲解。