wxun

> 内部版本在测试这个功能，时机成熟了会同步到github 期待，能问下大概的预期时间吗

> braft::SegmentLogStorage::get_segment (this=0x7f6f7d45af70, group_id=12638, index=62666) 看起来根源是这个锁，这里有做改动吗？ > > 这儿有个嵌套。replicator 的 bthread id lock 里会去拿 Segment 的锁。Node 里有周期性的定时器会拿 replicator的 bthread id lock（获取 last_rpc_send_timestamp），Segment 锁住会造成整个 node 的锁竞争。这个地方目前在内部版本已经改了，还没同步过来。不过这个锁竞争仍然是 butex 的，不应该占住线程，主要还是看 get_segment 为什么会锁住。 这个锁想问下内部版本是怎么改的，优化了吗

> > > braft::SegmentLogStorage::get_segment (this=0x7f6f7d45af70, group_id=12638, index=62666) 看起来根源是这个锁，这里有做改动吗？ > > > 这儿有个嵌套。replicator 的 bthread id lock 里会去拿 Segment 的锁。Node 里有周期性的定时器会拿 replicator的 bthread id lock（获取 last_rpc_send_timestamp），Segment 锁住会造成整个 node 的锁竞争。这个地方目前在内部版本已经改了，还没同步过来。不过这个锁竞争仍然是 butex 的，不应该占住线程，主要还是看...

了解了，感谢回复，另外第2条中提到的实践经验中，“并发的change peer 后不gc数据可能导致脑裂”这个场景是怎么理解，每次某个组做change peer操作时候不是都会有状态busy检查吗，本身就不允许做并发变更

> 配置文件里加上： > --raft_enable_leader_lease=true > 然后在每次 leader 读之前调用一次 is_leader_lease_valid 可以保证线性一致读 leader apply比较快，而follower apply慢，但某个点follower当选了leader，只依赖leader的判断这个时候不能直接读吧？

本质在于你这个场景操作是非法的，不能强删本地数据，里面会有raft组元信息等配置，这个是不允许的，下线机器只能通过change_peers完成

这个应该是业务逻辑定制实现的吧，上层业务自主检测节点挂掉，然后change_peers到其他节点