架构探索：事务处理三

讨论范围



分布式事务:多个服务同时访问多个数据源的事务处理机制



CAP（以下特性只能2选1）



• 一致性

• 可用性

• 分区容错性



CA，放弃P



主流RDBMS集群通常是采用放弃分区容错性的工作模式，例如RAC集群采用共享磁盘的方式来避免网络分区的出现。每个节点都有SGA,UNDO LOG 和REDO LOG，但各节点共享同一份数据文件和控制文件



CP，放弃A



先假设一旦出现网络分区，节点之间信息的同步可以无限的延长。从而采用2PC/3PC手段来，同时获取分区容错性和一致性。



AP，放弃C



目前大多数分布式系统设计的主流选择，大多数的NoSQL库和支持分布式的缓存都是AP系统。




ACID CAP中讨论的一致性为强一致性，或线性一致性

牺牲了C的AP,又想尽可能获取正确结果的行为，称为弱一致性，它的特例：最终一致性。




分布式事务实现方式



最终一致性的实现方式：可靠消息队列、TCC、SAGA



可靠消息队列



通过持续重试的机制，来保证可靠性。最大努力交付

具体实现如下：

系统把最有可能出错的业务，以本地事务的方式完成后，通过不断重试的方式，来促使同个事务的其他关联业务来完成。



缺点：没有任务隔离性，在电商场景中可能导致的问题就是超售



TCC



TCC天生适合用于需要强隔离性的分布式事务中。他需要先把资源给冻住，然后执行后续的操作。



1. Try，尝试执行阶段，完成所有业务可执行性的检查（保障一致性），并且预留好事务需要用到的所有业务资源（保障隔离性）

2. Confirm，确认执行阶段，确认执行阶段，不进行任何业务检查，直接使用Try阶段准备的资源来完成业务处理

3. Cancel，取消执行阶段，释放Try阶段预留的业务资源



一般通过事务中间件（阿里seata)来完成



缺点：

• 业务侵入性较强



如果出现不合作（不可控）的第三方，往往在第一步Try就无法施行了。



SAGA



引入事务补偿的机制来代替回滚的操作。



实现原理：将大事务拆解为N个小事务，并且为每个事务设计一个对应的补偿机制