Paxos

CAP

CAP理论是分布式设计的基础，一句话就是一致性，高可用和分区容忍性（网络分区）三者取其二

为了提高容灾，系统会部署在不同地方的机房，比如上海北京，如果上海机房网络故障，那么北京机房如果能够正常提供服务，那就必须实时将上海机房和北京机房数据进行同步保证数据是一致的，如果数据量很大，那么在同步数据的过程中，系统就没法正常响应请求，也就无法保证高可用

Paxos

这里不考虑消息的篡改，存储都是可靠的，没有数据丢失和错误，否则是拜占庭将军问题

classic paxos

一个实例（确定一个值）写入需要2轮rpc

multi paxos

一个实例（确定一个值）写入需1轮rpc(做了合并rpc)

fast paxos

没有冲突需要1轮rpc ， 有冲突需要2轮

主要看基础的paoxs，他是根本

一组节点分成3种角色,可以身兼数职：

提议者: 提出提议

接受者: 采纳

学习者: 广播被采纳的提议(超过半数同意的提议)

两个阶段

phase1: 谁编号高，谁能提交proposal => 能不能提交

phase2: 编号最高者提交proposal，没有更高的节点提出更高的proposal，则接受提案，否则重来 => 提交什么才能成功

两个阶段都要过半接受者同意才能成功

注意几个原则：

    越早达成统一越好,不是杠精
    提议者，叫号,有生成算法，要比提议者所知道的id都要大(mn+ir)，如果在你之前没有人提议，那么你可以按你的提议来，如果之前已经有人被采纳了，你就需要将自己的提议修改成已经被接受过的，获得过半的acceptor同意才能进入第二阶段，否则重新拿号再来
    接受者，prepare阶段，只接受号大的，但是如果此时已经接受过提议，会返回给提议者，让提议者修改，接收阶段有一个提议获取过半acceptor同意，结束

为了保证一致性，其实就是使用锁进行同步，这是我们很容易理解的

第一阶段加锁，或者说是抢锁，只有号大的能抢到，要求超过半数同意，也是保证只有一个能够拿到锁

第二阶段某个提议者获取得锁,进行修改释放锁，要尽快获取acceptor接受，大号仍然在抢占锁, 如果达不到半数accept，重新取号抢锁，因此存在活锁现象，增加随机等待即可

维基百科解释也可以，建议多看几遍