前言
从4.3.0版本开始支持事务消息,这是一个令人振奋的消息,线上目前4.2.0,在正式投产使用之前先进性简单分析。帮助用户实现类似 X/Open XA 的分布事务功能,通过 MQ 事务消息能达到分布式事务的最终一致。
基础概念
- 事务消息:MQ 提供类似 X/Open XA 的分布事务功能,通过 MQ 事务消息能达到分布式事务的最终一致。
- 半消息:暂不能投递的消息,发送方已经将消息成功发送到了 MQ 服务端,但是服务端未收到生产者对该消息的二次确认,此时该消息被标记成“暂不能投递”状态,处于该种状态下的消息即半消息。
- 消息回查:由于网络闪断、生产者应用重启等原因,导致某条事务消息的二次确认丢失,MQ 服务端通过扫描发现某条消息长期处于“半消息”时,需要主动向消息生产者询问该消息的最终状态(Commit 或是 Rollback),该过程即消息回查。
实现原理
其中:
- 发送方向 MQ 服务端发送消息。
- MQ Server 将消息持久化成功之后,向发送方 ACK 确认消息已经发送成功,此时消息为半消息。
- 发送方开始执行本地事务逻辑。
- 发送方根据本地事务执行结果向 MQ Server 提交二次确认(Commit 或是 Rollback),MQ Server 收到 Commit 状态则将半消息标记为可投递,订阅方最终将收到该消息;MQ Server 收到 Rollback 状态则删除半消息,订阅方将不会接受该消息。
- 在断网或者是应用重启的特殊情况下,上述步骤4提交的二次确认最终未到达 MQ Server,经过固定时间后 MQ Server 将对该消息发起消息回查。
- 发送方收到消息回查后,需要检查对应消息的本地事务执行的最终结果。
- 发送方根据检查得到的本地事务的最终状态再次提交二次确认,MQ Server 仍按照步骤4对半消息进行操作。
事务消息发送对应步骤1、2、3、4,事务消息回查对应步骤5、6、7。
code实战
发送事务消息
- 发送半消息及执行本地事务。
public class TransactionProducerClient {
private final static Logger log = ClientLogger.getLog(); // 您需要设置自己的日志,便于排查问题
public static void main(String[] args) throws InterruptedException {
final BusinessService businessService = new BusinessService(); // 本地业务 Service
Properties properties = new Properties();
// 您在控制台创建的 Producer ID 注意:事务消息的 Producer ID 不能与其他类型消息的 Producer ID 共用
properties.put(PropertyKeyConst.ProducerId, "");
// 阿里云身份验证,在阿里云服务器管理控制台创建
properties.put(PropertyKeyConst.AccessKey, "");
// 阿里云身份验证,在阿里云服务器管理控制台创建
properties.put(PropertyKeyConst.SecretKey, "");
// 设置 TCP 接入域名(此处以公共云生产环境为例)
properties.put(PropertyKeyConst.ONSAddr,
"http://onsaddr-internal.aliyun.com:8080/rocketmq/nsaddr4client-internal");
TransactionProducer producer = ONSFactory.createTransactionProducer(properties,
new LocalTransactionCheckerImpl());
producer.start();
Message msg = new Message("Topic", "TagA", "Hello MQ transaction===".getBytes());
try {
SendResult sendResult = producer.send(msg, new LocalTransactionExecuter() {
@Override
public TransactionStatus execute(Message msg, Object arg) {
// 消息 ID(有可能消息体一样,但消息 ID 不一样,当前消息 ID 在控制台无法查询)
String msgId = msg.getMsgID();
// 消息体内容进行 crc32,也可以使用其它的如 MD5
long crc32Id = HashUtil.crc32Code(msg.getBody());
// 消息 ID 和 crc32id 主要是用来防止消息重复
// 如果业务本身是幂等的,可以忽略,否则需要利用 msgId 或 crc32Id 来做幂等
// 如果要求消息绝对不重复,推荐做法是对消息体 body 使用 crc32或 md5来防止重复消息
Object businessServiceArgs = new Object();
TransactionStatus transactionStatus = TransactionStatus.Unknow;
try {
boolean isCommit =
businessService.execbusinessService(businessServiceArgs);
if (isCommit) {
// 本地事务成功则提交消息
transactionStatus = TransactionStatus.CommitTransaction;
} else {
// 本地事务失败则回滚消息
transactionStatus = TransactionStatus.RollbackTransaction;
}
} catch (Exception e) {
log.error("Message Id:{}", msgId, e);
}
System.out.println(msg.getMsgID());
log.warn("Message Id:{}transactionStatus:{}", msgId, transactionStatus.name());
return transactionStatus;
}
}, null);
}
catch (Exception e) {
// 消息发送失败,需要进行重试处理,可重新发送这条消息或持久化这条数据进行补偿处理
System.out.println(new Date() + " Send mq message failed. Topic is:" + msg.getTopic());
e.printStackTrace();
}
// demo example 防止进程退出(实际使用不需要这样)
TimeUnit.MILLISECONDS.sleep(Integer.MAX_VALUE);
}
}
- 提交事务消息状态
当本地事务执行完成(执行成功或执行失败),需要通知服务器当前消息的事务状态。 通知方式有以下两种:
执行本地事务完成后提交
执行本地事务一直没提交状态,等待服务器回查消息的事务状态
事务状态有以下三种:
TransactionStatus.CommitTransaction 提交事务,允许订阅方消费该消息。
TransactionStatus.RollbackTransaction 回滚事务,消息将被丢弃不允许消费。
TransactionStatus.Unknow 无法判断状态,期待 MQ Broker 向发送方再次询问该消息对应的本地事务的状态。
public class LocalTransactionCheckerImpl implements LocalTransactionChecker {
private final static Logger log = ClientLogger.getLog();
final BusinessService businessService = new BusinessService();
@Override
public TransactionStatus check(Message msg) {
//消息 ID(有可能消息体一样,但消息 ID 不一样,当前消息属于 Half 消息,所以消息 ID 在控制台无法查询)
String msgId = msg.getMsgID();
//消息体内容进行 crc32,也可以使用其它的方法如 MD5
long crc32Id = HashUtil.crc32Code(msg.getBody());
//消息 ID、消息本 crc32Id 主要是用来防止消息重复
//如果业务本身是幂等的,可以忽略,否则需要利用 msgId 或 crc32Id 来做幂等
//如果要求消息绝对不重复,推荐做法是对消息体使用 crc32 或 md5 来防止重复消息
//业务自己的参数对象,这里只是一个示例,需要您根据实际情况来处理
Object businessServiceArgs = new Object();
TransactionStatus transactionStatus = TransactionStatus.Unknow;
try {
boolean isCommit = businessService.checkbusinessService(businessServiceArgs);
if (isCommit) {
//本地事务已成功则提交消息
transactionStatus = TransactionStatus.CommitTransaction;
} else {
//本地事务已失败则回滚消息
transactionStatus = TransactionStatus.RollbackTransaction;
}
} catch (Exception e) {
log.error("Message Id:{}", msgId, e);
}
log.warn("Message Id:{}transactionStatus:{}", msgId, transactionStatus.name());
return transactionStatus;
}
}
import java.util.zip.CRC32;
public class HashUtil {
public static long crc32Code(byte[] bytes) {
CRC32 crc32 = new CRC32();
crc32.update(bytes);
return crc32.getValue();
}
}
事务回查机制说明
-
发送事务消息为什么必须要实现回查 Check 机制?
当步骤(1)中 Half 消息发送完成,但本地事务返回状态为 TransactionStatus.Unknow,或者应用退出导致本地事务未提交任何状态时,从 MQ Broker 的角度看,这条 Half 状态的消息的状态是未知的。 因此 MQ Broker 会定期要求发送方能 Check 该 Half 状态消息,并上报其最终状态。
-
Check 被回调时,业务逻辑都需要做些什么?
MQ 事务消息的 check 方法里面,应该写一些检查事务一致性的逻辑。 MQ 发送事务消息时需要实现 LocalTransactionChecker 接口,用来处理 MQ Broker 主动发起的本地事务状态回查请求;因此在事务消息的 Check 方法中,需要完成两件事情:
(1) 检查该 Half 消息对应的本地事务的状态(commited or rollback);
(2) 向 MQ Broker 提交该 Half 消息本地事务的状态。