MQ消息的可靠性

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常规方式

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

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

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

3.2自产自销

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

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

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

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

B.MQ存储消息环节

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

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

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

解决办法一般有两个：

• 同步刷盘

• 多副本备份

1.同步刷盘

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

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

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

2.使用集群多副本备份

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

耗时数据对比大约如下：

• 一次SSD随机写操作 150us

• 一次网络传输大约 20us

• 一次内存寻址 100ns

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

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

3.本地消息表自产自销

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

C.消费环节

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

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

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

幂等性依赖业务标识

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

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

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