一、功能

现实中并没有一种分布式事务的服务或者组件，能够帮助我们解决分布式系统下的数据一致性问题。更多的情况是，用分布式事务的理论来指导设计和开发，自行来解决数据一致性问题。

常用的分布式事务解决方案包括：2PC、3PC、TCC、Saga和本地消息表

二、2PC

二阶段比较适合适合解决分布式强一致性问题，例如创建订单和更新优惠券信息的场景，二者必须保持一致，否者容易被黑产利用。 二阶段指的是准备阶段和提交阶段。在准备阶段中，协调者给所有参与者发送“准备”命令，参与者将会执行除了提交数据库事务之外的所有工作，然后给协调者返回“准备”成功。当协调者收到所有参与者的“准备成功”的响应之后，进入提交阶段。此阶段协调者会给所有的参与者发送“提交指令”，然后每个协调者将会提交数据库事务。然后再给协调者返回“提交成功”的响应。协调者收到响应之后，会给客户端返回成功响应，流程结束。

缺点：

阻塞、协调者单点、脑裂等问题

适合场景：

只有在需要强一致、并且并发量不大的情况下，才考虑2PC

三、本地消息表

本地消息表适合解决分布式最终一致性问题，例如创建订单之后删除购物车的场景，在订单创建之后，晚几秒再删除购物车是可以接受的。订单服务在收到下单请求时，正常使用订单库的事务更新订单的信息，同时在执行过程中在本地记录一条消息。这个消息相当于一条日志，内容就是“清理购物车”这个操作。这个记录日志的流程和订单可以在一个库中，这样就保证了本地事务。然后再用一个异步的服务，读取本地日志，然后调用购物车的服务删除购物车。

四、3PC

3PC包括CanCommit,PreCommit,DoCommit三个阶段。CanCommit和PreCommit相当于2PC的准备阶段。3PC相比于2PC做了两个改进，一是事务参与者增加了超时机制，可以避免协调者宕机导致参与者长时间卡死的问题，另外，3PC在2PC之前增加一个询问阶段，这个阶段事务参与者可以去尝试锁定资源（但不等待），这样避免像2PC那样直接去锁定资源，而资源不可用的情况下，一直等待资源而卡住事务的情况。

五、TCC

TCC可以理解为业务层面的2PC，TCC同样分为Try和Confirm/Cancel 两个阶段，在Try阶段锁定资源，但不执行任何更新操作，Confirm阶段来执行所有更新操作并提交，如果失败进入Cancel阶段。Cancel阶段就是收拾烂摊子，把Confirm阶段做的数据更新都改回去，把Try阶段锁定的资源都释放。相比于2PC，TCC可以不依赖于本地事务，但是Cancel阶段的业务逻辑比较难实现。