mit6.824lab4-4A

实验简介

这个实验我感觉比前三个，更难理解。最后是根据下面的这段话，才懂得。

Sworduo(http://sworduo.net/2019/08/16/MIT6-824-lab4-shardKV/#more)：

Lab2和Lab3构成基础分布式数据库的框架，实现多节点间的数据一致性，支持增删查改，数据同步和快照保存。然而，在实际应用中，当数据增长到一定程度时，若仍然使用单一集群服务所有数据，将会造成大量访问挤压到leader上，增加集群压力，延长请求响应时间。这是由于lab2和lab3所构成的分布式数据库的核心在于分布式缓存数据，确保在leader宕机后，集群仍然可用，并没有考虑集群负载问题，每时每刻，所有数据请求都集中在一台机器上，显而易见的，在数据访问高峰期，请求队列将会无比漫长，客户等待时间也会变长。一个非常直接的解决方法，就是将数据按照某种方式分开存储到不同的集群上，将不同的请求引流到不同的集群，降低单一集群的压力，提供更为高效、更为健壮的服务。

Lab4就是要实现分库分表，将不同的数据划分到不同的集群上，保证相应数据请求引流到对应的集群。这里，将互不相交并且合力组成完整数据库的每一个数据库子集称为shard。在同一阶段中，shard与集群的对应关系称为配置，随着时间的推移，新集群的加入或者现有集群的离去，shard需要在不同集群之中进行迁移，如何处理好配置更新时shard的移动，是lab4的主要挑战。

一个集群只有Leader才能服务，系统的性能与集群的数量成正比。lab3是一个集群，lab4A要实现的是多个集群之间的配合。

参考：

• https://www.jianshu.com/p/6e8d33c3c799

4A

First you’ll implement the shard master, in shardmaster/server.go and client.go.

// 数据库子集和集群之间的关系
type Config struct {
   
   
    // config的版本号
	Num    int              
    // shards[0] = g0：代表数据库子集[0]由集群g0负责
	Shards [NShards]int     // shard -> gid
	Groups map[int][]string // gid -> servers[]
}

CLient

Client的实现跟3A一样。

Server

逻辑和3A也是一样。每一次变化，都要新增一个Config。

• Join：把这些GID 组，加到MASTER的管理范围里来。
• Leave：移除几个集群。
• Query：查询具体的Config
• Move：指定某个数据库子集归哪个集群管。

注意

如果你的Op中包含自定义字段，请在lagob中注册。因为Raft需要把我们Start的命令追加到日志中，然后Leader通过RPC发送追加日志请求给Follower。需添加如下代码：

labgob.Register(Op{
   
   })
labgob.Register(JoinArgs{
   
   })
labgob.Register(LeaveArgs{
   
   })
labgob.Register(MoveArgs{
   
   })