人人都是分布式专家 paxos raft_幽灵再现 paxos-CSDN博客

本文链接：https://blog.csdn.net/fei33423/article/details/123671481

父文章

有关一致性协议的资料网上有很多，当然错误也有很多。笔者在学习的过程中走了不少弯路。现在回过头来看，最好的学习资料就是Leslie Lamport和Diego Ongaro的数篇论文、Ongaro在youtube上发的三个视频讲解，以及何登成的ppt。

一致性里的通用问题?

1. 如果leader 提案已经多数通过了,但是没有提交怎么办?

这个需要客户端幂等重试

2. 一致性复制, 并发复制场景,接收方如何确保顺序?

原来的记录,序号可以不用连续的,但是传输的时候必须要加上一个传输序号,这样才允许并发传递. 类似tcp里的序号. zab里是利用tcp 单线程来保证负责保序. binlog同步也是. 又类似视频会议里的消息同步给端上,不要乱序.
消息“时序”与“一致性”为何这么难_HelloWorld搬运工的博客-CSDN博客_时序一致性

3. raft是要求强顺序的,paxos可以乱序?

数据库的先锁,后提交.如果没有锁,可以各提交各的.最终在binlog里有序. 同步的时候不用加锁了. 所以一个库不能太大,本来加锁的并发高性能,被主从同步的性能给拉低了.

raft可以随机分组,类似分库. 见知乎讨论,第三点,笔者瞎想

4. 对于zab来说,新leader如何知道所有follower的数据都同步完毕?

答: 按照2的方法,有序发送过来就好了. 最后发送一个end即可.

5.高阶: 关于Paxos "幽灵复现"问题看法 - 知乎

raft也是后期修复的这个bug. 解答详见下文. ABA

paxos

问题: 传统主备和paxos的区别?

答: 主备,主挂了后,备运行,如果主又恢复,备的数据没有完全同步过来,会丢失备上的数据. paxos,主挂了后又恢复, 会变成备,然后又变成主,这个过程会确保数据同步完毕后再提供服务.

作者发了三篇文章兼职议会<The Part-Time Parliament>(存在数学证明) <paxos made simple> 翻译 (描述各阶段和案例) , <fast-paxos> 在原paxos文献中, leader可以是多个.

Paxos Made Simple【中文翻译注解】

分布式数据一致性算法paxos解析及几个问题,收敛(含参考文献)_个人渣记录仅为自己搜索用的博客-CSDN博客

OB

2.0后没有updateServer 改成share-nothing . 详见分库分表 vs NewSQL数据库_Java小叮当的博客-CSDN博客

SQL如果没有分区信息? 则在OBServer端并行计算优化。 [大数据]OceanBase 2.0让百万支付不是梦？-码姐姐下载

自动扩容基于分区? 类似codis的动态扩容原理.

可靠性建立在哪?paxos多副本 OceanBase 社区版

分区策略有几种? OceanBase 社区-策略

lsm , 几层? 每个sstable OceanBase 社区-sstable

全局索引? OceanBase 社区-全局索引

分区后如何实现范围查询? 特别是hash后.

multi - paxos

避免每条LogEntry都需要走两了轮rpc（prepare&accept）：leader当选的时候完整的走一遍prepare流程（目测包括一个个LogEntry往后prepare，类似raft里面的leader下发no-op），后面的日志全都可以直接accept，可以这么做的原因是：

也含OceanBase 和幽灵复现的描述 https://blog.csdn.net/zxpoiu/article/details/115521494

分布式算法：Multi-Paxos 中文

Implementing Replicated Logs with Paxos/Multi paxos by raft作者 Diego Ongaro

Paxos协议的难以理解的名声似乎跟它本身一样出名。为此，Stanford大学的博士生Diego Ongaro甚至把对Paxos协议的研究作为了博士课题。他在2014年秋天正式发表了博士论文：“CONSENSUS: BRIDGING THEORY AND PRACTICE”，在这篇博士论文中，他给出了分布式一致性协议的一个实现算法，即Raft。由于这篇博士论文很长（257页），可能是为了便于别人阅读和理解，他在博士论文正式发表之前，即2014年初，把Raft相关的部分摘了出来，形成了一篇十多页的文章：“In Search of an Understandable Consensus Algorithm”，即人们俗称的Raft论文。

multi-paxos 二者最大的差别是Multi-Paxos要求唯一leader节点而Paxos没有唯一, 有多个leader. 异常情况分析: 其他机器宕机后,不知道谁是leader.需要有个选举的过程. 这期间拒绝一切指令. leader也无法得到半票的accepted. 再其他就是工程上考虑的事情, leader宕机后,新leader如何获取到全量最新数据.(zk, 每轮序号是连续的) (一般在大的指令的机器中选举出来,如果都挂了,那数据就丢失了)

multi-paxos创造原因如下截图:

fast-paxos

https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/tr-2005-112.pdf

ZooKeeper是以Fast Paxos算法为基础的 - borter - 博客园

Paxos-->Fast Paxos-->Zookeeper分析_Kuzury的博客-CSDN博客_fast paxos

分布式系统的一致性协议之 Fast-Paxos算法 - 知乎

raft

翻译

作者Diego Ongaro讲解视频：https://www.youtube.com/watch?v=vYp4LYbnnW8

分布式一致性算法：Raft 算法（论文翻译） [phil 注解]_个人渣记录仅为自己搜索用的博客-CSDN博客

分布式一致性算法：Raft 算法（论文翻译）

RAFT 论文中文翻译(1)_前面几章含matchIndex文字等

深入浅出一文搞懂Raft协议_梦回从前的博客-CSDN博客_raft协议含nextindex和matchIndex

区别

raft弱点和paxos的乱序区别?

Raft协议简介 - 墨天轮

OceanBase ob 需要先事务加锁,再获取序号分配给指令. 待半数提交后才释放锁. 这样子无加锁互斥的可以乱序提交,加锁顺序也可以确保顺序,避免并发乱序. 实现等效串行. (数据库隔离级别)

关于Paxos "幽灵复现"问题看法 - 知乎

由于郁白之前写的关于Multi-Paxos 的文章流传非常广, 具体地址: http://oceanbase.org.cn/?p=111 原文提出了一个叫"幽灵复现" 的问题, 认为这个是一个很诡异的问题, 后续和很多人交流关于一致性协议的时候, 也经常会提起这个问题, 但是其实这个问题我认为就是常见的"第三态"问题加了一层包装而已.

出现场景: ABA , B的时候查询无, A恢复后又有.
为什么普通的数据库第三态没有幽灵复现的问题? 原因是分布式算法 paxos/raft都有一个"重确认"的逻辑.

* 超过半数后 leader挂掉, 其他节点未通过心跳获取到commit怎么办?

详见5.4.2里的注释即 "在任期开始前,增加一个no-op noop, 因为需要同步之前的提案, 权当认为这些未提交提案都是可以提交的,同步过去并覆盖, 如前面所说不再判断是否是超过半数了,必须覆盖. 这里面会出现一个幽灵复现的问题. 但是又由于有了一个no-op ,完美解决幽灵复现. "分布式一致性算法：Raft 算法（论文翻译） [phil 注解]_个人渣记录仅为自己搜索用的博客-CSDN博客

raft协议，leader在commit了一条日志后，立刻挂了，那其他节点如何处理这条日志？ - 麒麒的回答 - 知乎 https://www.zhihu.com/question/357207584/answer/2510160192

论文里的确没有说, 唯一相关的是5.4.2里的一句话."To eliminate problems like the one in Figure 8, Raft never commits log entries from previous terms by counting replicas." 翻译过来是"Raft 永远不会通过计算副本数目的方式来提交之前任期内的日志条目"/

我来解读下.

新的主确实不知道最后一个节点是否commited,假设强制提交和apply到状态机里.

这里面会出现两个情况.
1. 如果客户端之前已经感知到提交. 没有问题.
2. 如果客户端之前没有感知提交,那就是第三态的问题. 新主提交也没有问题. 客户端来查询或者幂等重试即可.

所以最终结论就是 : 新主强制提交"最后一个日志的同任期"中"不知道是否提交"的节点.

( 补充, 但是还有一个问题,即幽灵复现的问题.陈宗志：关于Paxos "幽灵复现"问题看法 . 所以引入一个no-op 节点,

要先提交一个no-op 然后再强制提交"最后一个日志中同任期"中"不知道是否提交"的节点. )

解答

Raft论文学习之问答详情解答nextindex和matchIndex

mit 6.824 分布式课上的基于raft的实验课

MIT 6.824 - Raft学生指南中英对照

( 另外一个版本 MIT 6.824 - Raft学生指南（中英对照）：MIT 6.824 - Raft学生指南)

MIT Students' Guide to Raft 英文原地址

mit 6.824 raft 问答 ( Over the course of the semester, a number of good questions have been asked that may be of use to others trying to come to grips with Raft )

mit 6.824 raft 教师指南 - 含paxos和raft简单对比

MIT 6.824 - Raft学生指南

关注两大消息结构参数和返回值.

和zab最大的区别是每次同步的时候会回溯. 确保在重新选举的时候不需要日志同步.

单向通信,仅两种通信类型. zab主动拉数据.

Raft协议Java版实现

https://github.com/sofastack/sofa-jraft
https://github.com/hazelcast/hazelcast/tree/master/hazelcast/src/main/java/com/hazelcast/cp/internal/raft

ZAB

zk在得到半数后commit自己,然后返回客户端,然后异步通知给fllower.

问题: 如果客户端已收到通知,flower未收到通知,但是leader挂掉, 会怎么样? 三态问题,新leader会重确认,最终提交成功.客户端重试即可. 这点和raft是一样的. 不一样的是要zab收集, raft不用收集. 所有的议案都是顺序且线性的. 但是paxos不需要. raft在锁后线性了,也可以按表分组,降低同组大小.