ZooKeeper中,新的leader可以将某个path指定为ready znode。 其他节点将仅在该znode存在时使用配置。
当leader 重建配置之后,会通知其他副本重建配置,并新建ready znode.
副本为了防止出现不一致,必须在重建配置时,处理完其之前的所有事务。保证所有服务的状态一致。
任何一个副本更新失败,都不能够应用都需要进行重试。
Zookeeper用例:锁
acquire lock:
retry:
r = create("app/lock", "", empheral)
if r:
return
else:
getData("app/lock", watch=True)
watch_event:
goto retry
release lock:
delete("app/lock")
由于上面的伪代码可能会出现羊群效应,可以尝试下面的方式
znode下方的children中,序号最低的的是持有锁的
其他在等待的client只watch前一个znode的变化,避免了羊群效应
acquire lock:
n = create("app/lock/request-", "", empheral|sequential)
retry:
requests = getChildren(l, false)
if n is lowest znode in requests:
return
p = "request-%d" % n - 1
if exists(p, watch = True)
goto retry
watch_event:
goto retry
Zookeeper简化程序构建但其不是最终的解决方案
Zookeeper实现细节
挑战:处理重复的客户端请求
场景:primary收到客户端请求后,返回失败,客户端进行重试
在lab3中,我们使用了map来解决重复的请求问题,但是每一个客户端是堵塞的,只能够等待完成才能进行下一个
在Zookeeper中,在一段时间内的操作是幂等的,以最后一次操作为准
挑战: 读取操作的效率
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功能用于多样的应用场景,并且内在提供主从容错机制,在包括雅虎在内的多家公司广泛应用