mapreduce中包含了两个角色，coordinator和worker，其中，前者掌管任务的分发和回收，后者执行任务。mapreduce分为两个阶段，map阶段和reduce阶段。
map阶段对应的是map任务。coordinator将会把任务分成多个部分，例如，有多个文件待处理，则每个文件的处理是一个任务。coordinator根据待处理文件生成多个任务，将这些任务用available管道暂存，供worker取用。worker将任务完成之后，需要告知coordinator，coordinator需要记录任务的状态。为了标识任务，每个任务需要有唯一的taskId。coordinator可以用taskId为key的map来存储所有task，worker完成一个task之后，这个task就没有必要保存，coordinator可以从map中删除该task。coordinator存储未完成的task，除了供worker比对之外，还可以用来重新分发超时的任务。worker调用coordinator的applyForTask函数，来从avaliable队列中得到新的任务。在map阶段，worker收到任务后会调用mapf函数，这个函数是用户传入的参数，指向任务的具体执行过程。对mapf的执行结果，worker根据reduce的个数，将执行结果hash成reduce份。例如，对于wordcount任务，每个文件中的词的统计数量将根据词分为reduce份，保存在reduce个文件中。
reduce阶段对应的是reduce任务。coordinator将生成reduce个新的任务，每个任务处理一个hash桶中的内容。同样用available管道供worker取用。当然，这时worker只需要知道自己取到的是第几个hash桶对应的reduce任务，即可通过共享文件和统一的文件命名规则获取到此时需要处理的文件。根据用户reducef函数的输入，worker将输入文件中的内容排序之后，将相同key的value存储成数组，输入reducef函数处理。
值得探讨的点：
worker通知coordinator任务完成：worker对任务完成的通知可以不必发一个新的包，因为worker每次完成任务的同时都会立即向coordinator请求新的任务，因此可以在请求包中附送上一个已经完成的taskId。coordinator经过比对taskId和workerId确认无误之后，在分发新任务之前就可以处理旧的已完成任务。
超时任务检测：有两种选择，1是worker接收任务之后定时发心跳包，但是这种方式较为繁琐。另一种是coordinator定时检查，task的map中对每个task维护一个ddl，若当前时刻已经超过了ddl时间，就视为超时。
available管道初始化容量：不初始化容量的话，管道会阻塞。
任务结果文件重命名：worker处理阶段，为了防止其他worker也在处理这一文件导致的写冲突，会将处理结果文件命名中加上workerId，但reduce阶段不需要知道map结果是由哪个worker生成的，因此coordinator确认任务完成后会对结果文件重新命名，去掉workerId的标记。reduce阶段同理。
raft是一个分布式共识算法。分为领导选举【Leader election】、日志复制【Log replication】和安全【Safety】。
在一个raft集群中，server总是在三种状态之间转换，follower、candidate、leader，且保证任何时刻系统中最多只有一个leader。系统将时间划分为多个term，term顺序递增，candidate进行选举的时候会先将自身的term加一，表示自己认为已经可以开始新的term了。在一个term内的稳定状态下，raft集群中只有一个leader，其余的server是follower，系统所处term的切换意味着leader的切换。leader定时向其余服务器发送一个heart beat心跳信息，表示自己仍然存活，此外，接收外界对raft系统的数据请求，提供对外服务，生成日志条目，并且将日志条目复制给其他的follower，以此实现数据的多存储；follower接受leader发送的heart beat，确认当前系统存在leader，并且接收leader发来的日志条目副本，更新本地的日志。
【Leader election】若follower的heart beat超时，即，在一段时间内都没有收到leader发来的heart beat。此时，这台follower认为leader已经挂掉，于是自动转化为candidate状态，开始竞选成为新一期的leader。candidate将自身的term加一，投票给自己，同时向所有server发送requestVote的请求，对于收到requestVote请求的服务器来说，只要它们在这个term没有投出票，则投给这个candidate，换句话说，一个server在一个term只能投一次票。在一轮投票中，若所得票数大于总服务器数量的一半，则赢得选举，成为本期leader，同时立即发送一条heart beat宣布上任，系统回到稳定状态。同一时刻允许同时存在多个candidate，此时可能会出现选票平分的情况，这时无法选出新的leader，candidate将重新发起投票，并且term再加一。重新投票将会影响系统的性能，为了减小同时出现多个candidate的可能性，每台server的heart beat超时时间（等待heart beat的时间）将设置为一个区间范围内的随机数。一般要求：heart beat时间<<选举超时时间<<平均故障时间。