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

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

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

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

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

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

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

@EmdeBoas 多谢指正

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

这时候，group raft 就出来了

可以看看 TiDB 的 raft 实现