论文阅读笔记 - Paxos made live
作者：刘旭晖 Raymond 转载请注明出处
Email：colorant at 163.com
BLOG：http://blog.csdn.net/colorant/
更多论文阅读笔记 http://blog.csdn.net/colorant/article/details/8256145
关键字
Paxos, 实现,可靠性，性能，Chubby
== 目标问题 ==
基于Paxos机制，构建一个可靠的容错数据库系统。Paxos理论和实际实现之间有很多的gap，如何解决这些问题并构建出一个实际可用的系统。实际中作为Chubby的底层Log机制的一个实现
== 核心思想 ==
将Paxos逻辑由理论变成实践中上线的产品，需要解决众多的问题，涉及到可靠性，性能等方面的众多问题。尤其是可靠性方面，现实系统中存在各种各样的系统失效问题，原有的Paxos理论逻辑基于的假设前提往往会被破坏，要解决这些问题，就需要方法来检测和控制各种失效。
Multi-Paxos：Paxos逻辑是对一个单独问题的独立的决策过程，实际的系统需要一系列的Paxos过程来推动系统的运作，通过优化（比如保持一个相对稳定的Leader），可以在串联的多个Paxos过程中，节省下一个独立Paxos过程中所需要的一些步骤（如跳过下一个Paxos过程的Prepare阶段），加快Paxos的决策过程。
Leader角色的维护：要保持相对稳定的Leader，同时要防止单点失效和不影响读写性能，引入了基于timeout的契约（Master Lease）。一方面可以重选Leader，另一方面也用于在读数据过程中，保证Master本地数据的最新（没有Lease的replica不能更新数据）
磁盘失效问题的解决：Paxos逻辑中很重要的一个前提就是每个参与决策的Replica需要记住一些之前作过的承诺，这些承诺或Log记录在磁盘上保存已用于服务重构。但是如果这些记录损坏了，就会导致Paxos逻辑的前提被打破，进而导致系统无法正确运转。
- 失效的原因很多，可能是文件错误，或是完全丢失。前者可以通过各种校验手段来检测，后者通过在分布式文件系统（GFS）中维护一个标记来判别是否之前存在过可用文件。
- 失效的解决，基本上是通过Catch up，一方面从其它Replica中获取但前最新数据，另一方面直到观察获得整个系统的下一个完整的Paxos过程之前，自身不再参与Paxos决策过程
Snapshot快照：引入snapshot快照的目的是为了缩短数据重构时Log回放的代价，减少磁盘开销等。这同时也会引入额外的复杂性，比如快照与LOG的一致性，快照的丢失和恢复以及此期间可能遇到的各种问题等
== 实现 ==
实现中，为了减少开发复杂度和保证系统的正确性，采用了各种手段。比如隔离模块关系，拆分出独立的状态机，写了专门的工具用于从自定义语言中生成状态机的实际C++代码。
再有在一个容错系统中，底层的错误很可能被本身的容错机制所屏蔽了，加大了调试的难度。因此开始就是以测试为向导的，代码中大量的Assert。同时开发了各种层面的测试工具，用于在各个层级中可重现的植入各种错误情况。此外还有各种运行时的校验机制来检测不可预知的一致性错误，而LOG机制本身也有助于回放错误的过程。
== 相关研究，项目等 ==
Paxos /Chubby
== 其它 ==
总之，这篇文章就是Google在Chubby中运用Paxos来实现容错数据库LOG机制时遇到的各种实际问题的解决方案的经验总结。也提出了容错系统开发的方法建议。