Raft论文解读对话

1 为什么要读读raft论文?

答: 一致性协议是一个绕不开的话题,而raft则是非常流行的一个一致性协议.

2 讲一下raft协议的背景?

答: 据说是因为paxos协议太难了,然后为了教学和简化学习难度, 斯坦福大学某CS大佬研究出了raft, 大致是这样吧. 翻译过来是竹筏,竹筏确实很简洁.

3 有中文翻译的原稿吗?

答:有的. https://www.infoq.cn/article/raft-paper 这篇文章翻译的不错,第一眼感觉, 它是把论文完整的翻译了一遍.

4 英文原稿的篇幅介绍一下?

答: 英文原稿有18页,非常的长,相比 kafka论文而言, 同学说, 现在的论文越来越长,越来越细节.
论文的名字是: In search of an Understandable consensus Algorithm(Extended Version), 作者 Deigo Ongaro, John Ousterhout, Stanford University.

5 摘要了讲了什么?

答: 摘要了讲了, raft 设计的目的是为了基于paxos更简单,为了教学.论文中证明了怎么有利于教学的,这是一个很新奇的地方,让人怀疑这是一篇教育领域相关的论文了都.
摘要提了几点一致性协议相关的东西, 比如,选主,操作日志记录,多数派共识等等.

6 其余部分呢?

答: 有十几个标题,大致分别如下:
1 introduction
2 replicated state machine
3 what’s wrong with paxos?
4 如何体现可理解性
5 details of raft design(核心部分)(page3-page10)
6 cluster membership
7 log compaction 日志压缩
8 客户端交互
9 实现和评估
10 相关工作
11 结论

大家看,第5章是本文的核心,从篇幅可以看出来, 关于6,7,8 三部分是第5部分的延伸,而2,3 则可以归为 相关工作或者说背景介绍.

读论文不必从最难最重要的部分开始,不妨从一个最简单最容易有成就感的部分开始,我选择第3部分开始. 先见识一下paxos是什么,这是我第一次看paxos的解释,不妨挖个坑, 以后再写一篇关于 paxos 论文的解读.

7 请你讲一下paxos有什么问题?

答: 盲猜是太难了,太复杂了. 文章中说了,paxos有几个毛病,首要的就是太复杂了,至于为什么复杂,我相信,如果不了解paxos,说了也白说, 简而言之, 设计反直觉,然后是 single-decree 单指令,翻译. 第二个毛病就是设计过于理论而难以落地实践,很多系统参考paxos开始设计,然后发现这个理论很容易证明,但是很难实现,实现起来成本过高,最后弃之不用,另开新路,费时费力.

7.1 你的意思是作者说paxos是个绣花枕头?

答: 差不多意思. 作者说, paxos协议 几乎是等同于一致性协议,而且总是被用来教学,然而实际应用却比较艰难. 作者举chubby ,一个google家的分布式锁, 的评论说, paxos的理论和实际的需要截然不同,实际实现的系统仍然是基于没有被证明的理论. 也许是这篇论文的缘故吧,我们不能否则它为了批评而批评, 但是可以继续看下去.

8 接下来应该看什么地方呢?

答: 看第2部分, 备份状态机器. 这块我看了下, 第一感觉是头晕目眩,因此借助中文翻译来看一下, 其中涉及了一个有趣的概念,叫拜占庭将军问题.

借用百度百科,在此科普一下:

拜占庭位于如今的土耳其的伊斯坦布尔，是东罗马帝国的首都。由于当时拜占庭罗马帝国国土辽阔，为了达到防御目的，每个军队都分隔很远，将军与将军之间只能靠信差传消息。在战争的时候，拜占庭军队内所有将军和副官必须达成一致的共识，决定是否有赢的机会才去攻打敌人的阵营。但是，在军队内有可能存有叛徒和敌军的间谍，左右将军们的决定又扰乱整体军队的秩序。在进行共识时，结果并不代表大多数人的意见。这时候，在已知有成员谋反的情况下，其余忠诚的将军在不受叛徒的影响下如何达成一致的协议，拜占庭问题就此形成。

咱们看一下, 拜占庭将军是借用一个历史典故, 说必须一致决定才能做一件事,然而现实条件不允许,因此怎么办呢? 这就引出了一致性协议的问题, 有趣. 当然,这个故事也是在 paxos论文里提出来的, 由该论文的作者提出.

事实是拜占庭帝国的将军不可能这么傻, 只是作者自己简化问题, 以此举个例子. 也许将军之间的通信和达成一致的问题没有办法完美的解决,但是绝对会想出一个务实的方式,而非等到21世纪一群研究计算机的人来给出答案.

8.1 备份状态机如何理解?

答: 有一个事实我必须告诉你. 任何英文词翻译过来,硬生生翻译过来必然会给他们蒙上神秘的色彩,不是因为别的, 而是因为生硬和陌生. 举个例子吧, 我们习以为常的老干妈, 西方人会怎么翻译? 神秘东方辣酱? 什么是老干吗? old dry mother? old god mother?都是不准确的. Replicated state machine 也是如此. 翻译成复制状态机,备份状态机, 很正常也很合理,但是总是让人感觉有点奇怪, 翻译中为了效率难以做到信达雅.

备份状态机的出发点是,如果每个操作的输入一定,那么输出也一定是相同的,就像简单的函数一样确定.所以只要一台机器记录顺序操作, 把这个操作顺序放到其他机器上面执行一遍, 那么其他机器肯定也是一样的状态.
一致性协议研究的就是如何实现这个问题,因为总会遇到很多奇怪的难题.

8.2 一致性算法到底研究的是什么问题?

答: 这个问题是这篇论文的出发点和落脚点, 也是一致性算法的核心所在,它到底研究什么问题呢?在第二部分中,也就是备份状态机中, 大致说了一致性算法研究以下几点:

1. 复杂环境下的容灾(网络断开,数据丢失等等)
2. 以多数可用为基础,比如5台机器可以允许坏掉任意两台.
3. 时间顺序不能作为保证一致性的依据,因为存在网络时延等情况.
4. 如果一个rpc调用被多数服务器响应了,那么就算通过了.

其实一致性协议最后也许研究的是,如何在半数一样通过和所有人(机器)保持一致之间形成一个微妙的平衡.

我们人类社会也是,很难说所有人都同意一件事情,简单情况下,只要多数人同意,那么这事就算过了.
但是不同的组织对多数的定义不一样,美国的上下议院就很多事情通过的标准不一样, 弹劾总统2/3可能,通过一项法案可能要过1/2,等等.

9. 现在应该看哪一部分呢?

答: 现在我看introduction部分. 当我看了后面几部分,再回过头来看 第一部分introduction的时候,发现确实简单了很多. 总而言之, 第一部分详细的介绍了为什么要设计Raft的原因,以及核心设计原则: 可理解性, 以及为了实现可理解的两个具体手段:拆分和简化设计.

9.1 为什么你不用中文标点符号,这样很不规范啊?

答: 因为我经常写代码的时候,需要注释, 因为周围的同事习惯了使用中文注释, 我也就跟着写中文注释了, 因此中文注释和英文代码之间来回切换很麻烦, 我就选择,当中文输入法的时候, 也是用英文标点符号, 虽然不是那么纯粹,但是效率很高, 尤其是要中文和英文混着输入的时候.

10 接下来是什么部分?

答: 第四部分,为了理解而设计.

10.1 第四部分说了什么?

答:第四部分的题目是为了可理解性. 一个系统的设计需要考虑很多因素,都要兼顾,但是有些特点是矛盾的,因此需要取一个平衡值.比如: 实现起来很容易, 兼容主流操作系统等等, 而raft的原则主要是, 简单可理解,符合直觉.

其实我觉得这个原则的确实是非常正确的,简单的东西具有极强的生命力, 简单的设计需要花费极大的心血才能从蹩脚的设计中慢慢演化和诞生.这事我深有体会.

raft的设计者为了提高可理解性,使用了两个方法, 分别是:1.拆分,也就是把复杂问题拆成简单的小问题,其次,就是, 讨论几种问题,简化可能出现的情况.

raft的思路值得我们学习.

11 第10部分讲了啥?

答:第10部分讲了Relate Work,这么认为吧, 就是第十部分对比了一些 raft 和 其他系统不一样的地方, 讲了一些论文,一些系统. 我没法细看,因为我对raft不熟悉, 对这些论文和系统页不熟悉,我只能大致知道一些,有个大概的印象,待会回过头来看. 然后截止目前为之,简单的部分已经基本上被我看完了.

12 第5部分是篇幅最长的,具体内容都有哪些?

答: 从第5部分的介绍来看,它讲了3部分: 选主, 复制日志,安全. 听上去挺抽象的, 复制日志又叫分发日志,也就是master如何把不同机器上的操作汇总并且分发到全部机器上面去,让他们保持一致, 就像古代皇帝下发政令到各个地方统一执行一样. 安全,就是如何保证日志完全一样, 其实是第二部分的延伸和保障.

13 读第5部分第2节选主都讲了些啥?

答: 讲了怎么选主.但是我吐槽,我读英语太慢了,什么时候能像读母语那样快呢? 很多词语你都看得懂,但是在论文中好像会用到平常用不到的意思,大大增加了阅读干扰和时长. 有点烦. 比如term这个词吧, term啥意思你说说?

选主,讲的就是如何选出一个主节点. 这个过程采用一个随机的过期时间(150-300ms)之间,如果收到了半数以上的投票就当选. 当选成功以后要定期给所有的其他节点发心跳,告诉大家,我是主节点,否则其他节点会在主节点心跳超时时发起重新选主的流程. 如果出现几个节点都发起选主的过程, 那么大家会比较一个选主的数据结构的值的大小, 论文中管这个词语叫 Term? 我不知道怎么翻译. 这个Term怎么产生的也没说. 反正就是这么一个流程.

13.1 问你一个问题,如何发出心跳?

答: 发出心跳,最简单的就是定期发出一个请求吧, 我觉得 Http也能当心跳, ip包也能当心跳, 只是一般大家用rpc, 我对rpc其实比较陌生, 我写过http的服务器,但是没有编写过 rpc的服务器, 但是应该都是一种格式,底层还是字节流. 因此应该没没啥大不了的吧. 其实我特别好奇, 如何能自己编写一个rpc服务器呢? 在之前 http服务器的基础上改造一个?

13.2 如果你改造成功,你会拿它来干什么有意思的事情?

答:我会组建一个rpc集群, 比如5个rpc服务,然后让他们提供彼此之间的服务. 做一个简单的小demo.

13.3 第5部分第1节讲了哪几部分?

答: 第5部分讲了一些基础的部分,比如给我讲清楚了 term这个词是什么意思, term在这里不是条款也不是术语的意思,是任期的意思. 也就是说, master大家轮着做的潜意思吗? 总之, term就是一段时间, 它以选举开始,以master fail 为终止, 就像换届一样, 如果一个选举在一个过期时间内, 顺利收到多半投票, 那么它就是新的master了, 它就会广而告之,大家开始新的一轮分布式生活,平淡而又枯燥.

13.4 什么时候开始一个选举过程呢?

答: 是这样的, 任何一个server都可以发起选举过程,如果它认为主节点心跳停止了, 它就可以发起了(可能要等待一段时间, 作为等待窗口期,万一主节点又挣扎着活过来了),如果在它发起之前, 收到了其他server 发起的选主, 然而它认为旧的master心跳该没有到期,该怎么办呢? 到底是等待旧的心跳, 还是响应新的选举呢? 你们要造反?我是跟着呢, 还是继续等着呢? 论文没有说, 在这一节里没有说, 我会继续读下去.

---

2021-08-11 07:27:30

14 18页的论文很长吗?

答:不算很长. 比起硕士和博士论文, 这些确实不算长, 但是就内核而言, 学位论文多数都是在应付毕业而长, 写了很多没用的玩意, 压缩起来可能也是空洞无物的.

14.1 几天前我们看到5.1, 现在呢?

答: 继续看第五部分,找一个有趣的内容,当然,先要复习之前的部分,热个身.

15 选举的冲突为什么会发生?

答: 13.4已经说了,当旧的server停止心跳之后, 出现了场面一度混乱,这个时候就有人站起来说, 我要当头, 你们跟我走吧. 然后这个时候, 可能不止一个人这么做, 所以就会选举冲突.

15.2 如何平息这种冲突?

答: 谁的选举号码大谁就保持, 选举号码其实是一种时间戳类似的东西, 单调递增, 先发起的选举号码比后发起的选举号码小, 如果先发起的还没来得及赢下过半数量的投票(等待其他节点回应它, 其他节点只能一次选一个候选人,不能8面玲珑,谁都投一票), 就有更新的其他选举被其他节点发起投票并且传达给这个候选人, 那么按照现有的机制, 先发起的应该该怎么办呢, 比如我的结果还没出来呢?

有两种消息, 一种是 拉选票的消息, 一种是心跳消息, 只有获得多数投票才能发起心跳信息, 心跳消息是主节点才有资格发起的, 而候选人身份只能发起拉选票的消息.

如果一个候选人收到了其他的候选人的拉选票的消息,肯定是不理会的, 在这个拉选票截止时间之内是必然不理会的.其他的投票人也一样,不能说你收到一个拉选票消息就改投这个人. 这样是永远选不出主节点的.

如果一个候选人在等待其他候选人的投票信息的时候, 收到了一个心跳消息, 如果这个心跳信息中携带的选举号(我们暂且叫选举号吧,就是它当选成功时候的选举号,作为它的主节点身份)比当前候选人收到的最后一次心跳消息的选举号更新,那么说明这是一个新的主机诶单, 自己放弃候选人身份.

什么时候一个投票人可以投其他人呢? 任何选举都有一个不定长的到期时间, 如果过了这个到期时间还没有收到来自这个节点的心跳消息, 那么就可以投别的节点了.

如果一个候选人到他选举结束之前还没有收到多数票的响应, 也没有收到其他更新的心跳消息, 那么就继续发起新的投票.

整个过程是非常直观和符合人类选举的规则的.

有一些细节是论文没说,我自己脑补的, 可能有不准确的地方, 还望指正.

15.3 选举算法为什么设计成这个样子?

答: 论文中又说,选举算法的设计, 反复的修改, 最后才变成这个样子, 是经过一番考量和试验的, 不排除拍脑袋决策的可能, 未必是最佳的算法, 但是是比较实用的算法, 这就是选择的智慧. 最后一段,有几句话我没看懂.

16 日志复制都说了什么?

答: 日志备份可能是最长最难的部分. 请做好战斗准备. 日志复制中说了几个事, raft如何保障节点之间的日志一致的的机制, 如果不一致该怎么办. 首先,它说了复制日志的RPC消息的结构, 以及为什么要这些结构来保障日志的一致性的. 当然, 最先它说了日志的格式,
日志的格式, 论文里画了一张图. 大概包括以下几个核心内容:
(1)日志的下标,假设从0开始吧,就是跟数组的下标一样.
(2)日志产生的Term, 就姑且翻译为选举时期吧, 举个简单的例子,比如唐明皇的开元年间,天宝年间,清朝皇帝的康熙年间(他们皇帝换年号不是很勤快,一辈子就用一个), 雍正年间等等,就是一个产生的时期.
(3)命令的具体内容.
那么复制日志的RPC消息体又是什么样的呢, 它包含以下内容:
(1)命令的具体内容
(2)日志Term
(3)主节点本条被复值的日志的下标
(4)主节点前一条日志的Term和下标.

第(4)个是保证一致性的关键, 如果每次发送复制日志的消息的时候都, 从节点都检查一下当前的消息里的前一条日志的Term和下标是否一致,如果一致, 就说明前面所有的日志是一样的(为什么这么说, 你自己理解递归是什么意思吧),因此就是一致的,就接受这条日志并且赋值到自己的状态机里面, 如果根据RPC消息里前一条日志的Term和下标没有在自己的日志序列(注意是序列,讲究顺序的)找到对应的日志,那么说明从节点的日志要么多了,要么少了,反正就是不一致了, 从结点就拒绝这条日志的复制. 然后主节点就开始不停的向这个从结点发RPC, 是把前一条日志的Term和下标换成更早一个日志, 如此往复, 直到找到第一条相同的日志为止, 后面所有的不同的日志都会被主节点接下来的日志覆盖.

16.1 为什么会出现日志不一致的情况?

答:因为主节点不能保证把所有的日志都复制到所有的节点上去, 只能保证多数节点有这条日志.

16.2 我举个例子, 如果有ABCDE五台机器, A是主节点, A一条日志复制到了BC和自己身上,这就是多数了, 如果A因为网络故障而掉线了,那么重新选举的时候,如果D或者E当选为主节点, 很显然他们的日志是不全的, 那么这个时候如果按你说的, 岂不是要把那一条日志删掉呢?

答: 是的. 所以说这样的机制不完善,我们会打补丁, 起码, A是主节点,它会尽力把所有的日志都复制到所有的机器上去, 如果DE掉线了, 等他们联机上来, A会联系他们并且把日志复制到他们上去. 如果恰好是DE重连之前, A掉线了, DE也开始选举自己为主节点了, 这叫新兵蛋子, 应该说是不配被选举为主节点的, 所以选主这块应该会控制,不会把刚刚掉线然后重连的机器选为主节点的.

17 突然跳转到底8部分, 第8部分Raft都讲了什么?

答: 讲了客户端和服务器交互的事情.

17.1 具体来说?

答: raft集群中的客户端如何找到服务端的事, 以及如何实现顺序执行(这块有点不明白). 客户端首先会随机找一个服务器, 如果这个服务器不是服务器中的主节点(下文我们管它叫从节点), 它就会回应, 别找我, 找那个谁. 如果客户端找服务器主节点, 如果主节点超时, 客户端会过一会重新随机发起一个请求, 最终找到正常工作的主节点.

17.2 为什么是主节点服务,而其他节点不能服务?

答: 这确实是费解的, 设置那么多备用的, 只让一个上, 真的是家大业大啊, 资源浪费啊.

17.3 是不是说, 其他的结点用来读, 而主节点用来写?

答: 也不是, 读也是从主节点读的, 跟节点没关系, 从节点一直处于幕后待命状态,就是为了备份用.
待会会讲为啥从节点不是读取用的.

17.4 如果主节点同时负责读写请求, 那和单机的有什么区别?

答: 一时竟无法反驳, 区别是这样的集群, 主节点挂了也没事.

17.5 raft如何实现所有命令顺序执行?

答: 给所有的来自客户端的请求编号, 并且记录执行状态(成功还是失败), 保证其中的命令只被执行一次. 如果有相同编号的命令被重复请求, 那说明第一次相应没有到达, 因此客户端发起来重试.

17.6 但是你还是没有说,如何保持不同客户端的之间命令保证顺序执行呢?

答: 论文没有说, 或者我没Get到.

18 读是如何被处理的?

答: 读请求不会改变服务器的状态,但是也不能返回陈旧的信息. 因为主节点可能不再是真正的主节点了, 比如它曾经是, 客户端也认为它是, 后来它崩溃了, 集群选了新的主节点, 它又复活了, 这个时候如果客户端继续请求它, 它返回的就是陈旧的信息了. 因此raft通过某些措施保证.

18.1 raft如何保证读也是最新的消息?

答: 关键就在于确认它是否是主节点, 因为读不涉及写入多数节点的过程,相对比较快, 因此每次处理读请求, 都要取向其他节点确认一下身份, 我最后写入的消息是XXX,你看你们也是不是? 如果是, 那我还是主节点. 一个新选举的主节点如何确保它的所有日志信息都被复制到多数节点去了呢? 它也要向其他节点发出一个校验请求, 是当选后的第一步.

19 继续返回第5部分, 第5部分都讲了些啥?

答: 就讲了如何选主,复制日志. 自从日志复制部分 5.3 内容结束之后, 还没继续往下看, 请跳转到第16条看进度. 先复习一下第5.3 部分关于日志复制部分.

19.1 复习日志复制有什么新的发现吗?

答: 日志复制, 主节点如果收到一条日志, 那么它会发给所有从节点, 让他们也复制一份, 如果这条日志被安全的复制了, 那么就(1)执行这条日志包含的命令到自己的状态机上, (2)响应给客户端. (3)如果
几台从节点没有响应, 即使这条日志已经复制给多数机器并且这些机器都响应了,那么也应该继续有耐心的给这些没有回信的从节点继续发, 毕竟是主节点, 要有担当的.

(1)的过程后,这条对应的日志被称为提交状态.

19.2 什么是被安全的复制了?

答: 所谓的安全复制就是指被一条日志被包含着自己在内和其他从节点成功复制这条日志并且有回信, 这些节点数量加起来数量过半.

19.3 什么时候把一条日志应用到状态机?

答: 成功复制过半并且从节点都有回信. 这日志记为已提交日志?

19.4 一条日志被提交, 下标小的日志可以被跳过吗?

答: 不行, 比他下标小的日志都会被提交.

19.5 raft如何保证日志的一致性?

答: 返回16条, 一个日志有两个字段确保其一致性, 下标和任期值, Term Value, 对于raft里所有的节点上的日志, 如果一个日志的下标和产生任期值相同, 那么这条日志必然相同.

19.6 日志不一致产生的时机是什么?

答: 主节点复制日志到一半崩溃了, 从节点掉线了, 这两种情况.

19.7 如何处理这种不一致?

答: 会看第16条问答, 里面有说.

19.8 请继续从上次的进度说起, raft如何保证安全的选主和日志复制的?

答: 是的, 剩下的5.4节名字叫 safety. 也即是边缘条件或者特殊条件, raft的设计机制, 如何保证选主和日志复制. 它补充了细节.

20 raft 如何保证安全选主的?

答: 正如我 16.2 问答所说, 它是有细节的. raft和其他的分布式算法不一样, 它的不一样之处在于日志只从主节点往从节点复制, 没有从节点往主节点复制这个方向, 所以当选主节点条件严苛, 首先在它还是候选人身份的时候, 它拉选票的时候, 它要向其他从节点证明, 我包含最新最全的日志, 所以请你选我.

20.1 它是如何证明的?

答: 它向其他从节点看它最后一条日志的索引和 产生任期号Term, 因为这些都是单调递增的, 所以大家都知道它是不是包含比自己还多的日志, 最起码要一样多, 才会投票选. 谁会选一个比还落后的节点呢?

21 raft说, 一个主节点要分发日志, 这种日志有可能不是自己当前的任期内产生的, 这是怎么回事?

答: 一个主节点当选后, 有可能发现遗产. 所谓的遗产就是一个日志被复制到其他节点上去了, 但是未必或者到多数节点上去了, 或者即使被复制到多数节点, 还没来得及收到回信就崩溃了. 当新的节点当选后, 它要做的就是处理这个"遗产", 完成这个复制过程.

21.1 那么针对这种情况, 新任的从节点如何保证自己完成任务了呢?

答: 复制前任主节点产生的日志到其他所有节点并不难,只要发请求就行了,但是为了保证状态机的安全, 正如我21.2 所讲的情形, 前任主节点产生的日志不能因为复制到多数机器, 就立即提交到状态机, 只有本任期内的日志才可以, 从而捎带提交了前任主节点产生的日志.

21.2 什么情况下, 复制到多数节点的日志会被覆盖?

答: 复制到多数节点但是没有成功提交, 而这个任期比较旧, 而一个拥有新任期的日志当选为主节点,则会把最新任期的日志复制到所有其他节点, 覆盖了这个日志.

22 为什么主节点的日志是完整的?

答: 什么叫做主节点的日志是完整的?

22.1 主节点上的所有提交日志是提交到所有的节点的状态机上的,主节点的日志是最新最全的.

答: 这个就是主节点的权威性保证, 5.4.3 有内容, 采用反证法论述, 我就不细说了. 反正你记住, 一个主节点能当上主节点, 必定是有资格的, 是有机制保证的.

23 从节点和候选人节点崩溃了该怎么办?

答: 他们不是主节点, 他们都是不重要的角色, 在raft看来. 如果一个从节点或者候选人节点崩溃了, 其他节点发送给它的请求或者相应会一直重试下去, 直到他们重启成功. (实际实现的时候应该会设置一个重试次数, 毕竟发请求是有成本的)

24 时间和保证可访问性(可靠性之一,有请求必然有响应)?

答: raft的设计思想是, 不因为一个行为太慢或者太快而导致表明它是成功或者失败. 慢或者快不影响结果. 举个例子吧, 一个孩子5岁了还不说话, raft认为他并不是哑巴, 也许10岁他会说话了呢? 再或者20岁? 30岁, 死之前突然会说话了那都不算哑巴.

24.1 你说这话什么意思? 难道一个请求超过5分钟不响应也算正常?

答: raft认为是正常的, 你可以继续请求, 直到有返回为止. 但是超过5分钟不响应说明可访问行不行, 响应太慢, 系统就是有改进的空间. 关键在于制定一个合适的响应时间上限.

24.2 所以说超时还是算失败喽?

答: 超时只能说它很有可能失败, 但不是一定失败了, 现实的原因很多, 不要妄加揣测. 只能说很有可能.

24.3 废话少说, raft的超时时间是怎么样的?

答: 超时时间取决于网络广播时间和 MTBF. MTBF 是 mean time between failures, 也即是一个节点平均失败的间隔. 一般也就是几个月? 如果经常出问题, 那说明这个节点自身有问题.

一般网络广播时间取决于网络本身好不好, 如果网路很差, 超时时间就要设置大一点.
超时时间一定要大于广播消息的时间,小于MTBF, 你想想看, 如果广播消息还没完成, 也就是所有节点收到请求并且相应的时间, 你就判超时了, 那有什么意义呢?

25 第6部分 节点关系变化说了什么?

答: 第6部分不打算看了, 第7部分也不打算看了. 暂时不看, raft的精髓已经学到了, 第6部分讲的是加入和退出集群, 也就是节点数量的动态变化, 这个部分应该还是很有趣的, 但是短期没啥用. 第7部分, 日志压缩, 侧重于工程实践, 应该也没啥用, 因为目前也用不上. 有需要了再看.

26 采访一下, 全程看完有什么感受?

答: 全程历时大约2周, 中间有很多事情耽误了,大约花费了7*2小时吧, 最大的感受是, (1)英语论文看起来很长,但是说东西本质不多, 但是要把这些东西说清楚, 却有很多细节, 你要不厌其烦的说, 因此它的篇幅就很长. 这也是老外了不起的地方, 越是细节越有必要, 因为细节决定着到底有无可能是实现. (2)阅读英语磕磕绊绊的, 有很多生词, 很容易阅读疲劳, 因此阅读论文不要线性阅读, 从最有趣的地方开始阅读是最好的. (3) 读完了raft的论文核心部分其实目前够用, 剩下的细节随着以后实践的增加而可以逐步返回来再阅读.

27 读完具体对你有什么提升?

答: 本事没长, 但是可以和人能聊分布式话题了, 也算是半只脚跨入其中. 关于读论文, 其实时间有限, 不能一一读完, 尽量挑核心部分消化就可. 读了论文也不能说你就会什么了, 没有实践啥都不是, 所以还是要实践起来.

28 所以分布式的raft算法到底能干啥?

答: 我也在思考这个问题, 我为此搜索了一下互联网上的消息. 有以下几个收获:

1. 分布式公司 PingCAP 家的 TiDB, 是基于 Raft 做的. 文章网址如下: https://cloud.tencent.com/developer/article/1548518
2. Curve, 一个网易公司开源的分布式存储数据库, 使用了Raft协议, 介绍如下, https://cloud.tencent.com/developer/article/1548518
3. 华为云的基于Raft协议的分布式数据库, 介绍地址如下: https://cloud.tencent.com/developer/article/1548518
4. raft 在百度云的实践: https://time.geekbang.org/dailylesson/detail/100016716
5. RocketMQ 有使用到Raft协议来更新自己的设计: RocketMQ, RocketMQ现在已经升级为Apache开源项目, 以前是阿里开发的, 大概介绍地址如下: https://www.infoq.cn/article/7xeJrpDZBa9v*GDZOFS6

29 所以这个东西都是分布式存储用到了?

答: 也许吧…

30 所以好像对我没什么用吗?

答: 学习其设计思想, 跟人装B可以说… 认真的回答是, 分布式, 什么是分布式, 我们常说单机无法解决了才使用分布式, 也就是多机协作, 这个词语说在新人的嘴里有点可笑, 到底什么是分布式? 听过无数次, 又从来没真正接触过, 或者深入的就其中一个问题思考过. 我认为, 分布式, 只有你具体思考过一个问题, 就从问题出发, 参考别人的设计, 真正的解决了自己遇到的问题, 那才是真正理解什么是分布式了. 现在的人张口闭口就是, 分布式,大数据, 可是真正的问题解决又有几个? 只有去实践中真正解决问题, 才能算把这个问题搞明白, 看论文或者看课程, 啃砖一样的书, 是没有用的.

31 最后的最后, 说一句什么?

答: 系统设计, 符合直觉, 简单, 是具有旺盛的生命力的, 是最容易流行起来的, 否则就是一小部分人自High的, 殿堂之上的理论, make it simple and broadcast it.