raft 读请求可以读follower吗
raft写的话是走leader节点，同步至少(n/2+1)个节点即可；那如果写后读场景，raft的读也是只能走leader节点吗？如果走follower节点，是否会存在读脏数据的问题？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
raft写的话是走leader节点，同步至少(n/2+1)个节点即可；那如果写后读场景，raft的读也是只能走leader节点吗？如果走follower节点，是否会存在读脏数据的问题？
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
发布评论
评论（2）
会,但是实际上基于 raft 的 etcd 实现了 Linearizable Read 来解决这个问题
读请求到了 follower 后,follower会去向 leader 请求 readindex(也就是当时 leader 的 commitindex), leader 在确认自己还是 leader 之后,就会吧 readindex 发给 follower,follower 会对比自己的 commitindex 和 readindex,只有commitindex 大于等于 readindex 之后,才能读取数据返回.
如果是原始的raft论文《In Search of an Understandable Consensus Algorithm (Extended Version)》，读写请求都是发送给leader。如果读follower的话不能排除该follower处于partition,即他没有收到最新的append entries RPC,那么他只有旧数据。
此外，关于”读请求可以读follower吗“这个问题，zookeeper正是这么干的，所以zookeeper不能保证跨client的强一致性，即在zookeeper中client1读client2的写是有可能读到旧数据的。但是zookeeper保证了同一个client读写的强一致性，通过其FIFO client order保证。zookeeper论文《ZooKeeper: Wait-free coordination for Internet-scale systems》。
以上是我读完这两篇论文之后的看法，有错误的话欢迎交流～