| 导读 | 分布式事务往往是服务化的痛点，很多场景通过业务避免了分布式事务，但是还是存在一些场景必须依赖分布式事务，下面来讲讲如何处理分布式事务 |
解决分布式事务问题的方法有很多种，网上有很多博客也提供了各种解决方案。总结起来，一般可以分为以下两种方式： 1. 两阶段提交（Two-Phase Commit，简称2PC）：这是一种常见的分布式事务解决方案。在这种方法中，协调者节点负责协调参与者节点的操作，并确保所有节点在提交或者回滚时达成一
刚性分布式事务和两阶段提交是一种实现强一致性的机制。 刚性分布式事务是指在分布式系统中，多个参与者节点执行的一系列操作需要保证原子性，即要么全部成功，要么全部失败。这种机制要求所有参与者节点在事务执行过程中遵循相同的协议，通过协调者节点的指导来实现事务的
柔性分布式事务是一种在分布式系统中处理事务的方法。它采用最大努力提交的策略，即尽最大努力去完成事务的提交，但是也允许部分操作失败。在柔性分布式事务中，通常会使用TCC（Try-Confirm-Cancel）模式来实现事务的管理。TCC模式将事务分解为三个阶段：尝试（Try）、确认（Confirm）和取消（
首先解决分布式事务前提保障：接口必须幂等性，防止消息重复发送对业务影响
二 可靠消息系统设计（这个感觉不错比较简单，就拿来分享下）
如上图
开始执行 比如：
try{
if(prepare()) { //预发送阶段
doService(); //执行业务逻辑
updateMsgStatus();//更新消息为确认状态
}
}
1 预发送消息，try阶段，如果预发送消息失败了，业务还未执行，所以 系统A，B还是一致性的 不需要处理
这一点容易理解
2 预发送消息成功了，开始执行业务逻辑。执行成功 更新预发送消息转态为确认发送。如果 此时 业务逻辑执行失败了，那预发送消息就不会跟新状态，此时消息确认系统就开启工作，到业务系统1上回查此消息状态，此时发现业务执行失败了，就更新预发送状态至失败状态。
3 如果此时 业务执行成功了消息也被更新成确认发送了 那就ok 完美。如果消息更新失败，还是由消息确认系统回查转态 更新此消息被删除状态还是确认发送状态。
4 消息者开始消费
1> 比如消费失败了，此时产生不一致， 消息恢复系统检测消息状态，重新发送消息
2>如果执行业务失败了，此消息也就不会被确认了，还是由消息恢复系统检测消息状态，重新发送消息
3>如果ask失败了，还是以上逻辑重新发送上诉重新发送当然有次数限制，不能一直发送，超过最大次数就要进入死信队列，等待人工干预了
4> ask成功，消息也就成功消费了，完美，解决了消息可靠服务
三 努力提交这个比较简单 ，将失败的消息重复提交，实时性比较弱的一些场景，确保消息推送成功。
比如交易完成推送第三方消息。 此时可以使用努力提交
以上是探讨实现可靠的消息服务的详细内容。更多信息请关注PHP中文网其他相关文章！
