ZooKeeper与CAP

CAP理论：一个分布式系统不可能满足一致性（consistency）、可用性（Availability）、分区容错性（Partition tolerance）这三个基本需求。

1、一致性可分为：（参考ZooKeeper和CAP理论及一致性原则）

　    ①强一致性（strong consistency）。任何时刻，任何用户都能读取到最近一次成功更新的数据。
　　②单调一致性（monotonic consistency）。任何时刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值。也就是说，可　　获取的数据顺序必是单调递增的。
　　③会话一致性（session consistency）。任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在本次会话中就不会再读到比这值更旧的值　　 会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障。示例case：php的　　session概念。
　　④ 最终一致性（eventual consistency）。用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致的状态，只是所需时间不能保障。
　　⑥弱一致性（weak consistency）。用户无法在确定时间内读到最新更新的值。

（1）、2PC（二阶段提交）：准备阶段和提交阶段。

第一阶段：提交事务请求阶段
      a.协调者节点向所有参与者节点询问是否可以执行提交操作，并开始等待各参与者节点的响应。 
      b.各参与者节点执行事务操作，并将Undo信息和Redo信息写入事务日志中。 
      c.各参与者向协调者反馈事务询问的相应。如果参与者成功执行了事务操作，则反馈协调者YES响应，表示事务可以执行；如果参与者事务操作执行失败，则返回协调者NO响应。

第二阶段：执行事务提交

      如果各参与者反馈的都是YES响应，则就会执行事务提交。     

      a.发送提交请求。协调者向所有参与者发出Commit请求。

      b.事务提交。参与者接受到Commit请求后，会正式执行事务提交操作，在完成提交后，释放资源。

      c.完成事务。协调者接收到所有参与者反馈的ACK消息后，完成事务。

中断事务：假如有反馈者向协调者反馈了No响应，或等待超时，则会中断事务。

      a.发送回滚请求。

      b.事务回滚。参与者接收到Rollback请求后，会用第一阶段记录的undo信息来执行事务回滚操作

      c.反馈事务回滚结果。回滚后向协调者发送ACK消息。

      d.协调者收到反馈的ACK消息后，完成事务中断。

 

2PC存在的问题：同步阻塞（各参与者无法进行其他任务操作）、单点问题（协调者出现问题，整个系统无法运转）、数据不一直（协调者发送部分commit请求，挂了，其他参与者没收到）、太过保守（任意节点的失败都会导致整个事务的失败）

（2）、3PC（三阶段提交）：准备阶段，预提交阶段和do提交阶段。

       与2PC相比，3PC在准备阶段接收到是否可以执行执行事务的询问后，各参与者并没有立即执行事务，而是进入预提交事务阶段，等待协调者发送第三阶段的doCommit请求，当接收到协调者doCommit请求后，正式提交事务，并向协调者反馈ACK。

在进入阶段三时，如果协调者出现问题，或协调者与参与者之间出现网络故障，参与者在等待超时之后，会进行事务提交。

       3PC存在的问题：假如协调者出现问题，参与者默认提交事务，仍然会有数据不一致问题。

（3）Paxos算法

        参考这里吧。

（4）ZooKeeper中的数据一致性（参考 ZooKeeper和CAP理论及一致性原则 ）

    ZooKeeper从以下几点保证了数据的一致性

     单调一致性：来自任意特定客户端的更新都会按其发送顺序被提交保持一致。也就是说，如果一个客户端将Znode z的值更新为a，在之后的操作中，它又将z的值更新为b，则没有客户端能够在看到z的值是b之后再看到值a（如果没有其他对z的更新）。

     原子性：每个更新要么成功，要么失败。这意味着如果一个更新失败，则不会有客户端会看到这个更新的结果。

     单一系统映像：一个客户端无论连接到哪一台服务器，它看到的都是同样的系统视图。这意味着，如果一个客户端在同一个会话中连接到一台新的服务器，它所看到的系统状态不会比 在之前服务器上所看到的更老。当一台服务器出现故障，导致它的一个客户端需要尝试连接集合体中其他的服务器时，所有滞后于故障服务器的服务器都不会接受该 连接请求，除非这些服务器赶上故障服务器。

     持久性：一个更新一旦成功，其结果就会持久存在并且不会被撤销。这表明更新不会受到服务器故障的影响。

     实时性：在特定的一段时间内，客户端看到的系统需要被保证是实时的（在十几秒的时间里）。在此时间段内，任何系统的改变将被客户端看到，或者被客户端侦测到。

 

2、可用性（参考 ZooKeeper和CAP理论及一致性原则 ）

      指系统提供的服务必须一直处于可用的状态，对于用户的每个操作请求总是能够在有限的时间内返回结果。

      ZooKeeper中保证了CP。对可用性并没有保证。如下：

     不能保证每次服务请求的可用性。任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性；但是它不能保证每次服务请求的可用性（注：也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果）。所以说，ZooKeeper不能保证服务可用性。

      进行leader选举时集群都是不可用。在使用ZooKeeper获取服务列表时，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。所以说，ZooKeeper不能保证服务可用性。

3、分区容错性

      分布式系统在遇到任务网络分区故障的时候，仍然能够保证对外提供满足一致性和可用性的服务。除非整个网络环境都发生了故障。

      ZooKeeper保证了分区容错性，集群中单个服务器发生故障时，只要集群中超过半数的机器还能够正常工作，整个集群就能够对外提供服务。

 

 

参考：

ZooKeeper和CAP理论及一致性原则

ZooKeeper和CAP理论及一致性原则