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的具体定义。

1
2
3
4
5

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.主要操作(命令)

1. join
   让某些group加入集群。
   参数类型为map[int][]string
   比如{1:"x", "y", "z"}和{2:"a", "b", "c"}，即把1和2两个group加入集群。1包含xyz三个server，2包含abc三个server。

2. leave
   让某些group离开集群。
   比如leave(2)，那么group2就要离开集群，这时里面的abc三个server是存了某些shard的数据的，得把这些shard还给系统，分到其他的group里，最后把group2断开。

3. query
   获取某一份config。

4. 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{})这样注册一下解决。
  有恶心到。