迷雾总会解

每个 shardkv 服务器都作为副本组的一部分运行。每个副本组为某些键空间分片提供 Get、Put 和 Append 操作。在 client.go 中使用 key2shard() 来查找 key 属于哪个 shard。多个副本组合作为完整的分片集提供服务。 shardctrler 服务的单个实例将分片分配给副本组；当这个分配发生变化时，副本组必须相互传递分片，同时确保客户端不会看到不一致的响应。我们的存储系统必须为使用其客户端接口的应用程序提供可线性化的接口。也就是说，对 shardkv/client.g

在本实验中，我们将构建一个带分片的KV存储系统，即一组副本组上的键。每一个分片都是KV对的子集，例如，所有以“a”开头的键可能是一个分片，所有以“b”开头的键可能是另一个分片…。分片的原因是性能。每个replica group只处理几个分片的 put 和 get，并且这些组并行操作；因此，系统总吞吐量（每单位时间的投入和获取）与组数成比例增加。replica groups(复制组)。每个replica group负责分片的一个子集。副本由少数使用 Raft 复制组的分片的服务器组成；

切片默认是进行浅拷贝的，因此leader在向某个follower发送AppendEntries RPC时，在生成args到发送rpc这段时间内(这段时间没有上锁，上锁就太浪费资源了)，如果进行一次Snapshot(生成快照)，那么就会导致args的logEntries发生变化，原本存在的数据，进行一次快照后可能会进行删除，进而导致发送给follower的logEntries的某些日志的Command变为nil了。每应用完一条普通命令，就要调用saveSnapshot函数判断是否进行一次快照生成。......

lab3 的内容是要在 lab2 的基础上实现一个高可用的 KV 存储服务，算是要将 raft 真正的用起来。而在该任务中，要处理一个很重要的事情，就是线性化语义，也可以要求每个请求要具有幂等性。考虑这样一个场景，客户端向服务端提交了一条日志，服务端将其在 raft 组中进行了同步并成功 commit，接着在 apply 后返回给客户端执行结果。然而不幸的是，该 rpc 在传输中发生了丢失，客户端并没有收到写入成功的回复。...

做到显示为止，我们重启的服务器会重放完整的 Raft 日志以恢复其状态。但是，长期运行的服务永远记住完整的 Raft 日志是不切实际的。因此，我们可以做一个快照，快照存储了在某一个index之前的所有日志的一个状态， Raft 就可以看丢弃快照之前的日志条目。结果是更少量的持久数据和更快的重启。我2D部分最后一个测试没有通过，找了很久，始终没发现问题，不想搞了，暂时这样吧。大体的思路我觉得没有问题。最后一个测试没有通过，找了很久，始终没发现问题，不想搞了，暂时这样吧。.........

一个真正的实现是将 Raft 的持久状态在每次更改时写入磁盘，并在重新启动后重新启动时从磁盘读取状态。但是在我们的实现中，并不会真正的在磁盘中进行操作；Raft 应该从那个 Persister 初始化它的状态，并且应该在每次状态改变时使用它来保存它的持久状态。使用labgob编码器；具体的使用方法可以查看官方给出的persist() 和 readPersist() 中的注释。Lab2C真正难的地方在于它严苛的测试，涉及到节点的反复选举、宕机与重新上线、状态恢复、网络断开、日志未提交等等问题。...

tryCommitLog是从已经提交的index+1开始遍历后面的日志，只要一个节点的matchIndex大于等于当前日志的index，就表明该节点已经接收了该日志，如果日志达到了多数派，就可以提交了。并且将新提交的日志进行应用。这里有一个快照的判断，可以不用管，因为在我的实现中，快照命令和日志中记录的命令是两种不同的命令，并不会占用日志的index，在follower接收到一份快照后，会单独的发送快照命令给applyCh。遍历的过程中，只要有一条日志没有达到多数派，后面的日志也可以不用计算了。......

当进入第二部分，就是正式的开始raft的设计了，相信要写这个项目的人应该对raft算法不算陌生，如果在编写raft的代码的时候，可以仔细琢磨一下raft的论文。👉而在第二部分，一共分为四个小任务：leader选举、日志复制、持久化、日志压缩。代码写在raft文件夹中，除了进行对应的任务的完成，我强烈建议阅读、config.go这两个文件，以及labrpc.go文件。.........

本文是对MIT6.824中lab1 MapReduce的介绍和代码实现

文章目录引言zinx项目结构serverconnectionmsgHandlerroutermessagerequestconnmanagerdatapackglobalobj服务器创建客户端创建流程分析MMO游戏介绍玩家的上线世界聊天系统多人位置同步移动位置同步玩家下线项目结构mainaoigridplayerworldmanagerroutermoveworld_chatmsg.proto引言在该项目中有两个部分，一个是zinx，一个是mmo_game，zinx是一个tpc框架，而mmo_game是

在go中使用protobuf的过程