当集群选举完后,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 和 leader 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 实现
|