内容简介：在优化之前, 我们先分析原始的能保证正确性的做法是什么, 然后分析问题在哪, 最后再讨论怎么优化.* Paxos 读流程: 针对要读取的对象, 在其操作序列中追加一条 read 共识.* Raft 读流程: 在 Raft 日志序列中写一条 read 日志, 等 commit.
在优化之前, 我们先分析原始的能保证正确性的做法是什么, 然后分析问题在哪, 最后再讨论怎么优化.
* Paxos 读流程: 针对要读取的对象, 在其操作序列中追加一条 read 共识.
* Raft 读流程: 在 Raft 日志序列中写一条 read 日志, 等 commit.
两者其实是一样的, 都是复制状态机模型, 都要复制一条 read 日志, 然后 apply 之后才能返回结果. 问题在哪呢? 很显然, 大部分系统是读多写少, 每一次读都需要达成共识, 而达成共识的过程无论是 Paxos 还是 Raft, 成本都太高了 - 网络写 IO, 磁盘写 IO. 既然是读操作, 能否只用磁盘读 IO 就行了呢? 这个想法就是优化的方向.
一致性算法的基础是, 无论客户端是什么操作, 集群都要在全部或者部分成员参与的情况下, 达成新的共识. 优化的思路是在某些情况下, 不用每一次操作都达成新共识. 怎么做到? 1, 如果全部成员都是一致的, 客户端读操作就没必要生成新的共识. 2, 读操作不主动生成新的共识, 而是等待其它客户端写操作生成新的共识.
Paxos Quorum Read
流程分为: Quorum-read phase, Rinse phase.
1. 读取半数以上节点的 accepted_index, 记录其中 max_accepted_index
2. 等待 , 直到 max_accepted_index 被 apply/execute
3. 返回结果给客户端
重要的地方就是"等待", 如果没有等待, 就会变成 简单的 Quorum Read, 是错误的 .
这里面其实有个问题, 因为Paxos 是消极的, 如果没有外界触发, 这个等待可能永远也不会返回.
Raft Read Index
Leader 的数据就是可以返回的, 唯一的问题是, 某个节点可以错误地自认为是 leader, 所以要先确认自己是不是 leader.
1. 自认是 leader 的节点询问半数以上节点自己是不是 leader
2. 如果确认自己是 leader, 等状态机 apply 到大于等于 commitIndex(这个时刻就是 readIndex) 后, 读取状态机的结果返回
3. 如果发现自己不是 leader 怎么办? 找到正确的 leader, 获取 readIndex, 然后等待自己的状态机 apply 到至少 readIndex.
因为 Raft 是积极的, 所以AppliedIndex 一定会最终等于 commitIndex, 即使没有外界触发也不会永远等待.
以上所述就是小编给大家介绍的《Paxos和Raft读优化 – Quorum Read 和 Read Index》，希望对大家有所帮助，如果大家有任何疑问请给我留言，小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持！
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
面向对象葵花宝典：思想、技巧与实践
李运华 编著 / 电子工业出版社 / 2015-12 / 69
《面向对象葵花宝典：思想、技巧与实践》系统地讲述了面向对象技术的相关内容，包括面向对象的基本概念、面向对象开发的流程、面向对象的各种技巧，以及如何应用面向对象思想进行架构设计。在讲述相关知识或技术的时候，除了从“是什么”这个角度进行介绍外，更加着重于从“为什么”和“如何用”这两个角度进行剖析，力争让读者做到“知其然，并知其所以然”，从而达到在实践中既能正确又能优秀地应用面向对象的相关技术和技巧。 ......一起来看看 《面向对象葵花宝典：思想、技巧与实践》 这本书的介绍吧!
