分布式系统之事务

      数据库事务（Transaction）是并发控制的基本单位。所谓的事务，它是一个操作序列，由一条或者多条sql语句组成，这些操作要么都执行，要么都不执行，它是一个不可分割的工作单位。事务具有4个基本属性：A(原子性)、C(一致性)、I(隔离性)、D(持久性)。

      随着现在互联网用户规模越来越大，业务场景越来越复杂，单个数据库已经不能支撑上层业务应用。分布式微服务的架构模型的出现，使得应用越来越专注于自身业务，每次交互涉及到的调用链路越来越长，节点越来越多。如何控制每个节点状态的一致性，已经成为一个共性问题，金融场景中保证分布式环境下账务的一致性更为迫切。针对这个问题业内抽象出一些模型，比如2PC、3PC、TCC、Saga等。

      2PC，是Two-Phase Commit的缩写，即二阶段提交。将事务的提交过程分成了两个阶段来进行，准备阶段提交事务请求，提交阶段执行事务提交。准备阶段，协调者向所有参与者发送事务内容，各参与者执行事务操作并记录redo和 undo日志，各参与者向协调者反馈事务是否可以执行。提交阶段，若所有参与者反馈可以执行则进入正向提交流程，协调者向所有参与者发出commit请求，参与者执行事务提交然后释放资源，所有参与者向协调者发送Ack消息，协调者接收到所有参与者的Ack消息后完成事务。若有参与者反馈不可以执行或者在超时时间内无法收到所有参与者的响应则进入回滚流程，此时协调者向所有参与者发出rollback请求，参与者收到rollback请求后通过undo日志回滚事务并释放资源，参与者完成事务回滚后向协调者发送Ack消息，协调者接收到所有参与者的Ack消息后完成事务中断。

       3PC，是Three-Phase Commit的缩写，即三阶段提交。3PC是对2PC的改进，即将2PC的提交阶段分成了准备提交和执行提交。这样事务提交过程分成了三个阶段，询问阶段，准备提交阶段，执行提交阶段。询问阶段，协调者向所有参与者发送消息询问是否可以执行事务，各参与者接收到消息后向协调者返回是否可以执行。准备提交阶段，协调者向所有参与者发出准备提交请求，各参与者收到请求后记录redo和undo日志执行事务操作，各参与者向协调者反馈Ack消息。若参与者反馈NO响应，则协调者向所有参与者发出取消请求，参与者接收到取消请求或者超时未收到响应都会中断事务。执行提交阶段，协调者向所有参与者发送提交请求，参与者接收到请求后执行提交操作然后释放资源，参与者完成事务提交后向协调者发送Ack消息，协调者接收到所有参与者反馈的Ack消息后完成事务。若有任一参与者返回NO响应或者协调者超时未收到响应，协调者都会向所有参与者发送取消请求，参与者收到取消请求后通过undo信息回滚事务并在回滚之后释放资源，参与者完成事务回滚后向协调者发送Ack消息，协调者收到所有参与者反馈的Ack消息后中断事务。

      TCC，是Try-Confirm-Cancel的缩写，是服务化的两阶段提交协议。业务开发者需要实现这三个服务接口，第一阶段服务由业务代码编排来调用 Try 接口进行资源预留，所有参与者的 Try 接口都成功了，事务管理器会提交事务，并调用每个参与者的 Confirm 接口真正提交业务操作，否则调用每个参与者的 Cancel 接口回滚事务。

       Saga 是一种补偿协议，在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

       2PC、3PC属于数据库XA事务，要求数据库必须采用串行化的事务隔离级别，针对现在高并发的场景不太适用。TCC、Saga采用的是业务补偿方式，属于柔性事务，并发性相对高一些，事务的ACID特性不能很好地保证。分布式系统CAP和BASE理论，证明不会存在既保证数据强一致性，又保证高并发的通用模型。我们可以封装一套底层组件，基于这套组件既能实现强一致的XA事务，又能实现TCC、Saga这种柔性事务，还可以根据组件和业务场景实现个性化的分布式事务，目前蚂蚁开源的Seata也是这种思路。