成员变更在一致性协议里稍复杂一些，由于不同的成员不可能在同一时刻从旧成员组切换至新成员组，所以可能出现两个不相交的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)