这是一个创建于 2460 天前的主题，其中的信息可能已经有所发展或是发生改变。
当集群选举完后，follower 和 leader 的已提交的 logs 保持一致。
下面有两种情况:
-
客户端向集群请求读。 请求可以通过负载均衡分发到随便一台机器， 直接查询返回结果， 所以读的性能跟机器的数量成正相关.
-
客户端向集群请求写。 如果请求到达的是 follower， 则需要返回 leader 的地址， 让客户端将请求 redirect 到 leader, 所以写的性能理论上是一台机器写磁盘的极限
所以强一致性的 kv 分布式服务, 写的性能会有极限, 读的性能跟机器数量成正相关
 | 1 ccpp132 2019-03-22 18:48:15 +08:00 via Android 写也可以对 key partition 来分库做扩展 |
 | 2 zhangtao 2019-03-22 19:00:42 +08:00  2 是的，所以需要划分多个 raft 集群，来支持不同的业务 |
 | 3 louhubiao 2019-03-22 19:40:55 +08:00 via Android 生产环境中读的性能也就单机，不指望能有很好的读性能 |
 | 4 petelin 2019-03-22 19:44:31 +08:00 via iPhone 1 不对啊 你要是链接的正好是那一小部分节点就有可能 master 写入了 你读不到 |
 | 5 mortonnex 2019-03-22 19:56:08 +08:00 @ccpp132 partition 是为了解决并发,但 raft 的写是顺序的,也就是说临界资源不是库,而是 leader 本身,所以 partition 的优化非常有限,除此之外,写的瓶颈是网络,因为需要 Follower 的 ack |
 | 6 EmdeBoas 2019-03-22 19:56:15 +08:00 2 1.选 he 举 xie 完并不能保证 follower 和 eader commit logs 一致，保证的是如果某个日志条目在某个 term 中已经被提交，那么这个条目必然出现在更大 term 的所有 leader 中 2. 读必须走 leader，最原始的 logRead 还需要落一次盘，indexRead 才可以不落盘，leaseRead 不用走 raft-roundtrip，但也还是需要读 leader。所以单 raft 读也无法 scale-out 3. multi-raft 可以做读写的 scale-out |
 | 8 wweir 2019-03-22 22:01:16 +08:00 via iPhone 为了强一致性，读写都是单机，因为要同步，性能还要比单机低一点。 所谓性能高，都是以牺牲强一致性为基础的，中间有填不上的缝，在特定场景会产生时序上不一致的数据 |
 | 9 7173842 2019-03-22 22:06:17 +08:00 这时候，group raft 就出来了 |
 | 10 ty4z2008 2019-03-22 22:09:20 +08:00 可以看看 TiDB 的 raft 实现 |
Select Language