doc001

> > > > > > > “FollowerStableClosure消息的消费依赖于NodeImpl的析构” 这一条不成立吧。FollowerStableClosure 的消费取决于 disk thread 的推进，这个是独立工作的 > > > > > > > > > > > > > > > > >...

> > > > > > > > > “FollowerStableClosure消息的消费依赖于NodeImpl的析构” 这一条不成立吧。FollowerStableClosure 的消费取决于 disk thread 的推进，这个是独立工作的 > > > > > > > > > > > > > > >...

还有一个思路，在你说的 (1) 的基础上做一下改进，stop 的时候插入一个 barrier stop 事件，在这个事件之后的请求 done->Run() 新启协程执行，barrier 的状态只有 disk thread 会关心，这里不需要加任何竞争保护，stop之后的开销退化应该也是可以接受的，新事件的插入是个小概率事件

@zhongleihe review 一下这个pull request，看看有没有问题

> > @zhongleihe review 一下这个pull request，看看有没有问题 > > 没啥问题，我们也这样修改下，正好验证下。我们这边的复现概率很高 嗯，可以

group之前独立，如果要控制leader分布，可以用tranfer leader和vote接口。

> 可能是我表述有点问题，其实我想问的就是LogManager控制持久化的这部分，是怎么做的？是有专门的线程负责检测日志变更然后持久化？是来一条日志就持久化，还是定时持久化或者达到例如1000条就持久化？ 你想问的是 raft_sync_segments、raft_sync、raft_sync_meta 这几个选项吧。 1. raft_sync = true 是每一次写盘之后进行持久化，如果不开启的话，数据是在 page cache 内，掉电有丢失风险。braft 内部有一些 batch 合并的策略，这个选项是针对每次 batch 的； 2. raft_sync_segments = true 会在切换 log segment 的时候进行持久化，默认是 8 MB，由 raft_max_segment_size 控制；...

> 感谢解答！但是还有几个疑问： > > > raft_sync = true 是每一次写盘之后进行持久化 > > 这里的写盘难道不是持久化？ > 另外Batch合并的策略是怎么样的？ > > > raft_sync_segments = true 会在切换 log segment 的时候进行持久化 > > 切换log segment是什么意思呢？ 目前默认的 log...

> @PFZheng 然后我想问另外两个问题。 > > 1. Client 在找到Leader这块，braft是采用什么策略来处理的？ > 2. Client在发送请求之后，未收到响应之前，如果Leader挂了，这种场景应该怎么处理？ 首先，一个复制组里有哪些节点，这个是业务控制的，所以，业务需要记录有效节点集合，这个可以用 dns、zookeeper、或者业务自己记录等手段来实现。 在这个前提下，就意味着可以找到复制组中的任意一个节点。这个节点可能是leader或者follower。leader 在 on_leader_start 后知道自己是 leader，处理请求没问题；follower 在 on_start_following 调用中拿到 leader 的信息，业务需要记录一下，然后在节点上做 redirect 或者把这个 leader hint 信息返回给 client，client 做redirect。...

> > @PFZheng 然后我想问另外两个问题。 > > > > 1. Client 在找到Leader这块，braft是采用什么策略来处理的？ > > 2. Client在发送请求之后，未收到响应之前，如果Leader挂了，这种场景应该怎么处理？ > > 首先，一个复制组里有哪些节点，这个是业务控制的，所以，业务需要记录有效节点集合，这个可以用 dns、zookeeper、或者业务自己记录等手段来实现。 > > 在这个前提下，就意味着可以找到复制组中的任意一个节点。这个节点可能是leader或者follower。leader 在 on_leader_start 后知道自己是 leader，处理请求没问题；follower 在 on_start_following 调用中拿到 leader...