shardKV 算是一个 multi-raft 实现，工作方式大概是：在开始的时候系统会创建一个 shardmaster 来负责配置的管理任务，然后会创建多个 raft 组来负责多个数据分片的读写任务。在这个过程中，实验的 test case 会涉及到 raft 组的修改，raft 节点的故障、重启，以及在分块网络或者不可靠网络中系统的运行。
TA 给出了一些 Hint：
- server 需要定期询问 shardctrler 来获得新的配置，预期大概100ms一次，可以更频繁，但是少于他可能会导致bug
- server 需要互相发送 rpc以便在配置更改期间传输分片。shardctrler 的 Config 结构包含服务器名，一个 server 需要一个 labrpc.ClientEnd，以便发送 RPC。使用 make_end() 来转换（这一点本身存在的示例代码中有写法）
- server 对于请求中分片不属于自身的情况需要拒绝请求
- 请求错误的分片时，需要返回 ErrWrongGroup给client
- ......
在 raft 集群内部，需要分片能够被均匀的分配到 raft 组上，还要能够支持动态的迁移。在外部来看，需要表现的像一个整体的 KV 服务，有线性一致性。这些也是 Lab 4B 的测试中要求的。并且有两个额外的 challenge。一是要求及时清理不再属于本分片的数据，二是不仅要求分片迁移的时候不影响未迁移的分片的读写服务，还要求不同的分片数据能够独立的迁移，即如果一个配置导致当前 raft 组需要向其他两个 raft 组拉取数据的时候，即使其中一个挂了，也不能影响另一个提供服务。
需要首先明确的是，所有涉及到状态机变化的操作（配置变更，KV数据的读写）都应该通过 raft 日志的方式来保证其一致性，并且只能通过 raft leader 来进行日志的更新。