Paxos
三个角色
- proposer，发送两个请求给acceptor，prepare，propose
- acceptor，接受一个propose请求
- learner
prepare
每个proposer发出一个perpare给acceptor，发出为一个根据时间戳和server id生成的id。
如果acceptor没有accpet任何propose，则对这次的prepare给出两个承诺：
- 不会再接受 <= id 的prepare请求
- 不会再接受 < id 的propose请求（没有等于，因为之后的propose可以接受此id
如果acceptor已经接受了一个propose，此时将会直接返回接受的值，proposer会拿到这个值用于替换掉自己的值。
propose
发起正式的请求，带上自己需要执行的指令（用于learner执行）。 accpetor根据prepare定下的承诺accpet。如果一个多数派都accept了同一个id，那它就被成功选举。否则需要重新prepare。
形成活锁
Raft (multi paxos)
paxos决议需要两次来回，prepare和propose，甚至极端情况形成活锁。因此实际几乎都是用multi paxos。
Raft三个角色：
- follower：初始所有都是这个状态，leader崩了转为candidate
- candidate：此中选举出一个leader，如果选出了leader，所有candidate又将变回follower
- leader：只能存在一个
心跳：leader会不断给follower发出心跳，保证自己的统治地位。
日志同步，同步时都是以日志的方式同步到集群，因为要保证所有的input值相等，不能存在机器时钟等随机值，保证一致性。所有的指令都会由leader转成日志同步给其它follower。相同的初识状态 + 相同的输入 = 相同的结束状态
如果脑裂，出现多个leader，小的区间将不可用，脑裂消失后新的leader保持，旧的leader转为follower。大分区必须大于n/2才能正常执行。因此通常部署奇数台服务器节约资源，如5台最多可以挂2台，而6台最多也只能挂2台。
ZAB算法心跳由follower发给leader，其它和raft相似
Gossip 流行病协议，弱一致性，最终一致性
Gossip协议是基于六度分隔理论，一个人可以通过6个人认识世界上的所有人。
节点任意传播给其它节点，最终传播给所有节点。因为定义自由，因此有几百种实现方式。
缺点： 消息冗余，拜占庭问题（一个节点传错了就出事了），消息延迟
