consensus协议，有paxos、raft、pacificA，应用最普遍的有paxos。由于paxos难以理解、实现困难，例如日志空洞（leader宕机时，当前leader在上一任leader的任期内可能错过了一些日志的同步, 而这些日志在其他机器上形成多了多数派. 由于logID连续递增, 被错过的日志就成了连续logID连续递增序列中的”空洞”, 需要通过重确认来补全这些”空洞”位置的日志。）的处理等非常复杂，诞生了raft，逐渐替代paxos普遍应用到分布式系统中，例如mongodb、kafka等。 raft 一致性协议，一般是基于replicated state machine，基于这个理论：所有节点处理相同顺序相同内容的指令，结果就会一致。一般是以log的方式实现，将client请求append到log中，并同步给各节点，对raft而言做了简化，只有leader才执行读写，日志只会从leader流向follower，follower只参与选主，平时只做replicate。 consensus解决的实际上是3个问题：选主、log复制、safety(never returning an incorrect result) under all non-Byzantine conditions, including network delays, partitions, and packet loss, duplication, and reordering.)。 client请求只要大多数执行成功即返回成功。只要the majority of servers are operational and can communicate with each other and with clients，这个分布式系统就是稳定的。 Raft只有两类rpc，选举与append log，并约定一定的规则。见如下两图：注意约定的规则，在图中也有说明。 以下是选主rpc 以下是append log rpc 以下是各节点选主状态转换图 初始时，大家都是follower。leader通过定期heartbeat告诉follower自己是主。如果heartbeat间隔大于elect timeout，follower认为没有leader，就会发起选主。 任期term随时间递增，发起elect，会生成新的term，发给rpc给其他所有server，变成candidate. 万一同时有多个candidate多个term怎么办？重试 + […]
