12 | 分布式锁Chubby（一） ：交易之前先签合同
徐文浩
你好，我是徐文浩。
在过去的十几讲课程里，我带你一起学习完了 GFS、MapReduce，以及 Bigtable 这三篇被称之为 Google 的“三驾马车”的论文。不知道你有没有发现，这三篇论文有一个共同点，那就是这三个系统都是一个单 Master 系统。而这就带来了一个问题，就是这个 Master 会成为整个系统的单点，一旦 Master 出现硬件故障，或者遇到 Master 网络不通的情况，整个集群就不能提供完整的服务了。
MapReduce 里的 Master 我们可以暂且不论，毕竟这个 Master 的生命周期只是一个 MapReduce 任务执行的时间，即使 Master 出了问题，简单地重跑一下任务就好了。但是 GFS 和 Bigtable，都是要长时间提供在线服务的系统。从概率的角度来讲，它们的 Master 也一定会遇到故障。
所以，在 GFS 和 Bigtable 的论文里，我们看到它们都有对应的 Backup Master 机制。通过一个监控机制，当发现 Master 出现问题的时候，就自动切换到数据和 Master 完全同步的 Backup Master，作为系统的“灾难恢复”机制。
乍一听，这个做法简单直接。不过如果仔细想一想，这个操作可没有那么容易实现。我们至少会遇到两个问题：
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了分布式系统中的共识问题，介绍了二阶段提交和三阶段提交，以及其对分布式一致性和CAP原则的挑战。同时，文章还介绍了事务中的ACID特性，Paxos算法和“可线性化”概念，帮助读者深入理解分布式一致性和事务处理。最后，文章详细讲解了Chubby系统的设计和在大数据系统中的应用场景。通过阅读本文，读者能够全面了解分布式系统中的难点，对CAP原则有更深入的理解，并掌握了分布式共识问题、一致性和事务处理的基础知识，以及Chubby系统的设计和应用。文章内容丰富，涵盖了分布式系统中的关键概念和技术挑战，对于从事分布式系统开发和设计的技术人员具有重要参考价值。文章还介绍了分布式一致性的基础知识，包括两阶段提交和三阶段提交的算法，以及它们在可用性和一致性之间的取舍。此外，文章还提到了Paxos算法作为解决单点故障问题的策略。整体而言，本文为读者提供了深入了解分布式系统中共识问题和一致性挑战的重要参考资料。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《大数据经典论文解读》，新⼈⾸单¥59
《大数据经典论文解读》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(14)
- 最新
- 精选
piboye三阶段提交是我看过课程里讲的最好的，给老师一个赞2022-01-189
Eternal二阶段和三阶段的理解和学习需要一开始就建立一个模型，协调者，参与者，提交请求，提交执行，协调者硬件故障，参与者硬件故障，两阶段或三阶段的哪一个阶段那个角色出现故障？两阶段或三阶段的哪一个阶段那两个角色通讯网络故障？只有举例模型和例子的基础上自己推演才能理解深刻且记得住。 然后用mysql大家最熟悉的事务模型中的undo、redo 日志准备好但是未真正的提交事务这个例子来类比更方便大家理解这是我自己的感悟。两阶段，三阶段，cap等基础概念看过很多次，但是要融于自己的知识体系，条件反射的说出来，且在讨论问题的时候会不假思索利用到这个还是有难度的。简单的能把理论记住，或只在讨论这个理论知识的时候能分析出来，这个都不是最终目的。2023-03-19归属地：中国香港3
扭高达💨🌪思考题: 协调者应该是client端😂2021-10-1523
leslie《数据密集型应用系统设计》此书算是近年相对的经典，已经看了近十遍，总觉得自己理解的浅。中文版的翻译质量算是难得的上品，老师是看中文版还是英文版，是不是版本翻译中还是有欠缺？总觉得有些点没有提及到，不知道是不是翻译的问题，图倒是原版继承了。2021-10-262
在路上徐老师好，在两阶段提交这个策略下，一旦 Backup Master 节点出现问题，其实整个系统都是不能写入的。听起来意味着 Master 和 Backup Master 都不能出现故障，那 Backup Master 只是在增加出现故障的概率。如果需要提升可用性，为什么不在 Backup Master 出现问题的时候只写 Master ，等 Backup Master 恢复后再同步数据？两阶段提交和三阶段提交的根本问题在于单点故障，要解决这个问题应该需要用一个集群提供协调者服务， Backup Master 可以从一组节点中选举。 回到老师的思考题，我看到有的学友说是 client 是协调者，有的学友说 Backup Master 是协调者，我觉得如果两阶段提交的所有请求都要经过协调者，协调者应该是Master或者其他服务。如果 client 是协调者的话，没法保证多个 client 请求之间的顺序，也就是协调者应该是个单点服务。如果是 Backup Master ，那么客户端就形成了对 Backup Master 的直接依赖，也就不应该叫 Backup Master，另外选择Backup Master作为协调者并不能节省流量，因为所有的请求都要发给 Master 和 Backup Master。2021-10-2522- 龚诚bookeeper、zookper2022-05-011
斜面镜子 Bill我理解是有back master充当的，一方面备不提供服务，可以优化主的性能，其次，如果主挂了起码可以把备选成主，而不至于系统不服务2021-10-221- Geek_88604f二阶段提交和三阶段提交实际很少使用了。实践中使用的都是基于使用场景的改进版，像TCC、基于MQ的一致性保证等2021-10-161
陈迪Chubby是到现在为止最难懂的论文。。一些例子和设计决策依据让人不知所云2021-10-151- Geek_546d35想问一下三阶段提交时，需要两阶段类似的问题，如DoCommit时候参与者B挂掉，如何处理参与者A和参与者B之间的同步呢，也是让参与者A先等待一下吗2023-10-09归属地：湖北
收起评论
