Star

请教下nebula的一致性读现在保障级别是怎样的


在代码中看到graphd请求storage,如果leader失效了、就随机选择一个leader出来;
那这样子一致性读怎么保障?

比如针对同一个partition,两个graphd分别随机出来不同的storage,那么两个graphd的同一个query能拿到同样的结果么?因为在storage层没有看到类似etcd的readIndex这种和集群中其它机器沟通然后再返回数据的逻辑,所以上述场景中、两个graphd取到的数据会保障一致么 :thinking:

还是说storage收到请求时,会先判断下自己是否是此partition的leader、如果不是了就一定策略告知graphd并让graphd重新从meta拉取leader信息并请求

是的哟,现在每个partition只有leader负责读写

有 raft 来保证啊.

“还是说storage收到请求时,会先判断下自己是否是此partition的leader”

会判断的, 并且随着错误码就会返回 partition 所在的 leader 信息, 不用再去 meta 拉.

了解了,后续是否会有允许降低一致性、使用follower一起处理读请求从而提升读请求吞吐的考虑,类似etcd的readindex策略

恩,是否有考虑过拿到新leader信息后,对失败的partition使用新leader进行一定策略的重试?

我们的架构和etcd有一些区别,storage是多partition的,partition均匀分布在集群里,压力是均匀分布在集群中的,follower read并不会后明显的提升。

恩,也就是设计的初衷就是想通过加大partition的数量来增加读写并发,而follower只作为replica保证数据不丢,是这样么

是的,因为follower是会和其他leader混合在一台机器上面,所以follower read从整个集群的角度来说不能分担workload

浙ICP备20010487号