https://www.youtube.com/watch?v=BhosKsE8up8
state machine replication 的 共识(consensus) 算法
根据CAP理论，一个分布式系统，无法同时满足以下三点
1.一致性(Consistency)
2.可用性(Availablility)
3.分区容错性(Partition Tolerance)
在知乎上看到的对CAP的通俗易懂的解释
一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。
当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。
提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。
然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要保证一致，每次写操作就都要等待全部节点写成功，而这等待又会带来可用性的问题。
总的来说就是，数据存在的节点越多，分区容忍性越高，但要复制更新的数据就越多，一致性就越难保证。为了保证一致性，更新所有节点数据所需要的时间就越长，可用性就会降低。作者：知乎用户
链接：https://www.zhihu.com/question/54105974/answer/139037688
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
Zookeeper采用的算法叫ZAB，而ZAB是由PAXOS算法衍生而来。PAXOS除了衍生出ZAB之外，还衍生出了Raft算法(etcd就采用了Raft)。ZAB和Raft都是状态机复制的共识问题的解决方案，也是工业中强一致性问题的解决方案。严格的说PAXOS及其衍生算法解决的问题是状态机复制的共识问题，而这一问题并不完全等同于实现了强一致性，因为在某些情况下，系统的最终一致性，不仅需要达成共识，还取决于Client的行为
状态机复制，是分布式系统为了容错（fault tolerance），想出来的解决方案
Basic Paxos 除了Client 之外,还有proposer,acceptor,leaner 三种角色。
Basic Paxos算法存在的问题：
1.就是容易出现活锁，假设有两个Proposer不停的提提案，不停地打断对方，就会出现这个情况。当然这不是一个大问题，就是在被打断的情况下，做一个随机长度的time out就可以了
2.效率低，需要两轮RPC，第一轮先提案，此轮需要acceptor达到quorum阀值，此轮acceptor并不关心内容。第二轮RPC时，proposer才做写请求，要求acceptor写数据
=======================
“网络断了怎么保证数据一致性”、“怎么保证异地事务一致性”、“业务怎么无缝的在多个地点切换”