处理leader和follow的一个重要思路是多数投票，确保系统中存在奇数个服务器（例如3台）。进行任何操作都需要来自多数服务器的同意，例如3台服务器中的2台。如果没有多数同意，系统会等待。为什么多数投票有助于避免脑裂问题呢？ 至多一个candidate能够占据多数，这打破了只有两台服务器的情况下所见到的对称性。 注意：多数是基于所有服务器，而不仅仅是活跃的服务器。注意：在获得多数后继续进行，不

为了让技术栈更宽一点，想学习一下分布式系统，顺便下定决心学习一下go语言吧！ 由于还没有开始学，这里只总结相关的资料，后续会慢慢进化成MIT6.824课程导学。 Go语言 MIT6.824课程是用go语言来完成的，所以了解一下go语言是非常有必要的，个人通过w3csshool上的基础入门资料完成的：https://www.w3cschool.cn/go/go-tutorial.html

引言 lab3A的实验要求如下： Your first task is to implement a solution that works when there are no dropped messages, and no failed servers. You’ll need to add RPC-sending code to the Clerk Put/Append/Get met

本实验中，不同clientId的用户会向当前认为是leader的kvServer发送请求 集群中有多个kvServer，每个绑定了一个Raft 集群中的kvServer会不断执行指令更新自身状态，也因此在写代码时要对ops的来源进行区分 来源1：client认为当前kvServer是leader节点，直接发送RPC请求过来执行指令，因此kvServer根据指令更新自身状态时也需要对

1. 简介 在这个 Lab 中，我们将建立一个 MapReduce 库，作为使用 GO 编程和构建一个分布式容错系统的初步。在第一个部分，我们将会写一个简单的 MapReduce 程序。在第二个部分，我们将会写一个 Master，去向 workers 分发任务已经 handle workers 的错误。 2. Software 2.1. Go 环境 官方下载 go1.9 源码golang.

总结：本节课讲解了一些会在lab2中使用到的go的多线程技巧，会给一些简单的demo，lab2中可能会借鉴这些demo。 详细的Lab2的每一个part的raft算法实现源码，请参考我的个人仓库，记得切换到对应的Lab2X分支，Lab2A是只包含实现leader选举方面的代码，Lab2B目前正在开发中（记得点颗星星）, 配合readme食用更佳。 MIT6.824 1 sync.WaitG

本部分主要是关于不一致的日志是怎么决策和取舍的。同时对于日志的恢复，通过快照的方式提高恢复的效率。 1. 不一致log的处理 在我们分析之前，我们需要明白这个场景是否真的存在，因为有些场景不可能存在我们也就没必要考虑它。即需要思考这种情况可能发生吗？如果可能发生，是怎么发生的？ 一个旧Leader在各种奇怪的场景下故障之后，一个新任的Leader如何能整理在不同副本上可能已经不一