<pre name="code" class="html">第一种.没一个节点的数据都相同.即master->多slave模式. 例如zookeeper
Zookeeper 是一种高性能、可扩展的服务。 Zookeeper 的读写速度非常快，并且读的速度要比写的速度更快。另外，在进行读操作的时候， ZooKeeper 依然能够为旧的数据提供服务。这些都是由于 ZooKeepe 所提供的一致性保证，它具有如下特点：
【Zookeeper提供的一致性是弱一致性,首先数据的复制有如下规则:zookeeper确保对znode树的每一个修改都会被复制到集合体中超过半数的机器上。那么就有可能有节点的数据不是最新的而被客户端访问到。并且会有一个时间点,在集群中是不一致的.
也就是Zookeeper只保证最终一致性, 但是实时的一致性可以由客户端调用自己来保证,通过调用sync()方法.
】
顺序一致性
客户端的更新顺序与它们被发送的顺序相一致。
原子性
更新操作要么成功要么失败，没有第三种结果。
单系统镜像
无论客户端连接到哪一个服务器，客户端将看到相同的 ZooKeeper 视图。
【如果数据不一致,怎么能够保证看到相同的视图? 插入/删除/修改都会对数据结构有影响】
可靠性
一旦一个更新操作被应用，那么在客户端再次更新它之前，它的值将不会改变。。这个保证将会产生下面两种结果：
1 ．如果客户端成功地获得了正确的返回代码，那么说明更新已经成果。如果不能够获得返回代码（由于通信错误、超时等等），那么客户端将不知道更新操作是否生效。
2 ．当从故障恢复的时候，任何客户端能够看到的执行成功的更新操作将不会被回滚。
实时性
在特定的一段时间内，客户端看到的系统需要被保证是实时的（在十几秒的时间里）。在此时间段内，任何系统的改变将被客户端看到，或者被客户端侦测到。
【伪实时性,太让人误解了,直白点说就是数据可以在十几秒Sync到各个节点,保证最终一致性. 我第一时间看到这个实时性的时候,我就好奇,Oracle RAC花了老鼻子劲才保证了实时性和一致性,Zookeeper是如何轻松做到的,原来是个假的,还说的那么让人误会. 】
给予这些一致性保证， ZooKeeper 更高级功能的设计与实现将会变得非常容易，例如： leader 选举、队列以及可撤销锁等机制的实现。
【
用分布式系统的CAP原则来分析Zookeeper.
1)C: Zookeeper保证了最终一致性,在十几秒可以Sync到各个节点.
2)A: Zookeeper保证了可用性,数据总是可用的,没有锁.并且有一大半的节点所拥有的数据是最新的,实时的. 如果想保证取得是数据一定是最新的,需要手工调用Sync()
3)P: 有2点需要分析的.
节点多了会导致写数据延时非常大,因为需要多个节点同步.
节点多了Leader选举非常耗时, 就会放大网络的问题. 可以通过引入observer节点缓解这个问题.
】
第二种.每一个节点的数据都不太一样.即metadata_server->data_server 例如elasticsearch
Zookeeper 是一种高性能、可扩展的服务。 Zookeeper 的读写速度非常快，并且读的速度要比写的速度更快。另外，在进行读操作的时候， ZooKeeper 依然能够为旧的数据提供服务。这些都是由于 ZooKeepe 所提供的一致性保证，它具有如下特点：
【Zookeeper提供的一致性是弱一致性,首先数据的复制有如下规则:zookeeper确保对znode树的每一个修改都会被复制到集合体中超过半数的机器上。那么就有可能有节点的数据不是最新的而被客户端访问到。并且会有一个时间点,在集群中是不一致的.
也就是Zookeeper只保证最终一致性, 但是实时的一致性可以由客户端调用自己来保证,通过调用sync()方法.
】
顺序一致性
客户端的更新顺序与它们被发送的顺序相一致。
原子性
更新操作要么成功要么失败，没有第三种结果。
单系统镜像
无论客户端连接到哪一个服务器，客户端将看到相同的 ZooKeeper 视图。
【如果数据不一致,怎么能够保证看到相同的视图? 插入/删除/修改都会对数据结构有影响】
可靠性
一旦一个更新操作被应用，那么在客户端再次更新它之前，它的值将不会改变。。这个保证将会产生下面两种结果：
1 ．如果客户端成功地获得了正确的返回代码，那么说明更新已经成果。如果不能够获得返回代码（由于通信错误、超时等等），那么客户端将不知道更新操作是否生效。
2 ．当从故障恢复的时候，任何客户端能够看到的执行成功的更新操作将不会被回滚。
实时性
在特定的一段时间内，客户端看到的系统需要被保证是实时的（在十几秒的时间里）。在此时间段内，任何系统的改变将被客户端看到，或者被客户端侦测到。
【伪实时性,太让人误解了,直白点说就是数据可以在十几秒Sync到各个节点,保证最终一致性. 我第一时间看到这个实时性的时候,我就好奇,Oracle RAC花了老鼻子劲才保证了实时性和一致性,Zookeeper是如何轻松做到的,原来是个假的,还说的那么让人误会. 】
给予这些一致性保证， ZooKeeper 更高级功能的设计与实现将会变得非常容易，例如： leader 选举、队列以及可撤销锁等机制的实现。
【
用分布式系统的CAP原则来分析Zookeeper.
1)C: Zookeeper保证了最终一致性,在十几秒可以Sync到各个节点.
2)A: Zookeeper保证了可用性,数据总是可用的,没有锁.并且有一大半的节点所拥有的数据是最新的,实时的. 如果想保证取得是数据一定是最新的,需要手工调用Sync()
3)P: 有2点需要分析的.
节点多了会导致写数据延时非常大,因为需要多个节点同步.
节点多了Leader选举非常耗时, 就会放大网络的问题. 可以通过引入observer节点缓解这个问题.
】