分布式技术原理与算法解析之分布式事务 学习笔记 （5）
分布式事务（distributed transaction）
事务：包含一系列操作的、一个有边界的工作序列，有明确的开始和结束标志，且要么被完全执行，要么完全失败（all or nothing）。
定义：在分布式系统中运行的事务，由多个本地事务组合而成。（wiki）A distributed transaction is a **database transection **in which two or more network hosts are involved.
问题：为什么wiki上要指定是数据库事务？
特性：ACID（Atomicity, consistency, isolation, durability）
- 原子性（Atomicity）： 事物的最终状态只有两种，全部执行成功和全部不执行。由于原子性的存在，事务发生的过程无法被其他的客户端监测到。前一刻还没发生，下一刻已经完成。
- 一致性（consistency）： 事务使系统从一个正确的状态,迁移到另一个正确的状态。
- 隔离性（Isolation）: 系统中有多个事务并发执行时，多个事务不会相互干扰。
- 持久性（Durabiliy）: 完成一个事务引发的数据库更新会被永久保存。即使宕机或系统崩溃，也能够恢复到事务完成时的状态。
ACID中的C是强一致性：所有操作均执行成功，才提交最终结果，以保证数据一致性和完整性。为了适应复杂业务，出现了BASE理论，使用最终一致性替代强一致性。
具体实现：解决分布式环境下，组合事务的一致性问题。
-
基于XA协议的二阶段提交方法（2PC）
- XA协议：一个分布式事务协议，规定了事务管理器和资源管理器接口。
- 事务管理器：协调者，负责本地资源的提交和回滚；资源管理器：参与者，通常由数据库实现
- 实现步骤：
- 投票（voting）
- step1: 协调者向参与者发起执行操作的CanCommit请求，并等待响应；
- step2：参与者收到请求后，执行请求中的事务操作，记录日志信息但不提交；
- step3：待参与者执行成功，则向协调者发送“Yes”消息，表示同意操作；若不成功，则发送“No”消息，表示终止操作
- 提交（commit）
- step1: 若协调者收到的都是“Yes”消息，则向参与者发送“DoCommit”消息，参与者会完成剩余的操作并释放资源，然后向协调者返回“HaveCommitted”消息
- step2：如果协调者收到的消息中包含“No”消息，则向所有参与者发送“DoAbort”消息，此时发送“Yes”的参与者则会根据之前执行操作时的回滚日志对操作进行回滚，然后所有参与者会向协调者发送“HaveCommitted”消息；
- step3：协调者接收到“HaveCommitted”消息，就意味着整个事务结束了。
- 投票（voting）
- 缺点：同步阻塞 数据不一致
-
三阶段提交协议方法（3PC）
-
特点：引入超时机制和准备机制，解决2PC的同步阻塞和单点故障问题
-
cancommit+precommit+docommit
-
基于消息的最终一致性方法
-
解决问题：2PC和3PC的两个缺点：1）需要锁定资源；2）数据不一致；
在 eBay 的分布式系统架构中，架构师解决一致性问题的核心思想就是：将需要分布式处理的事务通过消息或者日志的方式异步执行，消息或日志可以存到本地文件、数据库或消息队列中，再通过业务规则进行失败重试。这个案例，就是使用基于分布式消息的最终一致性方案解决了分布式事务的问题。
- 特点：不强调强一致性，而是最终一致性。设计了中间件进行缓冲，多个节点之间并不直接交互
- BASE理论：BASE 理论包括基本可用（Basically Available）、柔性状态（Soft State）和最终一致性（Eventual Consistency）。
- 基本可用：分布式系统出现故障的时候，允许损失一部分功能的可用性。比如，某些电商618 大促的时候，会对一些非核心链路的功能进行降级处理。
- 柔性状态：在柔性事务中，允许系统存在中间状态，且这个中间状态不会影响系统整体可用性。比如，数据库读写分离，写库同步到读库（主库同步到从库）会有一个延时，其实就是一种柔性状态。
- 最终一致性：事务在操作过程中可能会由于同步延迟等问题导致不一致，但最终状态下，数据都是一致的。
