maemual / raft-zh_cn Goto Github PK

图8，需要更新一下，根据当前的图感觉未能表达作者的意思，de他们是两种情况，并不是前后关系，这个图会产生误解。其次作者似乎不是要解决覆盖写的问题，而是想表达leader不能直接根据多数派提交前任leader留下的log，因为后续可能会有d和e两种走向。 这里我也不是很明白，希望借助这个issue解惑一下~~

根据这里的描述，那个2在开始的时候没有被提交，在后面被自动提交
站在客户端的角度，在开始的时候，那个2没有被提交，那么客户端是不是就认为是失败了。后来又自动被被提交了，那客户端也不知道啊，会不会造成“安全性”问题？
比如说，你从账户里扣了10块钱，开始的时候没成功。你又从账户里扣20块钱，成功了。后面查看账户被扣了30块钱。

难道这需要在客户端实现的时候自己来处理？比如客户端没有收到成功的标识可以重复发送命令，如果一段时间后确实不成功就告诉分布式系统这个日志我已经反馈给“最终用户”失败了，你们要确保它不成功。

如图，S2是如何当选第3任期的leader的？他在竞选时最新的log的term是1，只能获得S4的投票。

在第一章介绍里
“describes our general approach to understandability (Section 4)”
这句我觉得翻译成 “描述了我们为了易懂性而使用的方法”更好一些，
感觉把“understandability”在这里翻译成“理解能力”有歧义。

第7节Log compaction中，对InstallSnapshot RPC的翻译中，Receiver implementation的第5条好像翻译有误。
【原文】Save snapshot file, discard any existing or partial snapshot
with a smaller index
被翻译为：保存快照文件，丢弃索引值小于快照的日志。
这里应该不是丢弃日志，而是丢弃之前的快照，且丢弃日志在Receiver implementation的第7条中有所体现：Discard the entire log （丢弃全部日志）。所以第5条的原意应该是丢弃之前的快照。
应改为：保存快照文件，丢弃索引值较小的现有的或部分的快照。

第五章节，第二个表格上方： “易失性状态” 翻译为 “不稳定状态” 会不会好点？

能把领导人、跟随者、候选者换成leader、follower、candidate不。前面的表述看的好怪，看的时候老是开脑洞😂 😂 😂

大家在面试中遇到过哪些和raft相关的问题？方便留言一起交流下吗？

原文：Specifically, if a server receives a RequestVote RPC within the minimum election timeout of hearing from a current leader, it does not update its term or grant its vote.
译文：特别的，当服务器在当前最小选举超时时间内收到一个请求投票 RPC，他不会更新当前的任期号或者投出选票。

第二句中specifically具体来说，不是特别的，hearing from a current leader译文中没有体现。

Google翻译：具体来说，如果服务器在听取当前领导者的最小选举超时内收到 RequestVote RPC，则不会更新其任期或授予其投票权。

我困惑的是：在文中5.4.2节中，如果Term=2,Index=2的日志在S1、S2、S3上已提交，但是并没有提交Term=4的日志，这样S5中的Term=3的日志是否会覆盖掉已经提交的Term=2的日志？

中文翻译图片无法展示

问题可以拆分成两个子问题。

1.这里的已提交是什么意思？

根据5.3日志复制中的定义：在领导人将创建的日志条目复制到大多数的服务器上的时候，日志条目就会被提交。
我认为在领导人决定提交条目时，一定是接收到了某个follower的true响应之后，自己决定提交，然后把提交指令分发给所有的follower。这个操作并非原子操作。也就是说，即使leader已经提交了，也可能并未将提交请求分发出去。

2.选举的条件问题

如果以1中我的问题为前提，选举条件中的“除非这个候选人包含了所有已经提交的日志条目”，就无法成立了。
因为选举成功要求该节点拥有所有已经提交的日志条目，目的是为了大多数节点中，至少有一个节点拥有刚才提交的条目。
对于我的这个场景，只有上一任leader中的该条目是已提交状态，就无法满足其他节点中至少有一个节点拥有刚才提交的条目。

这里引申出第3个问题

3. 每个条目是否有待提交、已提交状态

其实也是对问题1,2的思考中得到的新问题

The third issue is that removed servers (those not in Cnew) can disrupt the cluster.
第三个问题是，移除不在 C-new 中的服务器可能会扰乱集群。

这样翻译会造成困惑，按翻译理解的话可能会觉得是移除了原来在Cold现在不在Cnew的servers后会扰乱集群，但它都被移除出集群了还怎么扰乱。
原文的意思是那些原来在Cold现在不在Cnew中的servers，如果继续让它们在集群中运行的话，它们会因为收不到election刷新的心跳(Cnew中没有它们，所以leader不会给它们发送心跳)而不断的发起election，从而影响集群。

首先感觉repo主的翻译，帮了不少忙，很棒！因为在读的过程中，发现了几个小的错误，中间如果不看原文还是造成了一些困扰，后来发现应该是笔误，提出来一下（加粗表示）。
1、5.6节
【原文】： The broadcast time should be an order of magnitude less than the election timeout so that leaders can reliably send the heartbeat messages required to keep followers from starting elections;
【译文】： 选举超时时间必须比选举超时时间小一个量级，这样领导人才能够发送稳定的心跳消息来阻止跟随者开始进入选举状态；

2、图11注解
【原文】： The leader first creates the Cold,new configuration entry in its log and commits it to Cold,new (a majority of C-old and a majority of C-new).
【译文】：领导人首先创建了 C-old,new 的配置条目在自己的日志中，并提交到 C-old,new 中（C-old,new 的大多数和 C-new 的大多数）

3、8节第三段
【原文】：Then, the state machine tracks the latest serial number processed for each client, along with the associated response.
【译文】：然后，状态机跟踪每条指令最新的序列号和响应的响应

也许可以考虑统一一下，方便通过ctrl+f来跳转之类的

希望在我的 博客 中转载关于 Raft 的中文翻译

1. 会在文章标题中显示是转载的文章
2. 会在文章首部注明转载的 Github 地址
3. 如果翻译禁止转载的话，我就不转载了
4. 最后，祝身体健康！

To eliminate problems like the one in Figure 8, Raft never commits log entries from previous terms by counting replicas. Only log entries from the leader’s current term are committed by counting replicas;
原翻译：为了消除图 8 里描述的情况，Raft 通过计算副本数目的方式，使得永远不会提交一个之前任期内的日志条目。通过计算副本数目，只有领导人当前任期里的日志条目可以被提交

应该为：为了消除图 8 里描述的情况，Raft 永远不会通过计算副本数目的方式提交一个之前任期内的日志条目。只有领导人当前任期里的日志条目通过计算副本数目可以被提交；

英文原文是
When a leader first comes to power, it initializes all nextIndex values to the index just after the last one in its log

感觉这里日志中的最后一条有点不明确

反证过程中第5、6点结论如下：

5. 投票者把自己选票投给领导人 U 时，领导人 U 的日志必须和投票者自己一样新。这就导致了两者矛盾之一。
6. 首先，如果投票者和领导人 U 的最后一条日志的任期号相同，那么领导人 U 的日志至少和投票者一样长，所以领导人 U 的日志一定包含所有投票者的日志。这是另一处矛盾，因为投票者包含了那条已经被提交的日志条目，但是在上述的假设里，领导人 U 是不包含的。

但是会否存在这样的情况：

这种情况下，投票者和领导人 U 的最后一条日志的任期号相同，日志长度也相同，但是领导人U并不包含那条已经被提交的日志条目（index=5的日志），这便无法构建矛盾

或者这样的情况：

http://maemual-share.qiniudn.com/raft-%E5%9B%BE1-01.png
里面的图片都失效了

论文图2的中文翻译：

If election timeout elapses without receiving AppendEntries RPC from current leader or granting vote to candidate: convert to candidate

翻译原文：或者是给某个候选人投了票，就自己变成候选人

但应该是：如果在选举超时时间内 没有 从当前的 leader 收到 AppendEntries RPC 或 没有 给 candidate 投票，才会转变为 candidate。
如果一旦给某个 candidate 投票就转换为 candidate 的话，整个网络里的 candidate 会越来越多，这明显不符合论文的意思。

那么 client 发送到隔离二者且不是都能正常返回吗

那这样怎么能保证一致性, 还是 raft 的大多数指的是 >= 4?

应该是图片源的问题:

图11源

图12源

@maemual 从其他地方访问是不是也会? 是的话我就把图片源换下吧

在第五节的服务器状态表格中应该明确日志条目集的索引值是从1开始递增的

They ensure safety (never returning an incorrect result) under all non-Byzantine conditions, including
network delays, partitions, and packet loss, duplication, and reordering.

在所有不是特别复杂的条件下

Raft is a consensus algorithm for managing a replicated log中的consensus algorithm 按共识算法来看是不是会比一致性算法更好一些？共识和一致我感觉还是有一些差异的，
比如三个人，两个人同意，第三个人不同意算共识，但是一致我理解三个人都得统一。

RT

主要针对leader不是异常宕机，而是被主动关闭的情况

这么做有什么问题吗？或者如果没问题的话 有工程实现了类似的功能吗？

文章中所有图都只显示上半部分，无法看完整图片

原文：

3.这个投票者必须在给领导人 U 投票之前先接受了从领导人 T 发来的已经被提交的日志条目；否则他就会拒绝来自领导人 T 的附加日志请求（因为此时他的任期号会比 T 大）。

这个投票者必须在给领导人 U 投票之前先接受了从领导人 T 发来的已经被提交的日志条目。应该是之后吧？

翻译原文

如果领导人的已知已提交的最高日志条目的索引大于接收者的已知已提交最高日志条目的索引（leaderCommit > commitIndex），则把 接收者的已知已经提交的最高的日志条目的索引commitIndex 重置为 领导人的已知已经提交的最高的日志条目的索引 leaderCommit 或者是 上一个新条目的索引 取两者的最小值

我觉得最后一句上一个新条目的索引 直接翻成最后的新条目索引就行, 就我的阅读感受来说, 上一个 把我带到了一个误区,举个例子(如图1)

图1: 黑框代表已提交
在s4 马上要接受到leader的附加日志时, 对于上一个新日志的索引的表述,很自然的我就想到了,相对于马上要接受的这次附加日志,上一次的新日志是在索引1,如果对于s4来说,上一个新日志的索引是1,收到的附加日志中的leaderCommit是3,那么s4的commitIndex 就应当等于1,但实际上,当收到附加日志的时候, commitIndex 应该是2(如图2)

图2: 黑框代表已提交
这是因为当收到s4附加日志的时候, 收到的新日志自然加到最后的位置, 对应上了英文原文index of last new entry,而最后的新日志的索引在这里是2,因为 2<leaderCommit(3), 所以s4的commitIndex 更新为2

Hello, I have included your paper in my paper_reading_cn. Is it convenient? I can withdraw it if it is not suitable.
https://github.com/caicancai/paper_reading_cn