转 http://ifeve.com/zookeeper-consistency-guarantees/
本文翻译自《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:..]） |