Sudo Su

MQ消息的可靠性和幂等

9/14/2022

MQ丢消息可能存在三个环节

  • 生产环节
  • MQ存储消息环节
  • 消费消息环节

# A.生产环节丢消息

这是最常见的场景。

客户端调用一个接口，接口需要同时写数据库和写MQ。

结果数据库写成功了，可能因为网络或电源等其他原因，导致写入MQ失败了。

# 1.数据事务中间写入MQ - 不可行

操作步骤如下：

  1. 开启数据库事务
  2. 操作数据库
  3. 写入MQ
  4. 提交数据库事务

这个看似可行，实际上既不可行，又会有性能问题。

# 1.1降低数据库性能

开启数据库事务后，就应该全心全意操作数据库，应该把数据库事务的时间尽可能降低，这样才能提高并发。

尤其MySQL是RR的隔离级别下，事务不提交的情况下：

  • 自己的事务要一直维持 ReadView，还要一直维持着 undoLog；
  • 其他事务还要在各自的 ReadView 中维持着这个事务id
  • 一般都会开启MySQL死锁检测，如果改同一行还要一直影响死锁检测

性能会降低很多。

# 1.2处理不了故障

  • 假如 MQ 写入超时，怎么处理？step3 写入MQ成功还是失败是未知的。

  • 假如 MQ 写入成功，但是step4提交数据库事务的时候出现了故障，会发生什么？事务回滚，但是成功的MQ发出去了。

所以这种方法是不可行的。

# 2.事务消息 - 可行

目前似乎只有 RocketMQ 支持事务消息。

其解决的方式有两个关键点：

  • 将消息添加一个提交状态：已提交/未提交；未提交的不消费；
  • 提供一个事务反查机制

操作步骤：

  1. 向MQ发一个消息，但状态是未提交（称之为半消息/预提交）；同时注册一个回调处理函数；
  2. 操作数据库；
  3. 第2步成功则通知MQ将消息A提交，失败则通知MQ将消息A回滚；

如果第2步数据库commit超时，或者第3步操作失败，导致MQ迟迟没收到提交或回滚的请求，RocketMQ Server 会调用注册的回调函数，来确定消息状态。

该函数的实现要求入参是消息体，返回值是消息的状态。

一般回调函数的辑如下：

  • 根据回调传入的 msgBody 查询出对应的业务处理结果
  • 如果处理成功则返回提交，如果没处理成功则将消息回滚

事务消息确实极大方便了业务逻辑上的开发，然而只有Rocket MQ支持。

使用其他MQ也并非没有办法，还有一个更为通用的解决方案。

# 3.本地消息法 - 通用

实现方式是消息生产者在处理业务数据时，同时保存一下消息的投递状态。

  1. 处理业务数据，并保存消息状态未投递
  2. 向MQ生产消息
  3. 更新消息投递状态

如果第2步或者第3步失败，需要有定时任务扫描“业务成功且投递失败”的记录，再次投递。

然而此时有可能消息已经投递过一次了，因此可能会存在投递两次、甚至多次的情况。

因此消息消费端，必须实现幂等性。

# 3.1常规方式

  • 可以在业务记录表添加一个投递状态的字段，业务逻辑开始的时候状态设置成未投递。

  • 也可以新建一个消息投递表，业务逻辑开始的时候，将业务数据和投递状态，以数据库事务的方式写入，状态也是未投递。

然后起一个定时任务，扫描业务成功，但是消息投递状态是未成功的记录，再生产一次。

# 3.2自产自销

如果业务逻辑本身已经很复杂，不太方便添加事务逻辑，可以采用自产自销的方式来处理：

  • 写一个消费者，消费到生产的消息后就记录到本地消息表，状态为已投递。

  • 另起一个定时任务，将业务表和本地消息表对账。如果有业务成功但没有消费到的记录，就再生产一次。

这个方式不仅能解决生产端丢消息，连MQ丢消息的情况都能解决。

# B.MQ存储消息环境丢消息

当消息送达消息队列，不代表一定就会被消费。

绝大多数MQ虽然会把消息持久化存储到磁盘，但是都是先写入内存，再异步刷入磁盘。

如果遇到机器掉电、或者故障重启，消息就丢了。

解决办法一般有两个：

  • 同步刷盘
  • 多副本备份

# 1.同步刷盘

RocketMQ 可以像 MySQL 一样配置刷盘策略。

改成同步刷盘的话，只有消息落盘后MQ才会告知生产者成功。

同步刷盘会极大影响性能。

# 2.使用集群多副本备份

集群会将数据做多副本备份，集群间内网通信。

耗时数据对比大约如下：

  • 一次SSD随机写操作 150us
  • 一次网络传输大约 20us
  • 一次内存寻址 100ns

一次磁盘随机的耗时远大于网络传输，因此也可以通过副本来保证可靠性。

当同步完一定比例的从节点后，就可以认为消息已经可靠了，毕竟所有节点全部挂掉的可能性太低了。

# 3.本地消息表自产自销

参见在生产环节丢消息的解决方案：自产自销。

# C.消费环节丢消息

大多数MQ都要求消费者明确返回一个消费成功的状态，才会停止消息的重复投递。

因此这个环节只要保证确实消费成功再回复ACK，就能保证消费环节不丢失。

这个环节真正要考虑的是消费的幂等性。

# 幂等性依赖业务标识

幂等性不应当依赖消息ID，应当依赖消息体内的业务标识。

为了保证可靠性，生产端存在同一个业务生产两次消息的情况。此时消费端，会拿到两条消息，但却是同一个业务。

因此同一个业务数据，其标识一定是固定的，能唯一标识这条业务数据的。