Zookeeper用例：ready znode与配置改变

ZooKeeper中，新的leader可以将某个path指定为ready znode。 其他节点将仅在该znode存在时使用配置。

当leader 重建配置之后，会通知其他副本重建配置，并新建ready znode.

副本为了防止出现不一致，必须在重建配置时，处理完其之前的所有事务。保证所有服务的状态一致。

任何一个副本更新失败，都不能够应用都需要进行重试。

Zookeeper用例：锁

下面的伪代码向我们锁的实现。通过create试图持有锁，如果锁已经被其他的client持有，则通过watch方式监控锁的释放。

acquirelock:
retry:
r=create("app/lock","",empheral)
ifr:
return
else:
getData("app/lock",watch=True)

watch_event:
gotoretry

releaselock:
delete("app/lock")

由于上面的伪代码可能会出现羊群效应，可以尝试下面的方式

znode下方的children中，序号最低的的是持有锁的

其他在等待的client只watch前一个znode的变化，避免了羊群效应

acquirelock:
n=create("app/lock/request-","",empheral|sequential)
retry:
requests=getChildren(l,false)
ifnislowestznodeinrequests:
return
p="request-%d"%n-1
ifexists(p,watch=True)
gotoretry

watch_event:
gotoretry
Zookeeper简化程序构建但其不是最终的解决方案

应用程序还有许多需要解决的问题

例如如果我们要在GFS中使用Zookeeper，那么我们还需要

chunks的副本方案

primary失败的协议

…

但是使用了Zookeeper，至少可以使master容错，不会发生网络分区脑裂的问题

Zookeeper实现细节

和lab3相似，具有两层

ZooKeeper 服务层 (K/V 层)

ZAB 层 (Raft 层)

Start() 在底层执行插入操作

随后，ops从每个副本服务器的底层弹出，这些操作按照弹出的顺序提交(commited),在lab3中使用apply channel，在ZAB层中，通过调用abdeliver()

挑战：处理重复的客户端请求

场景：primary收到客户端请求后，返回失败，客户端进行重试

在lab3中，我们使用了map来解决重复的请求问题，但是每一个客户端是堵塞的，只能够等待完成才能进行下一个

在Zookeeper中，在一段时间内的操作是幂等的，以最后一次操作为准

挑战： 读取操作的效率

大部分的操作都是读取操作，他们不修改状态

读取操作是否必须通过ZAB层？

任何副本服务器都可以执行读取操作？

如果读取操作通过Raft/ZAB层，则性能会降低

读取操作如果不通过Raft/ZAB层、可能会返回过时的数据

Zookeeper解决方案：允许返回过时的数据

读取可以由任何副本执行

读取吞吐量随着服务器数量的增加而增加

读取返回它看到的最后一个zxid

只有sync-read() 保证数据不过时

read操作会返回zxid,zxid包含了部分客户端对于此read请求相对应的write请求的顺序，从而客户端能够了解此server操作是否落后于client。

心跳检测以及建立session时都会返回zxid，当客户端连接服务器时，通过zxid对比保证client与server的状态足够接近

总结

Zookeeper通过将wait-free对象（znode对象）暴露给客户端解决分布式系统中的进程协调问题

Zookeeper保证了write操作的线性一致性以及客户端操作的FIFO顺序

Zookeeper通过允许读取操作返回过时数据实现了每秒数十万次操作的吞吐量值，适用于多读而少些的场景

Zookeeper仍然提供了保证读一致性的sync操作

Zookeeper具有强大的API功能用于多样的应用场景，并且内在提供主从容错机制，在包括雅虎在内的多家公司广泛应用