# Lab4 分片kv服务(上)(配置服务器)
1.介绍
- Lab3中我们在raft基础上实现了基本的kv服务和log压缩。
- Lab4进一步实现分片式的kv服务，所有key都能得出一个hash值，然后按hash值把key存在不同的节点(或节点集合)。
任务分为AB两部分。A实现一个shardmaster，类似于一个管理调度程序。B实现shardserver，具体的kv服务器。本文讲A部分。
2.The Shard Master基本数据
- shard
分片，数据的某一部分集合。整个系统的数据会分散在各个分片里。 -
group
server的集合。包含一个或多个server。 -
shard与group的关系
一个shard只可属于一个group。一个group可包含(管理)多个shard。
比如
10个shard，3个group。
2个shard里的数据交给group1去储存。
3个shard里的数据交给group2去储存。
group3里机器最多，剩余的5个shard都交给group3去储存。
基本原则是把数据平均分配到所有机器。
提炼出来的核心数据就是一个Config结构体，即一份节点的配置，即shard和group的具体定义。
type Config struct {
Num int // config number
Shards [NShards]int // shard -> gid NShards为分片数量。定为10
Groups map[int][]string // gid -> servers[] 哪个group id包含了哪些server
}
- Num，配置的id。
Shards，每个分片所属的group id(gid)。
Groups，每个group里的server列表。
3.主要操作(命令)
- join
让某些group加入集群。
参数类型为map[int][]string
比如{1:"x", "y", "z"}和{2:"a", "b", "c"}，即把1和2两个group加入集群。1包含xyz三个server，2包含abc三个server。 -
leave
让某些group离开集群。
比如leave(2)，那么group2就要离开集群，这时里面的abc三个server是存了某些shard的数据的，得把这些shard还给系统，分到其他的group里，最后把group2断开。 -
query
获取某一份config。 -
move
把某个shard交给某个group。即把这个shard的数据挪到指定的group，从此被指定的group管理。
shardmaster主要就是要维护一串配置(Config的数组)(对标kvserver的键值对数据)。
一样是client/server架构，利用raft来保证配置数据的一致和可靠。raft里的log项就是一个个join/leave/query/move操作。
4.基本流程
-
想通了上述的逻辑，流程其实就很简单了，无非就是通过client发各种操作，加上一系列人工障碍(A部分测试没加障碍，但是B部分会依赖于A，如果到时B部分出了问题还得回来看)。
最后所有操作需要达成一致，得到预定的结果。跟lab2的kvserver是一个模式。 -
要做的工作就是抽象一下所有操作(命令)，填入kvserver的框架，操作得到apply以后，按各个操作的定义更新config。
-
这个服务虽简单，但是一样很有意义，用raft实现了另一套新的数据结构和操作的维护。扩展了思路。
5.其他
- 巨坑的labrpc
之前的代码Op的成员都是string或int等基本类型。现在的操作变复杂，要传入map、数组等。
我加了个interface成员，可随意传入不同操作的参数。
发现发送AE时，接收AE处解不出Op，解出来是nil。
肯定是labgob里编码、类型转换的问题，看又看不懂折腾半天。
最后发现StartServer里有个labgob.Register(Op{})，网上也有人提到要注册类型。尝试进行额外的labgob.Register。
join的rpc参数是Servers，类型为map[int][]string。
labgob.Register(map[int][]string{})这样注册一下解决。
有恶心到。
