理解分布式一致性协议Paxos

Make it Simple

Question:大名鼎鼎的Paxos协议是啥?Ansower:“分布式一致性协议”。
这么逼格的术语,就问你怕不怕??能不能搞的中国话一点,简单一点,而不是翻译《Paxos Made Simple》呢?一直觉得Lesile Lamport的脑回路和常人不一样好伐。文章前面部分一眼都懂,后面的,眼睛瞄瞎都不一定看得懂。本文是Paxos的一些阅读总结。欢迎一起讨论。

解决什么问题

场景化的核心问题:成功的往分布式系统里面写入一个数据。Outline几个关键问题:

  1. 数据写入模型是异步非阻塞,我们说的“同时”,都是指一次写入未Finish的情况下就开始下一次的写入;
  2. 各节点的数据一致,保证是最终一致;
  3. 失败处理的两个关键问题:失败了是否会重试、重试的时候是否会增加ID,文中对失败处理没有太多的描述;
  4. 保证数据顺序写入,一旦一个写入成功,后续就不会有ID更小的数据写入成功。但并不是每一个“同时”的写入操作都会写成功,也不保证ID大的就一定会成功。

怎么解决问题

我们循序渐展开思考解决之法。主要路径是;

  1. All,写入所有节点
  2. Quorum,写入过半节点
  3. Rules, 竞争规则
  4. Same Value,等值情况怎么应对
  5. Uncertainty,结果的非确定性
  6. Two Phase, 为什么要两阶段提交

All

最直观的,往所有节点写成功就算成功。是一个过程艰辛的正确答案。多个写操作并行时,部分节点是value=A,部分节点value=B,到底是A还是B呢?

Quorum

好解决。咱们投个票,少数服从多数。关于投票,既然投票,拿了过半的选票数就算胜利了。如果总票数为偶数,那势必需要在一个票上相互争取。既然是争取就得定个输赢的规矩。

Rules

最简单的输赢规矩是先到先得,占坑。OK,至此,基本道理咱们都了解了。咱们对着协议来说说怎么玩的。首先给proposal编号,可以理解为一个Proposal就是一次写入的申请,有了全局编号意味着就有了顺序。如果一个节点(协议成为Accepter)收到了两个ID的Proposal:

Same Value

如果两个写入者写入的是同一个值,比如之前提到的数据重发场景。要想达到重发数据也成功的效果,节点就要求可以接收多个Proposa。对应于协议里面就如果Acceptor发现Proposal的value和已经接受的一致,但是ID比已经接受的大,就也接受这个ID。应该也适用于非重发,但是同时写入的Value一致的场景

Uncertainty

同时写入A和B两个数据,其中A的ID小于B的ID。结果到底是A还是B呢?按照前面的描述,其实不确定。如果A已经拿到了半数的选票,B就会失败。但是这种情况对应用来说并非最佳选择,毕竟有个先后顺序。

Two Phase

这块是最难以理解的,大家都会说有两个阶段。但从不解释为啥要拆分成两个阶段(Prepare和 Accept)。我简述下我的理解,(如果有其他理解或者权威资料的请你通知我)

  1. 给ID更大的Proposal多一次机会。第一阶段拿到拿到过半票数后,也有可能被ID更大的消息抢走选票;
  2. 事先询问。别一股脑去写入,先问下是否具备写入条件。如果ID大的哥们已经拿到了过半选票,你还去写入剩余的一些戳,其实是没有必要的,写了大家也不认,还要再改写。
  3. 协助达成所有节点的数据一致,如果ID大的Proposal未被accept,他可以改变自己Proposal的值,发向其他的节点。算法本身并没有说明这一点。咱们也不去讨论如果ID大的写入失败了,业务层重新写入数据的情况,我理解又是一次算法的全过程了。
  4. 类似Zookeeper,这种同时写入,更多的是去解决多Master同时存在的情况,通过ID的增加,可以识别出新旧master,从而拒绝旧Master的请求。这种玩法的极端情况情况下,新的Master如果是Prepare成功,Accept失败,是需要重试的。

你可能感兴趣的:(大数据理论)