关于共识算法Raft的常见误解

Raft 共识算法

最近翻了翻Raft相关的资料，同时也总结了日常工作的一些积累，就当做Raft技术笔记吧。

由于工作的关系，Raft是所有组件共用的算法核心，包括RocketMQ、Consul、CubeFS等，所以对Raft也算脸熟了（当然它可能不怎么认识我，工作中这种情况挺常见的，不知道为什么:-）

最终一致性与线性一致性

最终一致性，常表述为弱一致性，这里的弱是较于强而言（后续会有个人基于现实场景中遇到的问题进行对比），而线性一致性常说的是强一致性。

日志的覆盖与删除

摘抄网上一篇文章的片段“由于从节点的最大日志数据二元组是<7,12>，与leader发送过来的日志数据<6,10>不匹配，索引11、12的数据将被删除”

Raft 主从同步流程如下：
索引6-10会从leader同步（Append Entries），但是由于leader的索引只是到10，follower上的committed index 会重置到10（与Leader保持一致，参考Raft 安全性原则），索引11、12不会做任何更改，当leader收到新的写请求后索引递增到11、12；那么follower会从leader同步数据，此时会覆盖（follower上索引11、12的内容会被leader上新写入的内容覆盖，由此leader、follower上索引11、12保持一致）；

上述流程中可以发现，并没有删除流程；Raft 的读写都从Leader上进行，同时Leader是Append-Only的，所以删除流程对于Raft来说是不存在的操作。

Remove节点时需要skip

回放时需要跳过remove自身节点的日志，否则当前节点无法加入集群；

这点尤为重要，曾经线上遇到某个节点恢复上线时总是保持分钟级在线，然后就自动下线了，四处排查总是找不到原因，本地也无法复现，最后滤逻辑和日志发现，remove self了，哭笑不得。

总结

未完待续

参考文档

1、Raft wiki