在微服务体系下，我们的应用被分割成多个服务，每个服务都配置一个数据库。如果我们的服务划分的不够完美，那么为了完成业务会出现非常多的跨库事务。即使按照 DDD 的原则来切分服务还是免不了有的业务场景需要多个业务同时提交成功或者同时回滚的场景。比如会员使用积分下订单这个场景，那么会员服务的积分扣减需要跟订单下单成功同时完成。如果下单成功，但是扣减积分接口失败，那么就会造成数据的不一致性。这个时候我们就需要使用分布式事务来保证数据的一致性。
由于分布式事务要介绍的东西比较多，这一篇只介绍 2PC、3PC 的基本概念，所以 .net 相关的内容大概也只会出现在标题上一次，笑哭。
什么是 2PC
2PC 既 Two-phase Commit ，中文翻译为二阶段提交。2PC 要求每个事务的参与方都把一个事务抽象成2个阶段。下面大概分析下 2PC 事务的流程。
首先提出2个概念：
- 参与方
分布式事务中所有需要同时进入事务的业务方。 - 协调器
分布式环境下为了对多个事务参与方进行统一的调度管理，我们需要一个调度器。
阶段一
事务开始后，协调器下达事务开始的命令，每个参与方收到命令后开始执行准备阶段（Prepare phase），所谓准备阶段就是执行本地事物，这个时候资源被锁定，但是不进行提交。如果这个阶段没有发生异常，那么参与方会通知协调器“执行成功”。如果某个参与方在这个阶段失败了，那么同样通知协调器“执行失败”，协调器会给所有参与方发布回滚的命令。参与方在收到“回滚”命令后执行回滚操作。
阶段二
如果所有的参与方在阶段一全部响应成功，那么协调器就会给每个参与方发布执行提交操作的命令。参与方收到提交命令后开始尝试进行事务提交。如果事务提交成功，参与方会通知协调器“提交成功”。待到所有的参与方全部回复“提交成功”，那么本次事务成功执行。
到这里我们可以看到 2PC 模型跟数据库的事务模型是高度契合的，所以 2PC 经常用来把多个数据库事物包装成一个分布式事务的场景。事实上大多数数据库如：oracle，mysql等自己已经实现了基于XA协议的2PC 事务。
2PC 的问题
- 在一阶段，假设参与方A执行事务成功并通知了协调器，参与方B执行失败，由于网络的问题一直无法上报给协调器，这个时候会造成参与方A事务一直是等待提交状态，阻塞整个业务。这个时候就需要引入超时机制，在一定时间内没收到协调器的指令后直接回滚事务。
- 在一阶段，假设参与方A执行事务成功并通知了协调器，参与方B执行成功，由于网络的问题一直无法上报给协调器，这个时候会造成参与方A、参与方B事务一直是等待提交状态，阻塞整个业务。这个时候不光在参与方A一侧需要引入超时机制，在参与方B同样需要进入超时机制来自动回滚事务。
- 在二阶段，如果参与方A提交成功，参与方B因为某些原因提交失败，或者是服务器宕机或者是网络原因B一致没有收到提交的指令，这个时候就会造成数据不一致，这种情况 2PC 几乎没有补偿能力，只能依靠后期手动修复数据。
- 如果协调器在一阶段中间挂了，那么跟以上1、2情况类似，需要通过超时机制来补偿。
- 如果协调器在二阶段中间挂了，比如只给参与方A发送了提交请求，那么就会造成以上问题3类似的问题，造成数据不一致。
- 2PC 因为依赖数据库本地事务，我们知道事务一旦开启就会阻塞后面的业务执行。所以该方法在并发高的情况下会有比较大的性能问题。而且他所阻塞的时间远远高于单机事务，因为它所耗的时间取决于执行时间最长的那个参与方所执行的事务。
3PC
由于 2PC 的众多问题，又有人发明了 3PC 事务。
3PC 事务是对 2PC 的一次改进：
- 首先引入了超时机制避免事务长时间阻塞。
- 3PC 在 2PC 的 Prepare phase 阶段之前又加入了一个阶段叫做 CanCommit 阶段。现在3个阶段分别是：CanCommit、PreCommit、DoCommit 。后两个阶段大致可以映射到 2PC 的一阶段跟二阶段。那么CanCommit 阶段是干嘛的呢？CanCommit 只是一次预检，协调器先问一下各个参与者是否可以进行事务，同时也校验一下当前的网络是否正常，参与者服务器有没有宕机。经过这一次校验后，至少可以比 2PC 安全一点，减少因为当前网络故障服务宕机带来的故障的概率。但是 3PC 任然无法完全解决问题，在 DoCommit 命令发布后，依然有可能部分参与者提交成功，部分失败，2PC 数据不一致的问题 3PC 依然无法避免。
我们来理一下 TCC 事务。本次还是讲解 TCC 的原理跟 .NET 其实没有关系。
TCC
- Try 准备阶段，尝试执行业务
- Confirm 完成业务
- Cancel 回滚准备阶段的业务
TCC 事务其实是 2PC 的一个扩展。上一次我们说了 2PC ，在二阶段进行事务提交。因为 2PC 基本上是利用数据库的
事务能力进行 commit ，其实这里还有可能出现一种 rollback 情况。 TCC 就是把 2PC 的二阶段细化了，拆分成了 Confirm 跟 Cancel 两个步骤。TCC 是 2PC 的一次进化，TCC 拆分二阶段后已经不局限于数据库事物了，它可以适用于非数据库事物的场景。因为我们的 Cancel 阶段可以进行更加复杂的回滚能力，业务补偿能力。TCC 可以认为是业务层面的2PC 。
下面我们以使用客户积分兑换房间为示例说明一下 TCC 事务。
- Try
为完成 TCC 事务的 Try 阶段，我们需要在房间上增加一个状态字段“是否锁定”，一旦锁定，其它订单就没有办法预定这间房间。同样我们需要在用户积分表上增加一个字段“冻结积分”，如果涉及到并发可能要单独拉一张表出来。这里简化一点就加个字段吧。
Try阶段开始：订单服务把房间设置为锁定状态；积分服务把用户的积分减去消耗的积分同时把消耗的积分暂存在冻结字段上。 - Confirm
如果一阶段都提交成功了，那么所有的服务都开始进入 Confirm 阶段。订单服务把房间状态更改为“已预定”状态；积分服务把冻结的积分清0。这样整个事务都成功完成了。 - Cancel
如果一阶段某个服务没有 Try 成功，那么所有的服务都要进入Cancel阶段。比如订单服务锁定房源成功了，积分冻结的时候失败了，那么订单服务要进入 Cancel 阶段，把房间的的锁定状态取消，从新释放出来。如果锁定房源失败了，积分扣减成功了，那么 Cancel 阶段就要把扣减的积分给加回去。
TCC 的一些问题
异常
如果 Confirm 阶段出现异常，TCC 管理器会不断的重试这个阶段，直到成功。因为理论上认为只要 Try 是成功的，那么 Confirm 阶段一定会成功。因为所需要的资源已经在 Try 阶段冻结了。如果 Cancel 阶段出现异常，那么 TCC 管理器也会不断的重试这个阶段来解除冻结的资源。
幂等
因为 TCC 有重试机制，所以所有的接口都需要实现幂等，避免多次调用对业务数据产生错误。比如多次扣款，多次下订单等。
并发问题
因为 TCC 事务在 Try 阶段对资源是完全的提交状态，并没有像 2PC 那样使用数据库事物来对资源进行锁定，所以在并发的时候对资源的修改要格外注意。在处理业务的时候要时刻注意锁定的资源对业务造成的一影响。
允许空取消
TCC 事务在一阶段 Try 的时候失败要运行进行 Cancel 提交。这时候 Cancel 其实是不需要做任何补偿操作，我们称之为空取消。这个时候也要注意，在编写 Cancel 操作的时候要时刻注意到底有没有完成 Try 操作，如果没有完成 Try 操作则要进行空取消。
预防悬挂
TCC 按流程上来说是不会出现悬挂情况的。但是有一种特殊情况会造成资源的悬挂。按照正常流程我们的 Try 阶段总是先于 Cancel 执行的。但是由于网络拥堵的问题造成 Try 调用延迟了，TCC 管理器在一定时间没收到 Try 成功响应后会发送 Cancel 调用，这个 Cancel 就有可能在 Try 之前先被调用了。在 Cancel 执行成功后， 这个 Try 请求调用才到达服务，这个时候如果 Try 被执行成功，那么就会造成资源的悬挂。所以当编写 Try 代码的时候同意需要注意是不是已经调用过 Cancel 操作了。
总结
TCC 事务是 2PC 的一种升级。TCC 相对于 2PC 不再依赖于本地数据库事物能力，它可以使用于应用层面的事务。它把 2PC 的提交跟回滚操作明确的抽象成 Confirm 跟 Cancel 。TCC 事务在逻辑上是比较清晰的。但是 TCC 使用起来也有不方便的地方，就是它对代码入侵比较强，比较繁琐。每个业务都要强制拆分成3个方法。而且还要还要注意幂等，空取消，悬挂等问题。
以上简单介绍了 2PC、3PC 分布式事务的原理。我们可以看到 2PC 在理想情况下是可以保证数据一致性的。但是在复杂的生产环境下服务器宕机、网络故障的情况时有发生，最终导致数据的不一致，并且 2PC 的性能也差强人意。3PC 虽然改进了 2PC 的一些缺点，但是仍然没有解决掉最致命的数据不一致的问题、以及性能的问题。所以 2PC、3PC 并不是分布式事务的首选方案。那么下期我们将继续这个话题，继续介绍 TCC 分布式事务。
NET Core with 微服务 - 什么是微服务
.Net Core with 微服务 - 架构图
.Net Core with 微服务 - Ocelot 网关
.Net Core with 微服务 - Consul 注册中心
.Net Core with 微服务 - Seq 日志聚合
.Net Core with 微服务 - Elastic APM
.Net Core with 微服务 - Consul 配置中心
.Net Core with 微服务 - Polly 熔断降级
.Net Core with 微服务 - 分布式事务 - 2PC、3PC