本文首发于稀土掘金。该平台的作者 逐光而行 也是本人。
Chubby简介
Chubby是一个由Google设计的提供粗粒度锁服务的文件系统。基于松耦合分布式系统，解决了分布式一致性的问题。
- 特点:是一种advisory lock,不是mandatory(强制） lock，系统有很大的灵活性。
用途：
- GFS(Google file system)使用其选取一个主服务器；
- Google内部使用其进行Name Server
- Bigtable使用其指定一个主服务器并发现、控制与其相关的子表服务器；
- 其还可单独作为一个稳定的存储系统存储一些小数据
Chubby一致性问题解决原理————Paxos算法及原理及其实现
分布式一致性问题
简言之，即保证系统中初始状态相同的各个节点在 执行相同的操作序列时， 看到的指令序列完全一致，并且 最终得到的结果完全一致。
（我的理解：并不是要时刻同步，但是在关键的地方要同步，最终结果也要一致）
解决思路
设置一个专门的结点，该结点接收每次进行新操作时第一个节点发送的状态信息，并以此为基准，其他结点通过查询该结点获取信息后也同样执行该操作。
问题
如果该结点崩了，整个系统就崩了，不够可靠。
解决思路
同时设置多个这样的特殊结点，由它们共同决定操作序列。这也是Paxos的基本思想。
Paxos内容
概述
Paxos是由Leslie Lamport最先提出的基于消息传递的一致性算法。
其中的结点分为三种类型：
- proposers
- acceptors
- learners
proposers提出提议，acceptors批准提议，learner从acceptors获取被批准的提议并执行。
保证数据一致性的三大条件
- 只有经proposers提出的提议才有可能被批准
- 每次只批准一个提议
- 只有提议被批准后learner才能获取这个提议
为了保证以上三大条件而设定的一些约束条件
- 每次进行新操作时，每个acceptor只接受它得到的第一个决议
（类似于最初单个特殊结点那样，这次是为了保证能有少数服从多数的局面，即使最初的提议并不是最完备的，但总比卡住什么都不干好）
- 一旦某个决议通过，之后的决议必须要与它保持一致
一个决议的阶段
- 准备阶段
- 批准阶段
