• Zookeeper VS Chubby


    目录

    区别的根源

    一个设计良好的系统应该是围绕并为其设计目标服务的。

    • Chubby:provide coarse-grained locking as well as reliable storage for a loosely-coupled distributed system.

    • Zookeeper:provide a simple and high performance kernel for building more complex coordination primitives at the client.

    关键词

    chubby:lock service

    zookeeper: coordination

    Chubby旗帜鲜明的表示自己是为分布式锁服务的,而Zookeeper则倾向于构造一个“Kernel”,而利用这个“Kernel”客户端可以自己实现众多更复杂的分布式协调机制。自然的,Chubby倾向于提供更精准明确的操作来免除使用者的负担,Zookeeper则需要提供更通用,更原子的原材料,留更多的空白和自由给Client。也正是因此,为了更适配到更广的场景范围Zookeeper对性能的提出了更高的要求。

    1)一致性

    chubby:线性一致性

    chubby的一致性是分布式系统中所能实现的最高的一致性,即每次操作时都可以看到其之前的所有操作按顺序完成

    ZooKeeper:写操作线性(Linearizable writes) + 客户端有序(FIFO client order)

    写操作线性:所有修改集群状态的操作按顺序完成

    客户端有序:对任意一个client来说,它所有的读写操作按顺序完成

    从实现上来看。

     

    读请求

    写请求

    chubby

    由Master单独处理(or Client Cache)

    仅Master处理写请求

    zookeeper

    Leader提供读服务,Follower和Observer也能提供读服务

    仅Leader处理写请求

    区别

    对于读请求的处理逻辑是不同的!

    chubby的所有读写请求都交给Master串行执行,并且利用一致性协议复制到集群中所有节点

    ZooKeeper仅将写操作交给Leader串行执行,这保证了写操作线性。

    对于读操作,则由与客户端连接的server自行处理。

    如何保证客户端有序?

    Zookeeper给每一个写入后的状态一个唯一自增的zxid,并通过写操作的答复告知客户端,客户端之后的读操作都会携带这个zxid,

    直连的server通过比较zxid判断自己是否滞后,如果是,则让读操作等待。

    从以上对比可以看出,Zookeeper损失的是不同客户端的读写操作的一致性。如下图所示:

     

    集群初始状态为x,Client A发起写操作将状态修改为y,写操作由于写操作线性保证转发给Leader通过一致性协议复制到整个集群,过半数节点成功后返回;

    此时,Client B从还未同步到的server上读到的值仍未x。

    这种一致性的损失,换来的是集群读请求的高性能。

    不像Chubby的单点服务的结构,zookeeper采用多个server同时处理客户端的请求,异步读同步写,通过primary节点来同步数据的update,这一点大大改善了读服务的性能,当然弱化了客户端与服务器之间的一致性。

    对于不能容忍这种不一致的场景,Zookeeper提供了两种机制满足:

    • Watcher通知跟Read操作一样是由客户端所连接Server本地处理的,所以Client B收到对应的事件通知后再Read就一定能看到最新的状态y;

    • 由于客户端有序的保证,Client B可以在Read操作前加一条Write操作,来保证看到最新状态,为了避免这个不必要的Write操作Zookeeper提供Sync命令,相当于一条空的写操作。

    总结:

    Chubby保证了数据的强一致性。

    Zookeeper通过牺牲一定的一致性来换取更高的读性能。

    2)Client Cache vs No Cache

    Chubby:客户端维护了cache,并且客户端cache是强一致的。

    (关于维护客户端cache带来的写性能的影响,在chubby的应用场景中,为读多写少,写操作其实很少)

    ZooKeeper:根本没有实现cache功能,用户如果需要必须自己实现,利用watcher机制,用户能方便地按照自己需求实现一致或不一致的cache语义。

    总结

    chubby提供分布式锁服务,对一致性有更高的要求,为强一致。

    zookeeper提供分布式协调服务,为了适配更广的场景,对性能有更高的要求,牺牲了一定的一致性。

    参考资料

    【1】http://xudifsd.org/blog/2016/06/chubby-zookeeper-different-consistency-level/

    【2】https://www.cnblogs.com/linhaohong/archive/2012/11/26/2789394.html

    【3】https://bzdww.com/article/146310/ Zookeeper vs Chubby

    【4】http://www.evanlin.com/til-2016-07-25/

    【5】https://www.cnblogs.com/lulu/p/4199056.html

  • 相关阅读:
    C# 协变 逆变
    go slice 理解
    为什么避免使用Task.Wait或者Task.Result
    IL笔记
    docker随笔
    领域事件
    总结笔记
    基于ASP.NET Core 3.x的端点路由(Endpoint Routing)实现控制器(Controller)和操作(Action)分离的接口服务
    CentOS7 多IP搭建SOCKS5代理服务器
    Springboot 实现数据库备份还原
  • 原文地址:https://www.cnblogs.com/yeyang/p/11420920.html
Copyright © 2020-2023  润新知