zookeeper 一致性保障

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