zookeeper 一致性保障

Posted 2021-10-05 thinktik

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