zookeeper是一个高性能,可扩大的服务.zookeeper的读操作
和写操作的设计指标就是速度快,不过zookeeper的读比写快,在读的场景下,zookeeper能够将读的压力扩散到不同的follow服务节点上,而且须要读取的数据大部分是曾经被更新好了的'旧'的数据,而写操作须要在各个节点间保障一致性同步.保证数据的一致性同步是zookeeper的外围性能,他提供如下保障:
- 程序一致性: 从客户端发送过去的命令是依照工夫先后顺序有序执行的(注:更新操作是leader节点执行的,读取申请leader/follow都能够执行)
- 原子性: 更新操作的后果要么胜利要么失败,没有局部胜利或者局部失败的状况,不会产生局部后果
- 繁多的统一零碎映像:客户端读取到数据都是统一的,也就是讲对于一个zookeeper集群来讲,同一时间节点上客户端在任何一个节点读取的数据都是统一的,即便有些非凡状况下zookeeper产生了故障转移,客户端也不会读取到脏的数据
可靠性: 一旦更新被利用了,那么数据就会被长久化了不会被失落或者篡改除非客户端前面被动的批改这个值,这个保障有2个推论:
- 如果客户端失去了一个操作的success code,那么这个更新操作就被利用了.一个服务端谬误产生了()那么客户端是不晓得的操作是胜利还是失败了,咱们采取的步骤是尽量减少失败,但只有返回胜利代码的操作才有保障(这在Paxos中称为枯燥条件)
- 任何被客户端看到的数据,也就是以后看到的最新的数据或者被胜利更新后的最新的数据,即便服务器因为故障而从新复原后也不会被回滚为旧或者脏数据(失落,篡改,脏数据,旧数据)
- 及时性:保证系统的客户端视图在肯定的工夫范畴内(以数十秒为数量级)是最新的.在此范畴内,客户机要么看到零碎更改要么检测到服务中断
应用这些一致性保障很容易在ZooKeeper客户端上建设更高级别的性能,比方leader选举、阻碍、队列和读/写可撤销锁(不须要增加ZooKeeper),更多状况请看:Recipes and Solutions
留神
一些开发者会谬误的认为除了下面讲到的一致性保障外,还有例外的一种保障zookeeper不能反对,这保障就是工夫上齐全同时的一致性跨客户端视图:zookeeper无奈确保集群中的任意一个节点都会齐全同时的执行一个同一个操作,因为网络通信是有提早的,一个客户端更新操作是在例外一个客户端接到数据更新告诉的后面产生的,思考上面的场景,有A,B共2个客户端,如果A更新了/a节点的数据由0到1,而后通知B客户端去读取/a,客户端B可能会读到/a的旧数据,取决于B是从那个节点读取/a(读取leader是最新的,然而读取follow可能是旧的).如果客户端A和客户端B读取雷同的值很重要,客户端B应该在执行读取操作之前调用zookeeper API办法中的sync()办法.所以，zookeeper自身并不能保障在所有服务器上同步发生变化，然而zookeeper原语能够用来构建更高级别的函数，提供有用的客户端同步.
参考:
- Consistency Guarantees
- 《ZooKeeper官网指南》一致性保障
本文原创链接: zookeeper 一致性保障