成员变更在一致性协议里稍复杂一些，由于不同的成员不可能在同一时刻从旧成员组切换至新成员组，所以可能出现两个不相交的majority，从而导致同一个term出现两个leader，进而导致同一个index的日志不一致，违反一致性协议。下图是个例子：
raft作者提出了一种比较简单的方法，一次只增加或减少一个成员，这样能够保证任何时刻，都不可能出现两个不相交的majority，所以，可以从旧成员组直接切到新成员组。如下图：
切换的时机是把成员变更日志写盘的时候，不管是否commit。这个切换时机带来的问题是如果这条成员变更日志最终没有commit，在发生leader切换的时候，成员组就需要回滚到旧的成员组。
etcd raft为了实现简单，将切换成员组的实机选在apply成员变更日志的时候。
下面看看etcd raft library如何实现的：
应用调用
func (n *node) ProposeConfChange(ctx context.Context, cc pb.ConfChange) error {
data, err := cc.Marshal()
if err != nil {
return err
}
return n.Step(ctx, pb.Message{Type: pb.MsgProp, Entries: []pb.Entry{{Type: pb.EntryConfChange, Data: data}}})
}
可以看出，ConfChange是和普通的log entry一样封装在MsgProp消息中，进入propc，
跑raft算法的goroutine从propc中拿到消息后，会做如下判断：
for i, e := range m.Entries {
if e.Type == pb.EntryConfChange {
if r.pendingConf {
r.logger.Infof("propose conf %s ignored since pending unapplied configuration", e.String())
m.Entries[i] = pb.Entry{Type: pb.EntryNormal}
}
r.pendingConf = true
}
}
检查已经有成员变更正在做，就忽略新的成员变更。然后将pendingConf置为true，意味着目前有成员变更正在做了，从这里可以看出，多个成员变更不能同时进行。follower接收端的处理和普通log entry一样。
如果成员变更日志达成了一致，则会被封装在Ready中，应用拿到后，做如下处理：
if entry.Type == raftpb.EntryConfChange {
var cc raftpb.ConfChange
cc.Unmarshal(entry.Data)
s.Node.ApplyConfChange(cc)
}
ApplyConfChange：
func (n *node) ApplyConfChange(cc pb.ConfChange) *pb.ConfState {
var cs pb.ConfState
select {
case n.confc <- cc:
case <-n.done:
}
select {
case cs = <-n.confstatec:
case <-n.done:
}
return &cs
}
讲ConfChange放入confc，然后阻塞在confstatec上，跑raft协议的goroutine从confc中拿出ConfChange，做相应的增加/删除节点操作，然后将成员组放入confstatec。
switch cc.Type {
case pb.ConfChangeAddNode:
r.addNode(cc.NodeID)
case pb.ConfChangeRemoveNode:
// block incoming proposal when local node is
// removed
if cc.NodeID == r.id {
propc = nil
}
r.removeNode(cc.NodeID)
case pb.ConfChangeUpdateNode:
r.resetPendingConf()
default:
panic("unexpected conf type")
}
select {
case n.confstatec <- pb.ConfState{Nodes: r.nodes()}:
case <-n.done:
}
增加/删除节点操作都只是更新prs，map的每个元素保存一个peer的状态，其中最重要的状态莫过于
Match, Next uint64
看过raft小论文的人一看变量名就很明确意义，Match代表最大的已经落盘的log index，Next代表下一条需要发给这个peer的log index。然后将pendingConf置为false，代表成员变更结束。
重启如何恢复成员组：
hs, cs, err := c.Storage.InitialState()
Storage接口中:
// InitialState returns the saved HardState and ConfState information.
InitialState() (pb.HardState, pb.ConfState, error)
Storage是个接口，其中InitialState()用于恢复成员组，需要应用自己实现,通常将ConfState记在最后一次Snapshot的Metadata中：
message SnapshotMetadata {
optional ConfState conf_state = 1 [(gogoproto.nullable) = false];
optional uint64 index = 2 [(gogoproto.nullable) = false];
optional uint64 term = 3 [(gogoproto.nullable) = false];
}
ConfState:
message ConfState {
repeated uint64 nodes = 1;
}
拿到ConfState后就可以初始化上面提到的prs，snapshot后续的已经commit的log entry一样，通过Ready封装，应用进行apply，如果其中有ConfChange，则调用
s.Node.ApplyConfChange(cc)