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 一致性保障