etcd中raft协议的消息(一) —— 简述raft中的所有类型消息
etcd中的Raft算法简介
Raft 是一种为了管理复制日志的一致性算法。一致性算法是从复制状态机的背景下提出的（参考英文原文引用37）。在这种方法中，一组服务器上的状态机产生相同状态的副本，并且在一些机器宕掉的情况下也可以继续运行。复制状态机在分布式系统中被用于解决很多容错的问题。例如，大规模的系统中通常都有一个集群领导者，像 GFS、HDFS 和 RAMCloud，典型应用就是一个独立的的复制状态机去管理领导选举和存储配置信息并且在*宕机的情况下也要存活下来。比如 Chubby 和 ZooKeeper。
etcd是使用Raft算法来保持一致性的，etcd集群中每个节点都维护一个状态机，在任何时刻，每一个服务器节点都处于这三个状态之一：*、跟随者或者候选人。在通常情况下，系统中只有一个*并且其他的节点全部都是跟随者。跟随者都是被动的：他们不会发送任何请求，只是简单的响应来自领导者或者候选人的请求。*处理所有的客户端请求（如果一个客户端和跟随者联系，那么跟随者会把请求重定向给*）。第三种状态，候选人，是用来在 5.2 节描述的选举新*时使用。图 4 展示了这些状态和他们之间的转换关系；这些转换关系会在接下来进行讨论。
集群中每个节点内部以及节点之间用不同类型的消息进行通讯，本系列文章主要分析raft中不同类型的消息，以及节点在不同状态下对不同类型消息的不同处理行为。
消息类型
raft中的所有消息类型在raft.pb.go文件中，消息类型如下
MsgHup MessageType = 0 //当Follower节点的选举计时器超时，会发送MsgHup消息
MsgBeat MessageType = 1 //Leader发送心跳，主要作用是探活，Follower接收到MsgBeat会重置选举计时器，防止Follower发起新一轮选举
MsgProp MessageType = 2 //客户端发往到集群的写请求是通过MsgProp消息表示的
MsgApp MessageType = 3 //当一个节点通过选举成为Leader时，会发送MsgApp消息
MsgAppResp MessageType = 4 //MsgApp的响应消息
MsgVote MessageType = 5 //当PreCandidate状态节点收到半数以上的投票之后，会发起新一轮的选举，即向集群中的其他节点发送MsgVote消息
MsgVoteResp MessageType = 6 //MsgVote选举消息响应的消息
MsgSnap MessageType = 7 //Leader向Follower发送快照信息
MsgHeartbeat MessageType = 8 //Leader发送的心跳消息
MsgHeartbeatResp MessageType = 9 //Follower处理心跳回复返回的消息类型
MsgUnreachable MessageType = 10 //Follower消息不可达
MsgSnapStatus MessageType = 11 //如果Leader发送MsgSnap消息时出现异常，则会调用Raft接口发送MsgUnreachable和MsgSnapStatus消息
MsgCheckQuorum MessageType = 12 //Leader检测是否保持半数以上的连接
MsgTransferLeader MessageType = 13 //Leader节点转移时使用，本地消息
MsgTimeoutNow MessageType = 14 //Leader节点转移超时，会发该类型的消息，使Follower的选举计时器立即过期，并发起新一轮的选举
MsgReadIndex MessageType = 15 //客户端发往集群的只读消息使用MsgReadIndex消息（只读的两种模式：ReadOnlySafe和ReadOnlyLeaseBased）
MsgReadIndexResp MessageType = 16 //MsgReadIndex消息的响应消息
MsgPreVote MessageType = 17 //PreCandidate状态下的节点发送的消息
MsgPreVoteResp MessageType = 18 //预选节点收到的响应消息接下来的文章会对etcd中每个节点的消息进行详细说明。
主要参考是《etcd技术内幕》