如果同一个数据源在本地事物很好控制,但是在不断发展的互联网环境下,微服务越来越流行,这个时候,需要解决分布式事物,需要保证数据的最终一致性。
所谓分布式事务(全局事物),就是在两个不同的系统中(即两个不同的数据源,其实同一个数据源也行),无法同一个同一个spring事物去控制不同系统的事物的整体成功或者整体失败。
分布式事务的解决方法很多,但是性能和复杂性不一样,今天说说rocketmq如何保证分布式事务的。
rocketmq为我们提供TransactionMQProducer API的支持。这个api在发送消息的时候主要做了三件事:
1,先发送需要发送的消息到消息中间件broker,并获取到该message的transactionId。在第一次发送的时候,该消息的状态为LocalTransactionState.UNKNOW
2,处理本地事物。
3,根据本地事物的执行结果,结合transactionId,找到该消息的位置,在mq中标志该消息的最终处理结果。
整体的执行源码逻辑如下:
public TransactionSendResult sendMessageInTransaction(Message msg, LocalTransactionExecuter tranExecuter, Object arg) throws MQClientException {
if (null == tranExecuter) {
throw new MQClientException("tranExecutor is null", (Throwable)null);
} else {
Validators.checkMessage(msg, this.defaultMQProducer);
SendResult sendResult = null;
MessageAccessor.putProperty(msg, "TRAN_MSG", "true");
MessageAccessor.putProperty(msg, "PGROUP", this.defaultMQProducer.getProducerGroup());
try {
//这里执行第一次发送消息,也就是预发送,并获取sendResult,这里包含msg的所有消息
sendResult = this.send(msg);
} catch (Exception var10) {
throw new MQClientException("send message Exception", var10);
}
LocalTransactionState localTransactionState = LocalTransactionState.UNKNOW;
Throwable localException = null;
//根据预发送消息的状态做不同的处理,这里主要看SEND_OK
switch(sendResult.getSendStatus()) {
case SEND_OK:
try {
if (sendResult.getTransactionId() != null) {
msg.putUserProperty("__transactionId__", sendResult.getTransactionId());
}
// 这里做第二步,执行业务逻辑,即本地事物,
//具体的本地事物在LocalTransactionExecuter参数的实现类中,
//需要根据自己的业务逻辑去写,下面的//tranExecuter.executeLocalTransactionBranch(msg, arg);会执行实
//现类中的executeLocalTransactionBranch业务。
localTransactionState = tranExecuter.executeLocalTransactionBranch(msg, arg);
if (null == localTransactionState) {
localTransactionState = LocalTransactionState.UNKNOW;
}
if (localTransactionState != LocalTransactionState.COMMIT_MESSAGE) {
this.log.info("executeLocalTransactionBranch return {}", localTransactionState);
this.log.info(msg.toString());
}
} catch (Throwable var9) {
this.log.info("executeLocalTransactionBranch exception", var9);
this.log.info(msg.toString());
localException = var9;
}
break;
case FLUSH_DISK_TIMEOUT:
case FLUSH_SLAVE_TIMEOUT:
case SLAVE_NOT_AVAILABLE:
localTransactionState = LocalTransactionState.ROLLBACK_MESSAGE;
}
try {
// 这里的方法,其中的localTransactionState是第二次执行业务逻辑的结果
//可以根据这个结果,知道本地事物执行的成功还是失败。或者是异常localException,
//这样可以根据第一次发送消息的结果sendResult,去修改mq中第一次发送消息的状态,完成第三步操作。
this.endTransaction(sendResult, localTransactionState, localException);
} catch (Exception var8) {
this.log.warn("local transaction execute " + localTransactionState + ", but end broker transaction failed", var8);
}
TransactionSendResult transactionSendResult = new TransactionSendResult();
transactionSendResult.setSendStatus(sendResult.getSendStatus());
transactionSendResult.setMessageQueue(sendResult.getMessageQueue());
transactionSendResult.setMsgId(sendResult.getMsgId());
transactionSendResult.setQueueOffset(sendResult.getQueueOffset());
transactionSendResult.setTransactionId(sendResult.getTransactionId());
transactionSendResult.setLocalTransactionState(localTransactionState);
return transactionSendResult;
}
}
上述第三步执行的方法endTransaction,逻辑如下:
public void endTransaction(SendResult sendResult, LocalTransactionState localTransactionState, Throwable localException) throws RemotingException, MQBrokerException, InterruptedException, UnknownHostException {
// 获取第一次发送消息的id
MessageId id;
if (sendResult.getOffsetMsgId() != null) {
id = MessageDecoder.decodeMessageId(sendResult.getOffsetMsgId());
} else {
id = MessageDecoder.decodeMessageId(sendResult.getMsgId());
}
//获取事物id
String transactionId = sendResult.getTransactionId();
String brokerAddr = this.mQClientFactory.findBrokerAddressInPublish(sendResult.getMessageQueue().getBrokerName());
EndTransactionRequestHeader requestHeader = new EndTransactionRequestHeader();
requestHeader.setTransactionId(transactionId);
requestHeader.setCommitLogOffset(id.getOffset());
//根据本地事物执行状态localTransactionState,告知mq修改状态
switch(localTransactionState) {
case COMMIT_MESSAGE:
requestHeader.setCommitOrRollback(Integer.valueOf(8));
break;
case ROLLBACK_MESSAGE:
requestHeader.setCommitOrRollback(Integer.valueOf(12));
break;
case UNKNOW:
requestHeader.setCommitOrRollback(Integer.valueOf(0));
}
requestHeader.setProducerGroup(this.defaultMQProducer.getProducerGroup());
requestHeader.setTranStateTableOffset(sendResult.getQueueOffset());
requestHeader.setMsgId(sendResult.getMsgId());
String remark = localException != null ? "executeLocalTransactionBranch exception: " + localException.toString() : null;
//具体执行第三步完成整个事务。
this.mQClientFactory.getMQClientAPIImpl().endTransactionOneway(brokerAddr, requestHeader, remark, (long)this.defaultMQProducer.getSendMsgTimeout());
}
上述:
如果第三阶段出现异常或者网络原因,就是本地事务执行成功持久化到数据库中,但是在修改mq中消息状态出现异常的时候,这样就可以出现本地和mq的消息状态的不一致问题。或者说,所有的数据不一致问题。rocketmq都会定期通过TransactionMQProducer API初始化的时候,设置的TransactionCheckListener的的实现类的checkLocalTransactionState 方法检查本地消息的状态,根据本地状态修改mq的状态
package org.apache.rocketmq.client.producer;
import org.apache.rocketmq.common.message.MessageExt;
public interface TransactionCheckListener {
LocalTransactionState checkLocalTransactionState(MessageExt var1);
}
这样就可以确保生产端的数据要么是本地事物执行失败,rollback mq中消息,或者本地事物执行成功,mq中的消息也是待消费的状态。
说到这里,其实分布式事务已经完成90%。如果生产端的的第三部不是成功状态,消费端是不会消费第一阶段的消息的。所以,只要消费端消费的消息,肯定是生产端成功的消息,而消费端只要保证幂等性,就可以准确的消费消息(因为消费失败了,mq是可以重试,如果最总都没有被消费,基本是程序有bug,可以事后人工处理了。