zookeeper 学习笔记（一）分布式协议基础理论

分布式环境的各种问题：

1. 通信异常： 分布式节点之间的通信
2. 网络分区： 脑裂，分布式节点中一部分节点失去了通信。
3. 节点故障： 某个节点发生宕机现象
4. 三态： 超时、成功、失败

acid & cap & base ---理论

单机事务acid

acid： 事务的四种特性， 原子性、一致性、隔离性、持久性
隔离性： sql事务隔离级别，读未提交（另外一个事务操作的值都可以取到）、读已提交、可重复读（幻读）、串行化

分布式事务 cap理论

一致性
可用性
分区容错性

base理论

基本可用、弱状态、最终一致性

分布式一致性协议

两阶段提交协议

协议主要分为两个角色： 协调者、参与者
两个阶段： 投票阶段 - 提交阶段 或者 投票阶段-中断阶段
经常应用于关系型数据库的分布式一致性场景

投票阶段

1. 协调者向参与者发送执行事务的请求
2. 参与者开始执行事务，并记录相关日志，可回退。 
3. 参与者向协调者反馈执行结果

提交阶段 或者中断阶段

如果所有的事务执行结果都是成功的则：
1.  向参与者发送commit命令
2. 参与者执行commit，并释放资源
3. 向协调者反馈执行结果
4. 协调者收到ack之后，事务完成。 
如果有未执行成功的参与者，则： 
1. 发送事务回滚命令
2. 各个参与者回滚
3.反馈事务回滚结果
4. 完成事务中断

两阶段提交的缺点：

1. 整个流程有同步阻塞的问题，各个节点在等待协调者反馈结果过程中，一直占有资源
2. 协调者的角色很重要，一旦异常则整个流程崩塌。 （单点问题）
3. （数据不一致问题），发送commit之后如果协调者没有收到commit请求，则会出现数据不一致的情况。

三阶段提交协议

为了解决上面的问题提出了三阶段提交：
canCommit -> preCommit -> commit

canCommit

  1. 协调者向参与者发送canCommit命令
  2. 参与者根据自身情况，分析是否可提交，并不提交commit
  3. 向协调者返回结果yes

preCommit

1.  若返回的canCommit都为yes，则发送preCommit
2. 协调者收到preCommit之后提交，开始执行事务。
3. 将结果返回协调者

commit

1. 若返回成功，则发送commit命令
2. 各个协调者执行commit命令
3. 返回commit结果
4. 是否中断，完成执行 --如果协调者故障，超时自动提交

为什么要有三阶段提交： 降低了参与者的阻塞范围

ps: 个人体会不到三阶段比二阶段提交好在哪里。。