Paxos算法与Zookeeper分析,zab (zk)raft协议(etcd) 8. 与Galera及MySQL Group replication的比较

 

 

 mit 分布式论文集 https://github.com/feixiao/Distributed-Systems

wiki上描述的几种都明白了就出师了

raft 和 zab 是相似的,都是1.先选举,2.而后再对客户端的消息进行投票.  实际上是 simple paxos 的一种变化.

和 原生paxos 的区别在于: 选举的阶段实际上是 prepare 的阶段. 选举容许多个主出现.

1. 读原文

paxos-simple-Copy [ https://www.microsoft.com/en-us/research/wp-content/uploads/2016/12/paxos-simple-Copy.pdf ]

读译文

悟出一点和zk的区别.

文献例子中:

• • leader能够两个, 全部投票仍是两阶段. prepare预锁[预锁是最好的理解方式]+ 提交 因此在fast paxos中再次强调不关心leader如何选举[The Progress Property 一节中,i will not discuss how to select leader]. 在此文中有说起方法,timeout.[paxos-simple-Copy原文Progress 一节末尾]
  • 顺序性有序号保证,接受不必定当即执行. 故没有135 ,就不能执行149. 能够先设置一个nop
  • 能够批量决议议题,第x-x+10个命令,是否采用对应的命令.
  • instance 就是没个决议. 笔者注:instance能够细化到到单个帐户的投票上,对应着zk为各个路径.增长并发能力.

zk和raft中leader的做用:

       1. 做为全部paxos instance的prepare阶段. [phil注: 通常人悟不到这点]

2. 统筹全部的请求,方便进行并发控制

3. 选择日志最多的节点,可以快速从失败中恢复.

 

zk和raft中leader是否可能有多个?

zk:

可能的. 虽然zk在获得半数赞成后, 再等待了finalizeWait = 200ms, 远当心节点之间心跳超时时间. 也避免不了leader被抢走的尴尬. 案例说明: 共5台机器, 好比 1,2,3 都选择了1. 1 变成leader 而后2 还没获得3的通知, 此时5发出请求,获得了2,3,4,5的赞成.

raft:

选本身,而后通知全部人. 各自等待. 先唤醒的再选择本身,通知全部人.

zk:

和raft共同点:

• • 　　有选举轮次,来源于simple paxos 的prepare的概念
  • 都是选本身,通知全部人.

和raft不一样点:

• • 对返回的结果不理睬,直接睡眠 [4]
  • leader排他,有效的只能是一个.
  • 顺序性有命令队列保证.
  • 接受了当即执行
  • 日志不是顺序的
  • 加入新节点会阻塞 [1]
  • 更换leader会阻塞 [1]

    http://blog.csdn.net/xhh198781/article/details/10949697 前半部分是对simple faxos的很好总结.

   raft:

和zk共同点:

• • 有选举轮次,来源于simple paxos 的prepare的概念

和raft不一样点:

• • 对返回的结果理睬.
  • 日志是连续的 [1] [3]
  • 加入新节点不阻塞
    • 其余区别见下图[6]

       

  
  

   

       

 

笔者注解: 以前的可靠性都是

1. 经过备份,切换的方式. 对应的监听切换器又须要热备. 热备无穷尽也.

2. 客户端多ip 适用于无状态服务器.

       paxos的选举机制很好的解决了这个问题.3台机器便可. 客户端配置x个ip.

 

• paxos之Multi-Paxos 这个没找到原文献. 和simple中思想差异较大.可是和zk区别较大,见[2]

• FastPaxos 有原文献.
• 趣事Paxos在大型系统中常见的应用场景

“Leslie Lamport也是用了长达9年的时间来完善这个算法的理论”–

这个故事实际上是这样的:
Lamport大牛在他Paxos的第一个版本早在1990年就提交给ACM TOCS Jnl.的评审委员会了 可是当时没有人理解他的算法 主编回执他的稿子建议他用数学而不是神话描述他的算法 他们才会考虑接受这篇paper 

Lamport大牛很生气 他有次就在一个会议上说:”为何搞理论的这群人一点幽默感也没有呢?” 他拒绝修改 并且withdraw了这篇文章

1996年微软的Butler Lampson在WDAG96上提出了从新审视这篇文章 由于他读懂了

1997年MIT的Nancy Lynch在WDAG97上 根据原文从新改写了这篇文章 叫作 在本文中她们”代替”Lamport用数学形式化的定义并证实了Paxos

因而在1998年的ACM TOCS上 这篇迟到了9年的paper终于被接受了

后来2001年 Lamport大牛也做出了让步 他用简单的语言而不是神话故事 重述了原文 这就是 可是通篇仍是没有数学符号 L大牛甚为执拗 据他本身说 他检查过了本身的语言并无歧义 不须要数学来描述

Paxos能够说是Theory of CS领域被流传最普遍的一则趣事~

 

•  实现:

phxsql）是腾讯开源的mysql主备集群多副本管理系统，除了mysql源码以外，还包含了一系列外部的组件（phxsqlproxy、phxbinlogsvr）和内部插件（phxsync），借助paxos协议，实现了主备数据的强一致。

• • • MySQL半同步复制的数据一致性探讨   
    • 谈谈PhxSQL的设计和实现哲学（下）8. 与Galera及MySQL Group replication的比较
    • 世界上目前已知的通过理论证实和实际检验的一致性算法屈指可数：两阶段提交two-phase commit (2PC)、Paxos[4]、Raft[5]、Zookeeper Atomic Broadcast (ZAB)[3]、Viewstamped Replication[5]等。newsql
    • zk的zap 说明
    • raft说明

阿里云企业三节点版本，在alisql内核中引入raft协议，不借助任何外部依赖，经过mysqld自身的简单配置，实现整个集群的构建，架构简单、实现优雅。

•  paxos一些例子和进阶,事务《分布式系统理论基础 - 时间、时钟和事件顺序》

分布式基础通讯协议:paxos,totem和gossip canssandra.

•  P2P大规模直播与GOSSIP协议 百度文库上仍是有好文章的. 看看学术文章,对理解新技术仍是不错的.

• 2. zk的原理

    核心是对应的画图能力,模块分解能力. 数据流图.

    别人的文章 图解zookeeper FastLeader选举算法. 要学会画无职责的流程图(含循环+ 节点批注). 而后再理解模块,带上职责. 甚至是角色.

   Paxos算法与Zookeeper分析

    http://blog.csdn.net/zhxdick/article/details/50886638

[1] Raft对比ZAB协议  总结了两个经典区别: 1. 日志的连续性问题 2.加入过程是否阻塞整个请求  .具体详见文献3

[2] Multi Paxos http://www.cnblogs.com/fei33423/p/7990190.html wiki上也有,可是没有对应的文献.

[3] Raft算法赏析  核心: 当前term的leader不能“直接”提交以前term的entries . 致使了日志是连续的

   有一张例子图 

[4] Raft 为何是更易理解的分布式一致性算法

[5] 颇有深度的文章 分布式系统理论进阶 - Raft、Zab

[6] Vive La Difference: Paxos vs. Viewstamped Replication vs. Zab, Robbert van Renesse, Nicolas Schiper and Fred B. Schneider, 2014

我的渣记录,仅搜索用