doc001

每个peer看到的conf可能是不一样的，如果去检查server_id是否在当前的_conf成员列表，可能没法选出主。例如，一个 3 节点的复制组，发生过很多次配置变更，现在有效节点是 {7, 8, 9}，9 刚加入，日志滞后很多，本地的 conf 还停留在很早的版本，如 {1, 2, 3}，这时候 7、8 里挂掉一个，如果判断 server_id，就选不出主来了

你说的第二个问题不会发生，这里有个隐含的前提是，投票是依据自己看到的 conf，一个没加入的节点，是不会被大家看到的

看错误是leveldb的编译存在问题，需要添加-fPIC编译参数

这个由业务逻辑来实现更合理。挂掉这件事情，包含很多可能性，对于网络分区而言单个节点是无法判断是自己有问题，还是别人有问题。

> > 这个由业务逻辑来实现更合理。挂掉这件事情，包含很多可能性，对于网络分区而言单个节点是无法判断是自己有问题，还是别人有问题。 > > 这种在业务层怎样实现比较好，有相应经验吗？ 我想到一个是每个节点都对其他所有节点定期进行健康检查，当检查到节点连不上就向master apply一条日志，master若检查到超过半数节点都认为该节点失联才认为该节点失联。 @PFZheng 这儿其实可以抛开raft看看业务是怎么管理物理节点的，这个和其他系统是一样的。HDFS/GFS 这类系统看看中心节点怎么处理的，其他非中性化的系统也有类似的机制处理节点加入和离开。在判断节点加入和离开之后，发起change peer。

brpc的内存分析页面看了吗

有需求你可以考虑贡献一个，哈哈

> > 有需求你可以考虑贡献一个，哈哈 > > 话说，为啥最开始没有这个呢。定时已经够用了？ 嗯，定时够用了

> This leads to the following errors on a cross region set-up where latency between nodes can be high: The reason why the connect timeout is not set is that,...

是的。braft没有记录committed index，业务层自己记录了的话，是可以跳过一部分数据的redo的