1. raft snapshot里存储的到底是啥？为啥installsnapshot就能恢复之前的全部数据状态？
是根据业务类型的不同有不同的存储实现，比如curvebs，管理的是文件系统里的chunkfile文件，curvefs是rocksdb，快照的实现也完全不同，但都是在raft状态机的
on_snapshot_save方法里执行的raft snapshot流程。bs存储的是状态机元数据+chunfile文件列表，fs存储的则是状态机元数据+rocksdb的checkpoint数据。
2. 一个新加入的follower，比如换盘，怎么恢复出来全部数据的？
参考问题1
3. 配置变更的流程是？以add/remove peer为例进行说明。为啥Leader启动的时候要发送NO_OP请求？
4. 节点视图（类似osdmap）配置（论文中应该是叫configuration）是如何持久化的？
5. 为了支持follower读，Client的读取中带上CommittedId，怎么获取的？
在Raft协议中，为了支持Follower节点的读取，Client在读请求中携带CommittedId。这个CommittedId表示已经提交的日志条目的索引。
具体获取CommittedId的过程如下：
- Leader节点确认CommittedId：Client首先向Leader节点发送一个读请求。Leader会检查自己的已提交日志条目，并确定一个CommittedId，表示已经提交的最新日志条目的索引。
- Leader将CommittedId返回给Client：Leader将确定的CommittedId作为响应返回给Client。这个CommittedId可以用于后续的读请求。
- Client使用CommittedId进行读取：Client在后续的读请求中携带这个CommittedId。Follower节点会根据这个CommittedId来判断是否可以读取数据。只有当Follower节点的已提交日志条目的索引大于等于CommittedId时，才能返回数据给Client。
需要注意的是，如果网络分区或其他异常情况导致Follower节点的已提交日志条目滞后，读取可能会受到影响。因此，一些实际场景中可能需要考虑过期读取等机制来处理这种情况。
6. installsnapshot是否意味着全量恢复？本地如果还有chunkfile但是数据比较老，是否会从leader上拉取覆盖本地的？
installsnapshot并不能完全恢复之前的数据状态，还有一部分snapshot做完之后变更的数据要通过logentry的重放进行恢复。对bs来说，因为是支持原地改写（覆盖写），而且logentry也是保序的，所以可以认为对chunkfile的修改是幂等的，通过installsnapshot拿到所有的chunkfile列表之后，从leader节点同步chunkfile数据过来（如果本地的chunkfile的checksum和leader的不一致就拉过来，一致就不需要），重放之后的logentry，就能保证跟leader上的chunkfile最终达成一致的结果。
fs则是通过rocksdb的mvcc来保证数据的一致性。
