纯技术干货分享：分布式事务处理方式总结

TCC将整个事务分成两个阶段——try和commit/cancel。TCC整个流程具有三种角色——事务发起者、事务参与者、事务协调者。以上面的订单支付为例，采用TCC实现处理事务的流程如下：

• 第一阶段try，订单系统分别调用promotion和account两个系统，询问该用户是否有足够的积分和账户余额。为了防止资源争抢，在这个阶段会对资源进行锁定，即营销系统会锁住用户的10元积分，账务系统会锁住用户的90元账户余额。
• 如果在try阶段有任何一个参与者处理失败(例如用户积分不够10元或者用户的余额不够90元)，则事务发起方(订单系统)会通知事务协调组件，后者会通知所有的事务参与者cancel在try阶段锁定的资源。
• 如果在try阶段所有的参与者都处理成功，则事务发起方通知协调者commit这个事务，协调者会通知所有的参与者完成事务的commit。这时系统会完成真正的余额和积分扣减。2.2步是假设订单系统也要更新订单的状态。

但仅是这样处理还是有一致性问题，例如在第二阶段commit时如果发生宕机、网络抖动等异常情况，就可能导致事务处于“非最终一致”状态(参与者只执行了try阶段，没有执行第二阶段。或部分参与者第二阶段commit成功，部分参与者commit失败)。为了应对这种情况，需要增加事务日志，以便发生异常时回复事务。

可以利用DB这种可靠存储来记录事务日志。日志中应包含事务执行过程中的上下文、事务执行状态、事务的参与者等信息。事务日志可以由事务发起发负责记录，也可以交由事务协调方进行记录。

事务日志可以由主事务记录日志和从事务记录日志组成：

• 主事务记录日志 用于记录事务发起方信息以及事务执行的整体状态。
• 从事务记录日志 用于记录所有的事务参与者信息，以及每个参与者所属的从事务的执行状态。与主事务记录日志是一对多的关系。

有了事务日志后，就可以周期性的不断扫描事务日志，找到异常中断的事务。根据事务日志中记录的信息，推动剩余的参与者commit或者cancel，以便使整个分布式事务达到“最终一致性”。

下面是commit阶段发生异常时的事务补偿逻辑：

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!