A Slide for Zookeeper Learning | zookeeper学习中的PPT分享

Albert Wang / 2022-07-07 / 200 Words/has been Read Times

这是一篇用来测试共享文件的博客，分享了一篇关于 zookeeper 分布式组件学习的PPT。

zookeeper 可以用来解决哪些问题？

test_and_set 机制：当一台服务器挂掉之后，其他服务器能接手它的工作
config_info：通过它来管理的信息
master elect：选主

zookeeper 采用复制系统来做系统容灾。因为同样是一主多备，随着服务器数量的增加，主将会成为系统瓶颈，并不能保证系统对外提供的性能也随着服务器数量的增加而增加。

zookeeper 为了保证性能，它允许 client 端从任意一台服务器上读取数据。虽然会让读的性能大幅度提升，但是同样也带来了一些新的问题。比如刚好 client 去读的那台服务器并不属于“大多数'' 服务器中的一台，这就可能会导致读到旧的数据。

zookeeper 怎么保证线形一致性？

对于写的请求，client 对提供 seq_id 到服务端，服务端会线形去执行这些请求。

对于读的请求，它并不能提供线形一致性，但它能保证后读的请求一定不会比先读的请求读到更老的数据。具体做法而言，在持久化 log 的时候，所有的服务器都会同时持久化 zxid，在读的时候服务器端会把 zxid 返回给 client。client 每次请求都会把 zxid 带下来，不管新的读请求发给了哪个 zk，这台服务器都能根据 zxid 提供更新的 log 信息。

zookeeper 提供的配置管理服务。

Zookeeper 采用非锁的方式对外提供锁服务，因为 zookeeper 提供了写的线形一致性。当需要修改配置的时候，客户端需要先删读 ready 文件，然后去修改配置，修改完成之后再创建 ready 文件，整个过程中只有写操作，没有读操作。

delete("ready")
write f1
write f2
create("ready")

假如需要读取配置，首先 worker 需要取检查配置文件是否存在，如果文件存在，就会读取 f1 和 f2 这两个配置。因为如果 ready 文件存在，那说明更新配置操作一定完成了。

exists("ready")
read f1
read f2

读取可能操作可能会遇到下面这种场景，假如读先获取到了 ready 文件，然后写去更新配置，就可能会导致配置获取不一致。

create("ready")
exists("ready")   读
read f1           读
delete("ready")
write f1
write f2
read f2           读
create("ready")

zookeeper 避免这个问题的手段，就是在获取 ready 文件的时候同时会创建一个 watch 任务，如果配置文件被修改，它可以确保会通知到所有的 client

exists("ready" ， watch=true)

在PPT制作过程中参考了尚硅谷的教学材料【尚硅谷】大数据技术之Zookeeper 3.5.7版本教程_哔哩哔哩_bilibili 和 Raft 以及 zookeeper 的论文原文。