05｜共识Raft：如何保证多机房数据的一致性？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
Raft算法是一种用于保证多机房数据一致性的分布式强一致性算法。相比Paxos算法，Raft更易于理解并能保证数据操作的顺序，因此在分布式数据服务中被广泛使用。文章介绍了Raft算法的实现原理，包括Leader的选举过程、多副本写一致性的保证以及服务之间的日志进度同步机制。在Raft算法中，Leader通过向Follower发送单条日志同步信息来保持数据一致性，同时定期打快照以降低修改日志的大小。虽然Raft算法对网络性能有一定依赖，但通过合理的优化和调整，可以提高整体集群的数据修改性能。 文章还介绍了如何保证读取数据的强一致性，以及Raft算法的特点和适用场景。通过Raft算法实现的多机房数据存储层，能够实现数据的存储和增删改查的跨机房强一致同步，使业务层无需关心一致性问题，轻松实现多机房的强一致同步。然而，这种同步方式的代价和延迟较大，适合在数据量和修改量较小的场景中使用。 最后，文章提出了一个思考题，即为什么Raft集群成员增减需要特殊处理。总的来说，了解了Raft算法，就相当于了解了分布式强一致性数据服务的半壁江山，对于需要保证多机房数据一致性的业务来说，具有重要的参考价值。
《高并发系统实战课》，新⼈⾸单¥59
全部留言(21)
- 最新
- 精选
👽文中的这一段，如何保证数据一致性的解释： “这里有个小技巧，就是 Follower 在收到查询请求时，会顺便问一下 Leader 当前最新 commit 的 log index 是什么。” 这里是不是意味着每次对从节点的查询，一定会伴随对主节点的查询？这么来看的话，性能岂不是会很差？不单单是要求修改量小，查询量多了主节点是否也容易承受不住？ 另外一个问题是，我们有一个大佬说，现在的分布式一致性都是扯的，我们追求的只能是最终一致性。这样说有道理吗？我们是否还应该追求分布式数据的强一致性？作者回复: 从某个角度来说，这和我们的需求有很大关系。用户量大的服务业务对性能要求高，不管多大的公司投入硬件都是有限的，所以基本能看到的都是最终一致是主流（常见的读多写少服务是主流）。而分布式一致性如果不考虑性能是能做到的，只是不值得，因为还要考虑高可用等事宜。
2022-12-27归属地：北京44
HappyHasson有两个问题， 一，这里没有主观下线和客观下线的区分吗，就是当一个follower检测到leader下线，但是不一定真的下线了，而且网络抖动引起的 二，我看到的理论都是说投票过半数就选举成功了，这里说是三分之二，为什么作者回复: 你好，HappyHasson，很高兴再次收到你的留言 第一个问题：网络抖动引起的下线也会影响数据的同步，所以从某个角度来说他已经不是同步更新的节点了，如果是下线的是leader那么会导致更新数据卡住等待其他follower回馈，这很影响服务稳定。第二个问题，一般来说是一半，但是从以往经验来看，一半容易出现脑裂，为了减少避免这个问题的概率，所以是三分之二，当然缺点是大规模掉线会卡住服务。
2022-11-04归属地：北京3
梅子黄时雨搜索了下，主要是存在脑裂的问题，就是在增减集群成员后，到底有哪些成员，新老节点看到的结果会不一样，从而到导致leader选举出错。作者回复: 点赞
2023-01-04归属地：北京2
Layne老师，主从之间通信不上的时候，怎么确定是主还是从出问题了呢？这种情况下主从分别会做些啥操作呀？作者回复: 你好，Layne，一般来说主从同步，都是从主库复制变更过程到从库执行，所以看从库同步状态的错误原因就可以了。
2022-11-30归属地：北京32- Geek_499240如果leader收到了一个请求，并把日志同步到了大部分的follower上，如果leader 还没来得及commit就奔溃了，那么新选举出来的leader会commit这条消息吗？
作者回复: 你好，很高兴收到你的提问，你问到了一个额外的知识点，这里新选举出来的leader在选举成功后会立刻写一个no-op日志，这个操作会把之前没有commit的都提交。这么做是因为不想让新leader提交前任的内容，会产生数据冲突等问题。no-op是一个知识点，可以查一查
2022-11-10归属地：北京32 - HappyHasson收到投票申请的服务，并且申请服务（即“发送投票申请的服务”）的任期和同步进度都比它超前或相同，那么它就会投申请服务一票 原文中这句话意思是，如果一个follower收到了自荐投票请求，任期比自己大但是同步进度没有自己大，这时候会拒绝投票？
作者回复: 你好，HappyHasson，很高兴收到你的留言，是的！这个机制是为了保证，拥有最新进度的leader能够被选中，这样可以减少损失，因为leader是可以强制其他follower和他一致的，这就导致如果leader进度不如其他follower会强制覆盖丢失掉这个差异
2022-11-04归属地：北京32 
贺子这里有个小技巧，就是 Follower 在收到查询请求时，会顺便问一下 Leader 当前最新 commit 的 log index 是什么。如果这个 log index 大于当前 Follower 同步的进度，就说明 Follower 的本地数据不是最新的，这时候 Follower 就会从 Leader 获取最新的数据返回给客户端。可见，保证数据强一致性的代价很大。这里和后面的感觉矛盾呀！到底raft是什么机制呀，后面说wait index！tidb就是支持indx read，类似作者回复: 你好，贺子，这里面有几点：首先，在 Raft 算法中，为了保证数据的强一致性，Follower 在收到查询请求时会询问 Leader 当前最新的 commit 的 log index。如果这个 log index 大于 Follower 同步的进度，说明 Follower 的本地数据不是最新的。这时候 Follower 会从 Leader 获取最新的数据返回给客户端，以保证数据的一致性，这就是前面提到的如果想要最新的数据。 更进一步提高性能上来讲，Raft 算法也可以采用了等待 Leader commit log index 的机制来保证数据的一致性。Follower 在处理读取请求时，会等待 Leader 提交的日志达到一定的进度后才返回数据。这样可以确保读取的数据是已经提交并被大多数节点接受的数据，从而实现强一致性。 可以说Raft 算法通过两种方式来保证数据的强一致性：Follower 主动向 Leader 查询最新的 commit log index，以及等待 Leader 的 commit log index 达到一定进度后才返回数据。这些机制确保了数据的一致性，但也会带来一定的代价和延迟。 另外关于 TiDB 的支持 index read，这是因为 TiDB 在 Raft 算法的基础上进行了优化和改进，以提高读取性能和并发性。这与 Raft 算法本身保证数据一致性的机制是相辅相成的。
2023-07-31归属地：北京1
奕如果集群中的 Follower 节点在指定时间内没有收到 Leader 的心跳 ---------- 这里是不是有数量的限制，比如说至少一半的 Follow 节点？作者回复: 你好，一步，Follower只会收到leader的心跳，同时一半是指leader自己统计有一半Follower消失吗？
2022-11-15归属地：北京31
千锤百炼领悟之极限可以说了解了 Raft，就相当于了解了分布式强一致性数据服务的半壁江山。另一半是ZAB吗？作者回复: 你好，很高兴收到你的留言，还有一些但是没有他复杂，比如gossip
2022-11-14归属地：北京1
Mr.Tree对于Raft保证数据读取的强一致性，follower的读取都会向leader发送一个版本确认请求，如果是高并发的情况下，leader的压力岂不是会很大，会不会把它打崩，或者客户端出现延迟，对于这种主从结构系统；出现写冲突是如何处理呢？想到一个场景：张三人在国外，银行账户里存有1w，通过手机银行APP转帐给李四8k，于此同时，张三媳妇在国内通过ATM机查询账户1w，想要取5k，这种同时发生，对于这种强一致性要求系统会怎么处理？作者回复: 你好，Mr.Tree，很高兴收到你的疑问，事实上大部分交易系统为了保证数据的强一致都是用本地主库去做的，当进行交易的时候跨区域通讯到核心机房去做交易。你的开户行决定了你的数据在哪里做决策，在下一节课你会看到Raft算法，这里会对这个疑问有很大的帮助。
2022-11-12归属地：北京1
