对paxos算法的理解

相关名词解释

CAP定理：

C:Consistency，一致性，指数据在多个副本之间，能够保持一致性（强一致性，一旦更新，用户不会再读到旧的数据），（最终一致性，更新以后，一段时间内，用户还是会读到旧的数据，但是最终一定会更新到新数据）
A:Available，可用性，系统提供的服务必须一直处于可用状态，在有限的时间内给用户返回结果
P:Partition Tolerance，分区容错性,分布式系统在遇到任何网络分区故障的时候，仍然需要能保证对外提供满足一致性和可用性的服务，除非整个网络环境都故障了，（网络分区指不同的节点分布在不同的子网络（机房或者异地网络等），由于一些特殊原因导致这些子网络之间出现网络不联通，但是各个子网络内部是正常的。换句话说就是，任何一个地方的机房挂了，不应该影响整体网络的运行，可以被转发到其他机房,或者异地机房，继续保证服务的一致性和可用性
CAP定理是指，一个分布式系统，不可能同时满足上述3个条件，最多只能兼顾两个。
分区容错性是基本要求，所以一般都在一致性和可用性之间做出平衡

BASE定理

BASE是 Basically Available(基本可用), Soft state(软状态)，和Eventually consistent（最终一致性）三个短语的缩写，BASE是对CAP中一致性和可用性权衡的结果
基本可用，在分布式系统出现不可预知的故障时，允许损伤部分可用性，来保持基本可用，比如允许响应时间上的损失，或者功能上的损失（由于流量过大，通过限流，把部分用户引导到一个降级页面）
弱状态，又叫软状态，和硬状态相对，指允许系统中的数据存在中间状态，就是说，允许不同节点之间的数据同步存在延时，只要该状态不影响系统整体可用性。
最终一致性，所有副本中的数据，经过一段时间以后，最终能达到一致的状态

脑裂

脑裂，就是指当主机a短暂性掉线，而其他主机以为a断开了，于是选择了主机b作为新的master，这个时候主机a又正常了，于是区域内就出现了双主机，大脑分裂。

分桶策略

是指将类似的会话放在同一区块中进行管理，以便于zookeeper对会话进行不同区块的隔离处理以及同一区块的统一处理。
说白了就是心跳检测的时候，会计算一下下一次检测的时间点（下次超时时间点），然后把这个session的位置放到对应时间段的容器分类中，然后这样系统就不用轮询所有session来做心跳检测，只需要查询对应的“桶”
默认的检测时间是2000毫秒
超时时间=当前时间加sessionTimeOut（自己设置的超时时间）
而zookeeper做了优化
实际的超时时间= 超时时间+2秒

Paxos

what
paxos是一种提高分布式系统 容错性的 一致性算法。
特点
关键字
角色：
proposer：服务器之一，选举人，提出提案，邀请其他人参与投票
acceptor：除proposer外的服务器，选民们，拥有投票权，一旦半数以上的选民投票给了同一个选举人的提案，这个提案就会生效
learner：除proposer外的服务器，选民们，还没来得及投票就已经因为达到半数而失去投票权，或者投给其他的提案，而在真正的提案生效的时候，只需要在事后被通知提案的选举结果就行了

名词解释
epoch：英文单词意思：时期，表示每个leader服务器都会用高32位（左边）的数字来表示自己的时期，在上一个时期的基础上进行递增。
SID 服务器ID
ZXID ：事务ID，全局单调递增的唯一ID，ZDIX是一个64位数字，其中低32位是一个简单的单调递增的计数器，针对客户端的每一个事务请求，leader服务器会在尝试一个新的事务proposal的时候，对该计数器进行加1操作。而高32位则代表了leader周期epoch的编号，每当选举产生一个新的leader服务器，就会从这个服务器上取出其本地日志中最大事务proposal的ZXID,并从该ZXID中解析出对应的epoch值，并且对其进行加1操作
关于master选举的时候，优先比较ZXID，选大的，相同的情况下，比较SID(myId)，选大的。投票信息（myId,ZXID）

其他关键信息：
必须有过半的机器同意提案，才能生效
选拥有最新ZXID的那个人做master，可以保证他拥有的提案是最多的（也是最新的）
只能有一个master被选定
不能再批准任何收到的，比当前批准过的提案编号小的提案
初始化的时候，选myid最大的做master

how
1,首先我们有服务器abcde,一共5服务器分别对应id 12345
2,程序启动后，每个服务器都尝试选举自己为master，给其他人发送自己的编号（myId），具体如下：
a:id1发送1给bcde，b收到以后，检查自身，发现自身拥有一个myId2,于是拒绝了a的请求，并且告诉a，我有2，我比你大，返回给a自己存的值，由于b没收过旧的数据，所以返回的是（myId2，ZXID 0），于是a收到消息后记录，并竞选失败。
e:id5发送5给abcd，a收到过b的返回值，已知目前有个（myId2，ZXID 0）的值，拿两个值比较后，发现(e:id5，ZXID 0)更大，于是把（myId2，ZXID 0）返回给e，并且告诉e，a同意选举e为master，bcd收到类似信息后，也返回了同样的结果
e已知集群内有5台机子，于是当e收到a和任意一台机器返回的同意结果时，就认为自己竞选成功，并开始走下一步骤，比如宣布服务器选举master完毕，可以开始处理提案

处理提案的过程：
1，e收到客户端的事务请求，对ZXID进行加1操作，然后把prepare命令以及最新的ZXID一起发送给abcd（中的一个半数以上子集，不需要给全部都发）
2，abcd收到prepare命令，检查比对自身拥有的ZXID，如果新ZXID大于当前已知的自身存有的ZXID，就响应prepare请求，否则就丢弃提案。
3，e收到任意两个服务器返回的响应后，再次发送accept命令给所有服务器，包括ZXID，以及事务的内容（value）
4，任意两台机器收到accept后，有两种情况，他们之前没有收到过prepare请求 或者 他们之前收到过prepare请求，所以这时候，只要确定自身拥有的ZXID不大于收到的ZXID，就能对这个accept进行响应（处理）。
5，e收到两台或以上机器响应以后，把ZXID和处理后的数据写入到日志中
处理提案完毕

故障模式
1，这时候e出现了故障，掉线了，假设目前e持有的ZXID为01..05 表示第一个epoch，共处理了5个事务
2，这时候abcd都在差不多时间发现和e的心跳检测连接不上，于是认定e已经掉线，需要开始新一轮的选举
3，abcd再次分别发起选举，假设这时候a和d的ZXID为01..05，而b和c的为01..04
4，当a发送(Myid,ZXID)请求给bcd的时候，b，c对比自身的ZXID发现，a的更大，于是认同了a的选举；d对比自身的ZXID，发现是一样的，又对比myId,发现自己的myId比a大，于是拒绝了a，并且把自己的myId，ZXID告诉a.
5，由于这个时候集群内只有4台机子，于是必须要半数以上，也就是三台机子都同意，才能选举成功
6，d在同时也发起了选举请求给abc，b和c虽然已经同意过a，但是在比对的时候，发现d的ZXID相同，而myId更大，于是又认可了d，而a也做出了同样的选择，于是d当选为新的master服务器
7，d在当选之后，通知给集群内的所有人，我当选了。