《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官方指南》一致性保障

FavoriteLoading添加本文到我的收藏
  • Trackback 关闭
  • 评论 (7)
    • langgui
    • 2016/07/30 3:45下午

    这翻译…

      • 追云
      • 2016/07/30 7:31下午

      额,哪里不对请直说。。。我也才是第二次翻译,翻译不好是肯定的

        • wer446
        • 2016/08/04 10:15上午

        更新既不会成功也不会失败——不存在部分结果。这句话是要表达什么呢

          • 追云
          • 2016/08/11 9:23上午

          照我个人理解,意思是应该是:更新中途如果出现了故障(错误),会自动回滚操作,不会存在部分更新(剩下部分因为故障而没完成更新)的情况

      • 夜映雪
      • 2016/08/09 12:12下午

      Updates either succeed or fail — there are no partial results.

      更新要么成功,要么失败——不会出现部分成功的(更新操作)结果

      感觉这样翻译会好点

    • spark
    • 2016/08/05 12:07下午

    丈二和尚摸不着头脑

您必须 登陆 后才能发表评论

return top