mit_6.824_2021_lab4A_The_Shard_controller

mit_6.824_2021_lab4A_The_Shard_controller

lab4 系列除了构建一个 键值存储系统，还需要将系统按键 分片(shard) 或对一组副本进行分区；

分片的策略有很多，比如：所有以 “a” 开头的键是一个分片，所有以 “b” 开头的键是一个分片，等等

为什么需要分片？从性能考虑，每个副本只处理一部分分片的 put 和 get，并且这些副本之间是支持并行操作的；因此，系统的总吞吐量和副本的数量成比例增加

shard kv 系统组成

分片键值对存储系统将由两个组件组成；

首先是一组副本，每个副本负责处理分片的一部分。一个副本由使用 raft 副本组分片的服务器组成。

第二个组件是 分片控制器，分片控制器决定哪个副本组对应服务哪个分片，即管理配置信息。配置随时间变化，客户端咨询 分片控制器，寻找对应 key 的副本组，而 副本组会请求控制器，以找到需要装载的分片。分片控制器是单例，采用 raft 实现容错。

shard kv 系统功能

分片存储系统必须能在多个副本组之间转移分片，需要支持该功能的原因是：一某些组的负载可能会比其他组重，移动分片来实现负载均衡；二是某些组可能会加入或退出系统，又或者增加新的组以增加分片容量，或将已有的副本组下线修复

实验挑战

处理重新配置功能，即将分片重新分配给副本组。在一个副本组中，所有组成员必须就客户端的请求在进行重新配置时达成一致。如，请求在重配置的同时到达，重配置导致副本组不再对持有该键的分片负责。所以组中的所有副本服务器必须就请求在重配置前还是后达成一致，如果在重配置前，则请求生效，分片的新所有者需要看到生效效果。否则，请求无法生效，客户端必须在新所有者处重新请求。

推荐的方法是，让每个副本组使用 raft，不仅记录请求的序列，还记录重配置的序列；需要确保在任何时间最多只有一个副本组为所有分片提供服务

重配置还涉及到副本组之间的交互，如在配置编号10中，G1组负责分片S1，配置11中，G2组负责分配S1。在10到11 的配置变换过程中，G1和G2需要使用RPC将分片S1内容做迁移

只有RPC可以用于客户端和服务器之间的交互。服务器的不同实例不允许共享Go变量或文件，逻辑上是物理分离的

重配置将分片分配给副本组，重配置不是 raft 集群成员变更，我们不需要实现 raft 集群成员变更

关于生产环境

这个实验的通用架构：一个配置服务和一组副本；与Flat Datacenter Storage、BigTable、Spanner、FAWN、Apache HBase、Rosebud、Spinnaker和其他许多通用模式类似。

但是生产环境中的系统更复杂，功能更强；例如，lab 中不会变更每个 raft 组中的服务器集合（成员变更），其数据和查询模型也十分简单（目前是简单的 kv 存取），分片切换速度很慢，还不允许客户端并发访问（如何客户端允许并发，那之前lab3 的线性一致性不能得到保证了）

lab4 和 la