当前课程知识点：大数据平台核心技术 > 实践1：通过两阶段提交协议完成数据上传 > 两阶段提交与三阶段提交 > 两阶段提交与三阶段提交(主讲人：冯骁)
下面我来讲一下
跟这次实践相关的
两阶段提交和三阶段提交
两阶段提交的缩写
又叫做2PC
中文叫做两阶段提交
在分布式系统中
每个节点虽然可以知晓
自己的操作时
到底是失败还是成功
但是没有办法知道
其他节点的操作
到底是成功还是失败
所以当一个事务
跨越多个节点时
为了保证事务的ACID特性
往往需要引入一个协调者
来统一的控制所有的节点
所有节点的操作结果
并最终指示这些节点
是要把操作结果
真正的提交
比如说我们在写数据时的
commit（00：56）操作
还是要把之前的操作回滚
第一阶段
协调者会问
所有的参与者节点
是不是能够提交操作
所有的参与者
开始事务执行的准备工作
比如说
对资源上锁
预留资源等等
然后参与者响应协调者
如果准备工作成功
那么就返回可以提交
否则就返回拒绝提交
第二阶段
如果所有的参与者
都返回可以提交
那么协调者
就会向所有的参与者
发送正式提交的命令
参与者正式完成提交
并且释放之前所有的资源
然后返回 完成
协调者收集各个节点
完成回应后
结束这个事务
如果有任何一个参与者
回应拒绝提交
那么协调者向所有的参与者
发送回滚操作
并且释放所有的资源
然后返回
回滚完成
协调者收集各个节点的
回滚回应后
取消这个事务
我们可以看到
两阶段提交
其实就是第一阶段做投票
第二阶段做决定的一个算法
同时也可以看到
两阶段提交
是一个强一致性的算法
下面我们通过一个简单的动画
来讲解一下
两阶段提交的过程
在阶段一
所有的参与者都会向协调者
发送自己处理的结果
到底是能够成功执行
还是需要回滚
在阶段二
协调者会把最终处理的结果
返回给所有的参与者
另外我们也能看到
两阶段提交的一些问题
第一
它是一个同步阻塞操作
那么它会非常大的
影响这个操作的性能
另一个主要的问题
是其中的TimeOut
比如在第一阶段中
如果参与者
没有收到询问请求
或者说参与者的返回
没有到达协调者
那么需要协调者
做超时处理
一旦超时
可以当做失败
也能够进行重试
在第二阶段中
正式提交发出以后
如果有的参与者没有收到
或是参与者提交回滚
之后的确认信息没有返回
那么一旦参与者的回应超时
要么重试
要么把那个参与者标记为
问题节点
剔除整个集群
这样可以保证服务节点
都是数据一致的
最糟糕的情况是
在第二阶段里
如果参与者收不到
协调者的最终指令
参与者将处于
状态未知的阶段
不知道该怎么办
两阶段提交最大的问题
就出在这里
如果第一阶段完成后
参与者在第二阶段
一直没有收到决策
那么这个状态会
block住整个事务
所以说在两阶段提交里
协调者的状态对事物完成
非常重要
它的可用性非常关键
因此我们引入了
三阶段提交算法
三阶段提交算法与两阶段提交最大的不同是
在询问的时候
并不锁定资源
除非所有人都同意了
才开始锁定资源
下面我们通过一个
简单的动画来讲解一下
三阶段提交的内容
首先协调者向所有的参与者
会发送能否提交的请求
如果说在这个阶段
参与者不能返回
那么直接会返回提交失败
或者在这个阶段如果说
发生了TimeOut
也会导致整个事务失败
由于这个阶段
并没有锁定资源
因此它不会block住
整个事务
因为它并没有锁定住资源
第二个阶段叫做
Pre commit阶段
协调者会向所有参与者发送
Pre commit请求
Pre commit阶段
才会真正的锁定住资源
三阶段提交的理论是
如果说在第一阶段
所有人都已经返回了成功
那么在Pre commit阶段
commit成功的可能性更大
最后一个阶段
与两阶段提交相同
就是协调者向所有的参与者
发送commit这个命令
所有的参与者
提交最后的commit操作
并且释放掉所有的资源
下面我们通过一个动画
可以展示三阶段提交的
状态转移过程
从这个图中我们可以看到
如果说三阶段提交
在Pre commit阶段
发生了TimeOut
它可以直接把状态变成feel
而两阶段提交
如果在这个时候
发生了TimeOut
它可能整个系统
都会处于一种
不知所措的状态
这就是三阶段提交
引入了一个新的状态之后
解决了这种问题
最后我们总结一下之前
所讲过的一致性算法
从这张图上我们可以看到
我们基本上不可能
让所有的项都变成绿色
如果说想在鲁棒性（07：04）上
追求更多的话
那么在性能上
必然会有一些损失
这就是著名的CAP理论
一致性 可用性
和分区容错性
只能满足两个
不过从这张图上也可以看出
Paxos基本上还是
优于其他的一致性算法
说明Paxos也是目前
比较好的一种一致性算法
-主讲人：武永卫
-主讲人：程永
-QUIZ--作业
-大纲
-初步认识大数据对分布式存储系统的需求
-理解大数据对分布式存储系统的需求
-具体说明大数据对分布式存储系统的需求
-大规模分布式存储的挑战
-小概率事件-Raid卡故障
-分布式存储系统举例
-分布式存储系统重要功能设计要点剖析
-链式写正常流程
-写流程的另一种常见方式：主从模式
-链式写异常流程
-写异常处理的另一种方法-Seal and New
--写异常处理的另一种方法-Seal and New（主讲人：姚文辉）
-读正常流程
-读流程优化-BackupRead
-IO QoS
-数据正确性：checksum
-数据可靠性-Replication
-数据均衡-Rebalance
-垃圾回收-Garbage collection
--垃圾回收-Garbage collection（主讲人：姚文辉）
-Erasure coding
-Erasure coding（3,2）写入和读取过程
--Erasure coding（3,2）写入和读取过程（主讲人：姚文辉）
-元数据管理的高可用性和可扩展性
-元数据管理的高可用性
-Paxos概要
-Raft
-元数据管理的可扩展性
-不同存储介质的特性
-盘古混合存储
-QUIZ--作业
-阿里云飞天分布式调度
-任务调度
-资源调度
-容错机制
-规模挑战
-安全域性能隔离
-分布式调度的发展方向
-QUIZ--作业
-数据格式和抽象
-分布式编程模型
-MapReuduce编程模型
-关系型数据编程模型
-分布式图计算模型
-分布式编程未来展望
-QUIZ--作业
-分布式事务
-分布式一致性算法
-两阶段提交与三阶段提交
-实践--介绍
-关系型计算基本原理_1
-关系型计算基本原理_2
-分布式环境中的连接计算和聚合计算
-其他计算和物理优化
-QUIZ--作业
-提纲
-课程背景介绍
-前序知识
-分布式节点距离计算法则
-数据分布策略
-分布式计算调度
-数据就近原则计算如何容错
-ODPS跨集群数据依赖
-QUIZ--作业
-主讲人：谢德军
--实践2：编写MR完成Group By+Join操作（主讲人：谢德军）
-增量计算和流式计算
-与批量计算的区别
-业界典型系统技术概要分析
-核心技术
-消息机制
-有状态计算、并行DAG、抢占式调度和资源隔离、Failover机制
--有状态计算、并行DAG、抢占式调度和资源隔离、Failover机制（主讲人：强琦）
-StreamSQL
-QUIZ--作业
-软硬件趋势、分布式计算简史与内存计算
-分布式计算
-内存计算
-统一的计算框架
-业界经典系统技术分析-spark&flink
--业界经典系统技术分析-spark&flink（主讲人：强琦）
-QUIZ--作业
-主讲人：褚葳
-QUIZ--作业
-分布式环境下的新问题
-工程实现范例
-课程设计相关问题
