rpbear88

> I don't think it is a Raft problem. For a single raft group, you don't have to complete the first Raft log write before starting the next Raft log...

这个方案的前提依然是，我们认为braft的实现原理上没有特别多的导致性能差的点(虽然实验数据看起来并不是这样，我们还在进行调整)，依然认为最大的性能问题来自于raft算法本身。 而对braft来说，leader上本地日志提交和两个peer的replicator对log entry队列的争抢虽然有一些锁的保护，但是锁竞争并不会很大(和peer数相等)。

> > > 配置文件里加上： > > > --raft_enable_leader_lease=true > > > 然后在每次 leader 读之前调用一次 is_leader_lease_valid 可以保证线性一致读 > > > > > > leader apply比较快，而follower apply慢，但某个点follower当选了leader，只依赖leader的判断这个时候不能直接读吧？ > > braft里保证了这个事情。这个lease的有效时间是从on_leader_start开始的，也就是所有的已commit数据已经全部apply完了 但是似乎只能保证线性读，不能保证在一个node上读写是否并发是吧？对于写操作的话由于apply的时候是顺序的不会有并发问题。

> > 但是似乎只能保证线性读，不能保证在一个node上读写是否并发是吧？对于写操作的话由于apply的时候是顺序的不会有并发问题。 > > 不知道你所指的是哪个case，可以举个例子吗？ 感谢回复，我的意思是，开启了raft_enable_leader_lease之后，某次读操作和正在进行的写操作之间是无序执行的吧？这样对于数据结构来说要处理并发访问的问题，而如果只有写操作的话，由于写操作在进行apply的时候是串行进行的，并不需要考虑并发问题。 要是开启了raft_enable_leader_lease之后，可以提交一个请求，该请求只到各节点确认leader lease而不记录日志，但是确认之后依然可以由on_apply来通知调用者这次读是lease valid的就好了，这样整个node上不论读还是写都是串行执行的，不需要考虑并发问题。

> 这里其实和业务有关系，正常情况下，并发的没完成的写，读到新数据或者旧数据都是可以的，只需要保证不回退即可。 是的，这个业务倒是ok的，主要是不想让代码中为此维护一些互斥锁之类的。 > 至于你说的这个，有一个简单的实现方式，可以开放 fsmcaller 的execution queue接口出来，允许用户提交task进去，由于brpc的execution queue是串行的，on_apply也是在这里执行的，可以满足你的这个需求 OK，我觉得这个倒是一个不错的方案，可以看下改造难度，感谢。