paxos
分布式一致性算法，也分两个阶段，遵循少数服从多数的原则，并不需要所有参与者都同意某一协议 <br>
cap理论
C 一致性：数据在分布式环境下的多个副本之间能否保持一致性，这里的一致性更多是指强一致性； <br>
A 可用性：分布式系统一直处于可用状态，对于请求总是能在有限的时间内返回结果致性； <br>
P 分区容错性：除非整个网络故障，分布式系统在任何网络或者单点故障时，仍能对外提供满足一致性和可用性的服务； <br>
一个分布式系统不可能同时满足一致性、可用性和分区容错性这三个基本需求，最多只能同时满足其中的两项
zab
借鉴paxos思路，是zookeeper解决分布式一致性所使用的算法 <br>
2pc
阶段1提交事务请求
事务询问
协调者向各个参与者询问是否可以执行事务操作，等待参与者的响应
执行事务
各参与者进行事务操作,并且undo和redo写入到日志中去
各参与者反馈给协调者
参与者如果成功执行事务操作就反馈yes,没有成功执行事务操作就反馈No
阶段2执行事务提交
发送事务提交请求
协调者向所有事务发送commit请求
事务提交
参与者在接受到协调者的commit请求后开始提交事务，并且成功后释放相应的资源
反馈事务提交结果
参与者在完成事务之后发送Ack消息给协调者
完成事务
协调者接受到所有的Ack请求后，完成事务
事务异常的情况
任何一个参与者反馈No反应后,或者在等待超时之后,协调者无法收到所有参与者的反馈的话就会中断事务
1.发送回滚请求
协调者像参与者发送Rollback请求
2.事务回滚
参与者接受到回滚请求后，会将第一阶段的undo信息执行回滚操作,完成后释放资源
3.反馈事务回滚结果
参与者执行完回滚操作后，发送Ack给协调者
4.中断事务
协调者接受到Ack请求后完成事务中断
BASE理论
即使无法做到强一致性，但分布式系统可以根据自己的业务特点，采用适当的方式来使系统达到最终的一致性；
Basically Avaliable 基本可用：当分布式系统出现不可预见的故障时，允许损失部分可用性，保障系统的“基本可用”；体现在“时间上的损失”和“功能上的损失”；e.g：部分用户双十一高峰期淘宝页面卡顿或降级处理； <br>
Soft state 软状态：允许系统中的数据存在中间状态，既系统的不同节点的数据副本之间的数据同步过程存在延时，并认为这种延时不会影响系统可用性；e.g：12306网站卖火车票，请求会进入排队队列； <br>
Eventually consistent 最终一致性：所有的数据在经过一段时间的数据同步后，最终能够达到一个一致的状态；e.g：理财产品首页充值总金额短时不一致； <br>
