Zookeeper VS Chubby

区别的根源

1）一致性

2）Client Cache vs No Cache

总结

参考资料

区别的根源

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

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单独处理（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通过牺牲一定的一致性来换取更高的读性能。