实现 raft 的时候一些思考, 求 v 友印证下

[scalaer]

当集群选举完后，follower 和 leader 的已提交的 logs 保持一致。

下面有两种情况:

• 客户端向集群请求读。 请求可以通过负载均衡分发到随便一台机器， 直接查询返回结果， 所以读的性能跟机器的数量成正相关.

• 客户端向集群请求写。 如果请求到达的是 follower， 则需要返回 leader 的地址， 让客户端将请求 redirect 到 leader, 所以写的性能理论上是一台机器写磁盘的极限

所以强一致性的 kv 分布式服务, 写的性能会有极限, 读的性能跟机器数量成正相关

[ccpp132]

写也可以对 key partition 来分库做扩展

[zhangtao]

是的，所以需要划分多个 raft 集群，来支持不同的业务

[louhubiao]

生产环境中读的性能也就单机，不指望能有很好的读性能

[petelin]

不对啊 你要是链接的正好是那一小部分节点就有可能 master 写入了 你读不到

[mortonnex]

@ccpp132 partition 是为了解决并发,但 raft 的写是顺序的,也就是说临界资源不是库,而是 leader 本身,所以 partition 的优化非常有限,除此之外,写的瓶颈是网络,因为需要 Follower 的 ack

[EmdeBoas]

1.选 he 举 xie 完并不能保证 follower 和 leader commit logs 一致，保证的是如果某个日志条目在某个 term 中已经被提交，那么这个条目必然出现在更大 term 的所有 leader 中
2. 读必须走 leader，最原始的 logRead 还需要落一次盘，indexRead 才可以不落盘，leaseRead 不用走 raft-roundtrip，但也还是需要读 leader。所以单 raft 读也无法 scale-out
3. multi-raft 可以做读写的 scale-out

[scalaer]

@EmdeBoas 多谢指正

[wweir]

为了强一致性，读写都是单机，因为要同步，性能还要比单机低一点。
所谓性能高，都是以牺牲强一致性为基础的，中间有填不上的缝，在特定场景会产生时序上不一致的数据

[7173842]

这时候，group raft 就出来了

[ty4z2008]

可以看看 TiDB 的 raft 实现