1 关于分布式系统

1.1 介绍

我们常见的单体结构的集中式系统，一般整个项目就是一个独立的应用，所有的模块都聚合在一起。明显的弊端就是不易扩展、发布冗重、服务治理不好做。

所以我们把整个系统拆分成若干个具备独立运行能力的计算机服务的集合，而从用户的角度看，是一个完整的系统，但实际上，它是一个分布式服务的集合。

分布式系统主要从以下几个方面进行裂变：

• 应用可以从业务领域拆分成多个 module，每个 module 还可以再按项目结构分成接口层、业务层、数据访问层；当然也可以按访问入口进行拆分，如移动、桌面、Web 端访问的是不同的类型接口服务；

• 数据库可以按业务类型拆分成多个实例，还可以对单库或单表进行分库分表；参考我的这篇《分库分表》

• 增加一些中间件，来保证分布式系统的高可用，如分布式缓存、搜索服务、文件服务、消息队列、非关系型数据库等中间件；

1.2 优势和不足

分布式系统可以解决集中式不便扩展的弊端，提供了便捷的扩展性、独立的服务治理，并提高了安全可靠性。随着微服务技术（Spring Cloud、Dubbo） 以及容器技术（Kubernetes、Docker）的大热，分布式技术发展非常迅速。

不足的地方：分布式系统虽好，但也带来了系统的复杂性，如分布式事务、分布式锁、分布式 session、数据一致性等都是现在分布式系统中需要解决的难题，虽然已经有很多成熟的方案，但都不完美。

分布式系统的便利，其实是牺牲了一些开发、测试、运维 成本低，让工作量增加了，所以分布式系统管理不好反而会变成一种负担。

2 分布式事务

分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

分布式场景下一次完整的操作由不同的 action 组成，这些 actions 可能分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些 action 要么全部成功，要么全部失败。保证单个完整操作的原子性。

2.1 CAP 理论

CAP 定理（也称为 Brewer 定理），指的是在分布式计算环境下，有 3 个核心的需求：

1、一致性（Consistency）：再分布，所有实例节点同一时间看到是相同的数据

2、可用性（Availability）：不管是否成功，确保每一个请求都能接收到响应

3、分区容错性（Partition Tolerance）：系统任意分区后，在网络故障时，仍能操作

CAP 理论告诉我们，分布式系统不可能同时满足以下三种。最多只能同时满足其中的两项，因为很多时候 P 是必须的, 因此往往选择就在 CP 或者 AP 中

2.2 CAP 的组合情况

CA: 放弃分区容错性。非分布式架构，比如关系数据库，因为没有分区，但是在分布式系统下，CA 组合就不建议了。

AP: 放弃强一致性。追求最终一致性，类似的场景比如转账，可以接受两小时后到账，Eureka 的注册也是类似的做法。

CP: 放弃可用性。zookeeper 在 leader 宕机后，选举期间是不提供服务的。类似的场景比如支付完成之后出订单，必须一进一出都完成才行。

结论：在分布式系统中 AP 运用的最多，因为他放弃的是强一致性，追求的是最终一致性，性价比最高

2.3 数据一致性模型

分布式系统通过同步数据的副本来提高系统的可靠性和容错性，而且数据的不同的副本，合理会存在不同的机器或集群上。

强一致性：当用户的操作完成之后，会立马被同步到不同的数据副本中，后续其他任意请求都会获得更新过的值。这种对用户的可见性是最友好的，能始终保证读到正确的值。根据 CAP 理论上，这种实现需要牺牲可用性。

弱一致性：系统并不保证所有请求的访问都会获得最新值。数据写入成功之后，不承诺立即可以读，也不承诺具体多久之后可以读到，甚至读不到。在请求获得数据更新的这段时间，我 i 们称之为“不一致性窗口”。

最终一致性：是弱一致性的一种。系统保证在没有后续更新的前提下，系统最终会返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。

常见的事务处理机制：

1、Master-Slave 复制：写请求由 Master 负责，写入 Master 后，由 Master 同步到 Slave 上。

异步同步，所以是弱/最终一致性。

2、Master-Master 主主复制

异步同步，最终的一致性，多个节点间需要序列化协议。

2.4 分布式事务应用场景

2.4.1 典型支付场景

这是最经典的场景。支付过程，要先对买家账户进行扣款，同时对卖家账户进行付款，

像这类的操作，必须在一个事务中执行，保证原子性，要么都成功，要么都不成功。但是往往买家的支付平台和卖家的支付平台不一致，即使都在一个平台下，所属的业务服务和数据服务

（归属不同表甚至不同库，比如卖家中心库、卖家中心库）也不是同一个。针对于不同的业务平台、不同的数据库做操作必然要引入分布式事务。

2.4.2 在线下单

同理，买家在电商平台下单，往往会涉及到两个动作，一个是扣库存，第二个是更新订单状态，库存和订单一般属于不同的数据库，需要使用分布式事务保证数据一致性。

2.4.3 跨行转账

跨行转账问题也是一个典型的分布式事务，用户 A 同学向 B 同学的账户转账 500，要先进行 A 同学的账户-500，然后 B 同学的账户+500，既然是不同的银行，

涉及不同的业务平台，为了保证这两个操作步骤的一致，分布式事务必然要被引入。

2.5 常见分布式一致性保障（分布式事务解决方案）

2.5.1 XA 两阶段提交协议

两阶段提交协议（Two-phase commit protocol），简称 2PC，过程涉及到协调者和参与者。

它是一种强一致性设计，引入一个事务协调者的角色来协调管理各参与者的提交和回滚，二阶段分别指的是准备（投票）和提交两个阶段。

第一阶段（准备阶段）

为事务协调者的节点会首先向所有的参与者节点发送 Prepare 请求。

在接到 Prepare 请求之后，每一个参与者节点会各自执行与事务有关的数据更新，写入 Undo Log（撤销）和 Redo Log（重做）。

如果参与者执行成功，暂时不提交事务，而是向事务协调节点返回“完成”消息。当事务协调者接到了所有参与者的返回消息，整个分布式事务将会进入第二阶段。

假如在第一阶段有一个参与者返回失败，那么协调者就会向所有参与者发送回滚事务的请求，即分布式事务执行失败。如下图:

第二阶段（提交阶段）

如果事务协调节点在之前所收到都是正向返回，那么它将会向所有事务参与者发出 Commit 请求。

接到 Commit 请求之后，事务参与者节点会各自进行本地的事务提交，并释放锁资源。当本地事务完成提交后，将会向事务协调者返回“完成”消息。

当事务协调者接收到所有事务参与者的“完成”反馈后，整个分布式事务完成。

当有一个 Commit 不成功，那其他的应该也是提交不成功的。

2.5.2 XA 三阶段提交

三阶段提交：CanCommit 阶段、PreCommit 阶段、DoCommit 阶段，简称 3PC

三阶段提交协议（Three-phase commit protocol，3PC），是二阶段提交（2PC）的改进版本。与两阶段提交不同的是，三阶段提交有两个改动点：

引入超时机制。同时在协调者和参与者中都引入超时机制。

在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的。

即 3PC 把 2PC 的准备阶段再次一分为二，这样三阶段提交就有 CanCommit、PreCommit、DoCommit 三个阶段。当 CanCommit、PreCommit、DoCommit

的任意一个步骤失败或者等待超时，执行 RollBack。

利用消息中间件来异步完成事务的后半部分更新，实现系统的最终一致性。这个方式避免了像 XA 协议那样的性能问题。

下面的图中，使用 MQ 完成事务在分布式的另外一个子系统上的操作，保证了动作一致性。

2.5.4 TCC 事务

TCC 事务是 Try、Confirm、Cancel 三种指令的缩写，其逻辑模式类似于 XA 两阶段提交，但是实现方式是在代码层面人为实现。2PC 和 3PC 都是数据库层面的，而 TCC 是业务层面的分布式事务。

分布式事务除了上面提到的数据库层面的操作外，还包括发送短信、邮件这种业务操作等，这时候 TCC 就有用武之地了！

图中就是一个典型的分布式系统的原子性操作，涉及 A、B、C 三个服务的执行。如果有一个服务 try 出问题，整个事务管理器就执行 calcel，如果三个 try 都成功，才执行 confirm 做正式提交。

2.5.5 最终补偿机制，同于 MQ 事务

最后使用补偿机制做最后的一致性保障，MQ 方案尽量使用补偿机制进行保障。