《ZooKeeper官方指南》一致性保障

本文翻译自《ZooKeeper官方指南》，译者：追云，校对：追云

一致性保障

ZooKeeper是一个高性能，可扩展的服务。虽然读比写更快，但在设计上，它的读操作和写操作都很快。之所以会出现读比写更快，是因为在某些“读”的情况下，ZooKeeper 可以使用比较旧的数据，这得益于ZooKeeper的一致性保障：

连续一致性

来自客户端的更新请求会按照它们发送的顺序被应用。

原子性

更新要么成功，要么失败——不会出现部分成功的（更新操作）结果

单系统图像

一个客户端将会看到和它连接的服务器相同的服务视图。

可靠性

一旦一个更新被应用了，它（更新）将会从此一直存在，直到一个客户端再次更新。从这个保障可以得出两个推论：

1.如果一个客户端获得一个成功的返回码，更新将会一直被应用。在一些失败的情况下（比如连接错误，超时等）客户端将不会知道更新被应用了与否。我们对使失败（错误）降到最低采取了行动，但这个保障仅仅当返回码是正确的时侯才会出现。（这是一种在Paxos算法中被称为单调性的情况）。

2、任何通过读请求或成功更新的已被客户端看到的更新，当它处于从服务器错误中恢复的状态时（操作）将不能被回滚。

及时性

系统的客户端视图被强制性定为在一个合适的时间范围内（在命令的数十秒内）是最新的。系统的改变在这个范围内既不会被客户端看见，客户端也不会知道服务的运行中断。

使用这些一致性保障来建造一些更高级的功能，如leader选举、障碍、队列以及在ZooKeeper客户端（附件不被ZooKeeper需要）进行唯一的可撤销的锁的读/写是简单的。更多详情请见”Recipes and Solutions”。

Note

有时开发者会误以为有那么一些ZooKeeper实际上并不会保证做到的保障存在,它们是：同一时间一致的跨客户端视图

ZooKeeper并不保证在某一时刻，两个不同的客户端会接受到完全一致的ZooKeeper视图的数据。这是由一些因素导致的，如网络延迟，或客户端可能会在另一个客户端获取到改变通知之前执行一个更新。考虑一下存在两个客户端的情况，如客户端A和客户端B。如果客户端A将一个znode /a的值从0设为1，然后告诉客户端B去读/a,那么客户端B可能会因为它连接到的服务器的不同而读取到那个旧的值0.如果客户端A和B读取到相同的值是重要的，那么客户端B应该在它执行读操作之前就从ZooKeeper的API方法里调用sync（）方法。

所以，ZooKeeper它本身并不保证改变是在所有服务器间同步发生的，但ZooKeeper基元(注：primitives)可以被用来建造那些提供有效客户端同步的更高级的功能。（更多详情请见“ZooKeeper Recipes”.[tbd:..]）

原创文章，转载请注明： 转载自并发编程网 – ifeve.com本文链接地址: 《ZooKeeper官方指南》一致性保障