基于消息-实现分布式事务解决方案

1：什么分布式是事务？

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。（摘自百度百科）

2：为什么要使用分布式事务？

假设有如下场景，用户浏览某猫电商平台，看中了一款商品，于是点击了下单并进行了支付，这个时候会发生什么?

先进行个简单的猜想，支付成功后大致流程如下：
1：调用订单系统生成订单
2：调用库存系统减库存
3：调用支付系统扣款
4：调用物流系统发货
5：…
分布式系统中，订单、支付、库存、物流等系统均为独立部署且数据库隔离，相互之间通过RPC接口调用的形式进行通信，如果不使用分布式系统会造成什么问题？本文以1和2两步进行举例
用户下单后，将产生订单数据，并在订单系统中新增一条记录，新增成功后，调用库存系统进行减库存，如果库存系统因网络等其他原因，在超时之前还没有返回成功标识，则主程序将会发生异常，自动回滚，此时，就会出现脏数据，用户订单并没有创建成功，但库存却减少了，分布式事务，就是为了解决类似于这样的问题。

3：分布式事务的解决方案

1：基于数据库XA/JTA的方式；需要数据库厂商的支持,JAVA组件有atomikos等
2：异步校对数据的方式；支付宝，微信主动查询支付状态，对账单的形式
3：基于可靠消息(MQ)的方式；异步方式，通用性较强，拓展性较高
4：TCC编程式事务解决方案；严选，阿里蚂蚁金服自己封装的DTX
本文将围绕第三种解决方案进行讲解。

4：基于消息-实现分布式事务解决方案

在上述示例中，用户下单后会先调用订单系统，订单系统入库后，会再次调用库存系统，基于消息的事务解决方案，即将第二步的调用库存系统，改为发送异步的MQ消息，再由库存系统订阅该消息，消费即可，原理即如此。
这样做带来的问题？
1：如何保证消息100%成功投递？
思路如下：在调用MQ发送消息之前，先将此条消息插入至订单日志表中，标识消息未发送，当消息发送成功后，再根据MQ的异步回调通知策略，将该订单消息状态修改为已发送，同时，需要有定时任务，定期的去扫描订单表中超时未发送成功的消息，进行重发，如多次重发也未能成功发送，则需要根据重发次数，进行预警，由运维人员进行手动处理，如此，方能保证消息100%投递至broker上。

2：如果保证消息100被正确消费？
思路如下：首先要关闭MQ的自动确认机制，确保数据落地之后，再从MQ消息中删除此消息，其次，需要保证消息的幂等性，不能重复消费，通过redis缓存已经处理过的消息key，或者通过直接查库的方式进行判断，已经消费过的消息不能重复消费。

5：使用消息实现分布式事务的优点和缺点？

优点：
1：通用性强
2：拓展性强
3：方案成熟
缺点：
1：基于消息中间件，只适合做异步消息
2：消息处理会有延迟，业务上需要容忍

如何避免？
1：尽量避免分布式事务
2：尽量将非核心事务做成异步

以上就是基于消息实现分布式事务的解决方案的具体思路，具体的实现根据业务不同。处理方式也各有不同，这里就不贴代码了，读后如有收获，请点赞支持，谢谢。