讨论范围

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

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

  • 一致性
  • 可用性
  • 分区容错性

CA，放弃P

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

CP，放弃A

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

AP，放弃C

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

1
2
3
4

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

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

分布式事务实现方式

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

可靠消息队列

通过持续重试的机制，来保证可靠性。最大努力交付
具体实现如下：
系统把最有可能出错的业务，以本地事务的方式完成后，通过不断重试的方式，来促使同个事务的其他关联业务来完成。

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

TCC

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

  1. Try，尝试执行阶段，完成所有业务可执行性的检查（保障一致性），并且预留好事务需要用到的所有业务资源（保障隔离性）
  2. Confirm，确认执行阶段，确认执行阶段，不进行任何业务检查，直接使用Try阶段准备的资源来完成业务处理
  3. Cancel，取消执行阶段，释放Try阶段预留的业务资源

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

缺点：

  • 业务侵入性较强

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

SAGA

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

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