前言
纯读书笔记，不为阅读量。。。
分布式的特点
- 分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。
- 分布性：多台计算机都会在空间上随意分布。
- 对等性：分布式系统中的计算机没有主/从之分。
- 并发性：同一个分布式系统中的多个节点，可能会并发地操作一些共享的资源。
- 缺乏全局时钟：分布式系统缺乏一个全局的时钟序列控制。
- 故障总是会发生：组成分布式系统的所有计算机，都有可能发生任何形式的故障。
- 分布式环境的问题
通信异常 网络分区（”脑裂”）：局部小集群独立完成原本需要整个分布式系统才能完成的功能（数据一致性挑战）。 三态：成功、失败、超时（请求没有发送到接收方、响应没有反馈给发送方）。 节点故障：组成分布式系统的服务器节点出现的宕机或“僵死”现象。
从ACID到CAP/BASE
ACID（Atomicity、Consistency、Isolation、Durability）
- 事务是由一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元，狭义上的事务特指数据库事务。
- 原子性：事务必须是一个原子的操作序列单元，要么全部成功执行、要么不执行。
- 一致性：事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行之前和执行之后，数据库都必须处于一致性状态。
- 隔离性：并发环境中，并发的事务是相互隔离的，一个事务的执行不能被其他事务干扰。
4个事务隔离级别：未提交读、已提交读、可重复读、串行化
- 持久性：一个事务一旦提交，对数据库对应数据的状态变更应该是永久性的。
CAP定理
- Consistency、Availability、Partition tolerance 最多能满足其中的两项。
- 一致性：数据在多个副本之间是否能够保持一致的特性。
- 可用性：有限时间内、返回结果。
- 分区容错性：遇到任何网络分区故障时，仍然保证对外提供满足一致性和可用性的服务。
BASE理论
- BASE是Basically Available、Soft state、Eventually consistent，是对CAP一致性和可用性权衡的结果。
- 核心思想：无法做到强一致性（Strong consistency），但可以根据自身业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
- 基本可用：响应时间上的损失、功能上的损失（降级页面）
- 弱状态：允许系统在不同节点的数据副本之间进行数据同步过程存在延时
- 最终一致性：经过一段时间的同步后，最终能够达到一个一致的状态，最终数据能够达到一致，而不是实时保证系统数据的强一致性。
一致性协议
- 协调者：统一调度所有分布式节点的执行逻辑
- 参与者：分布式节点
2PC（二阶段提交）
阶段一：提交事务请求
1、 事务询问：协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
2、 执行事务：各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中。
3、 各参与者向协调者反馈事务询问的响应。（YES or NO）
阶段二：执行事务提交
- 执行事务提交
1、 发送提交请求
2、 事务提交
3、 反馈事务提交结果
4、 完成事务
- 中断事务
1、 发送回滚请求
2、 事务回滚
3、 反馈事务回滚结果
4、 中断事务
- 优点：原理简单、实现方便。
- 缺点：同步阻塞、单点问题、脑裂、太过保守。
1、同步阻塞：每个参与者在等待其他参与者响应的过程中，将无法进行其他任何操作。 2、单点问题：协调者出现问题，则全局不可控。 3、数据不一致：协调者在发送Commit请求过程中发生崩溃，部分参与者进行事务提交，导致数据不一致。 4、太过保守：参与者故障没能返回响应，协调者只能通过超时机制处理。
3PC
将二阶段提交协议的“提交事务请求”过程一分为二，形成了由CanCommit、PreCommit和do Commit三个阶段组成的事务处理协议。
阶段一：CanCommit
- 事务询问：协调者向所有的参与者发送canCommit请求。
- 各参与者反馈canCommit请求。
阶段二：PreCommit
- 执行事务预提交（所有参与者反馈Yes）
发送preCommit请求 参与者收到preCommit请求后，执行事务操作，并将Undo和Redo信息记录到事务日志中 各参与者向协调者反馈事务执行的响应
- 中断事务（任何一个参与者向协调者反馈No、或者等待超时）
发送中断请求（给所有参与者发送abort请求） 中断事务（abort或者等待协调者的反馈超时）
阶段三：doCommit
- 执行提交
1、发送提交请求 2、事务提交 3、反馈事务提交结果 4、完成事务
- 中断事务（任意一个参与者反馈No、或者超时）
1、发送中断请求 2、事务回滚（利用undo信息执行回滚） 3、反馈事务回滚结果 4、中断事务
优点：降低参与者的阻塞范围，出现单点故障后继续达成一致。 缺点：参与者接收到PreCommit消息后，如果网络出现分区，协调者所在的节点和参与者无法进行正常的网络通信，该参与者依然会进行事务的提交，出现数据的不一致
参考
从paxos到zookeeper zh.wikipedia.org/wiki/三阶段提交