备注：消息最终一致性的补偿机制、分布式事务场景不在本规范范畴内
问题
业务场景
业务需求上经常会有一些边缘操作，比如主流程操作A：用户报名课程操作入库，边缘操作B：发送邮件或短信通知。
业务要求
操作A操作数据库失败后，事务回滚，那么操作B不能执行。
操作B执行成功的话，操作A一定是执行成功的，反之不成立，加上补偿机制可实现在后续某个时间点操作B是成功的。
实现方案
1、使用TransactionSynchronizationManager在事务提交之后操作
@Transactional
public void insert(TechBook techBook){
bookMapper.insert(techBook);
// send after tx commit but is async
TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronizationAdapter() {
@Override
public void afterCommit() {
System.out.println("send email after transaction commit...");
}
}
);
}
2、使用@TransactionalEventListener处理数据库事务提交成功后再执行操作
@Transactional
public void finishOrder(Order order){
// 修改订单成功
updateOrderSuccess(order);
// 发布 Spring Event 事件
applicationEventPublisher.publishEvent(new MyAfterTransactionEvent(order));
}
@Slf4j
@Component
private static class MyTransactionListener {
@Autowired
private MqService mqService;
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
private void onHelloEvent(MyAfterTransactionEvent event) {
Order order = event.getOrder();
mqService.send(order);
}
}
// 定一个事件，继承自ApplicationEvent
private static class MyAfterTransactionEvent extends ApplicationEvent {
private Order order;
public MyAfterTransactionEvent(Object source, Order order) {
super(source);
this.order = order;
}
public Order getOrder() {
return order;
}
}
分析对比
TransactionSynchronizationManager
优点：适合应用在旧逻辑上，降低改造成本
缺点：该方式对代码的耦合度较高，代码不够优雅
TransactionalEventListener
优点：结构上比 TransactionSynchronization 优雅，并且可结合领域，在监听触发多个领域事件的发送，建议在后续新发消息中采用
缺点：对旧代码逻辑优雅不起来，单个领域事件由于触发点众多，可能需要定义多个事件及监听
结论
旧有消息发送采用TransactionSynchronizationManager覆盖，新增消息发送用TransactionalEventListener设计解决
