分布式事务分类和模型

转载请附本文链接：https://blog.csdn.net/maxlovezyy/article/details/99707736

本篇简单介绍下事务的分类和模型，下一篇开始基于Percolator做一个系列，详细讨论分布式事务。

分类

刚性事务 完全遵循 ACID 规范，即数据库事务正确执行的四个基本要素：
•原子性（Atomicity）
•一致性（Consistency）
•隔离性（Isolation）
•持久性（Durability）

柔性事务 为了满足可用性、性能与降级服务的需要，降低一致性（Consistency）与隔离性（Isolation）的要求，遵循 BASE 理论：
•基本业务可用性（Basic Availability）
•柔性状态（Soft state）
•最终一致性（Eventual consistency）

同样的，柔性事务也部分遵循 ACID 规范：
•原子性：严格遵循
•一致性：事务完成后的一致性严格遵循；事务中的一致性可适当放宽，比如说事务失败，在回滚的过程中某个参与者回滚失败，那么并不阻塞其他事务读取数据，即使能读取到不一致的数据。但最终会保证这个参与者回滚成功。
•隔离性：并行事务间不可影响；事务中间结果可见性允许安全放宽，类似于一致性中提到的情况。
•持久性：严格遵循

模型

1. 2PC(Prepare-Commit/Abort)
   标准2PC即第一阶段通知各个事务涉及到的参与者准备，如果都准备OK就进入到第2阶段提交。除网络问题外，如果准备过程中有任何一个参与者失败则回滚事务，如果提交发起失败则也回滚事务。一旦出现网络问题(包括宕机导致的网络问题)则相应的等待应答方死等，期间占着资源。
   为什么需要2PC？这里就不得不谈分布式下的1PC。1PC的实现很直观，就是发起者直接把操作和数据发送给各个参与者，参与者一旦执行了就必然可能不满足Atomicity、Consistency和Isolation，因为数据可能分布在不同的存储分区之中，没法通过1PC做到原子性。而2PC通过prepare阶段预写数据，commit阶段提交数据，也可能abort事务，这里的每一步都可以通过锁去保证ACI，比如Percolator的primary。
2. 3PC
   3PC相比2PC增加了超时机制以及资源锁定预留阶段，其虽然解决了标准2PC的阻塞等问题，但是增加了latency，并且依然存在数据不一致问题，而且其超时自动提交机制很鸡肋，数据不一致的来源之一，基本上没什么应用的地方，以后就忽略3PC了。对于2PC和3PC存在的宕机等问题导致出问题的场景，根本上还是要靠分布式去保证，比如逻辑上通过Raft/Paxos构造多副本，物理上通过disk、server、rack、AZ、region等做隔离。
3. TCC(Try-Confirm-Cancel)
   TCC其实就是2PC的一种特化实现，Percolator一样也是2PC的一种特化实现。TCC的try阶段相当于2PC的prepare阶段，confirm相当于2PC的commit，cancel相当于2PC的abort。2PC的实现会与具体系统关联性较强，也就是对内高内聚，对外的表现更加透明、低耦合。而TCC设计上讲究的是让业务做更多，业务可以做决策，TCC本身只是一个框架，资源层不同的参与事务的子系统只要实现TCC的接口即可，业务基于TCC框架调用接口就能实现子系统间的事务。一般TCC的子系统接口会具有幂等性或者支持事务，可以方便业务实现。由于TCC把2PC的决策过程放到了业务层中，而资源层子系统又会暴露较多信息给业务，这样业务其实就可以更好地跟踪事务状态以作出决策。比如对于commit超时这一结果的判定，2PC的话只能通过业务读取结果去判定事务状态，而TCC业务可以直接通过查看事务id或者查看相应事务id在各个子系统中的状态去判定事务状态。
4. 消息表
   基于MQ的方式就是消息表的一种具体特化实现，这种机制的事务显而易见就是异步的，遵循的不是ACID而是BASE理论，讲究最终一致性，某些case下的弱一致性。通过MQ去做解偶，并利用MQ的可靠性等机制简化实现。