我正在学习Zookeeper，到目前为止，我不明白将其用于数据库无法解决的分布式系统的目的。
我读过的用例是通过让Zookeeper客户端读/写到Zookeeper服务器，为分布式系统实现锁，屏障等。通过读/写数据库不能实现相同的目标吗？
例如，我的书描述了使用 Zookeeper 实现锁的方法是让想要获取锁的 Zookeeper 客户端创建一个在 .然后，该锁由其子 znode 具有最低序列号的客户端拥有。ephemeral znodelock-znode
书中所有其他 Zookeeper 示例再次只是使用它来存储/检索值。
似乎Zookeeper与数据库/任何存储的唯一区别是“观察者”概念。但这可以用其他东西来构建。
我知道我对Zookeeper的简化观点是一种误解。那么有人能告诉我Zookeeper真正提供了数据库/自定义观察者无法提供的吗？
通过读/写数据库不能实现相同的目标吗？
从理论上讲，是的，这是可能的，但通常，将数据库用于分布式协调的苛刻用例并不是一个好主意。我见过微服务使用关系数据库来管理分布式锁，后果非常糟糕（例如，数据库中有数千个死锁），这反过来又导致DBA与开发人员的关系很差：-）
Zookeeper 具有一些关键特征，使其成为管理应用程序元数据的良好候选者
上述所有功能都可以通过数据库实现，但只有应用程序客户端付出了大量努力。此外，监视和临时节点也可以通过使用触发器，超时等技术由数据库实现。但它们通常被认为是低效的或反模式的。
关系数据库提供强大的事务保证，这些保证通常需要付费，但通常不是管理应用程序元数据所必需的。因此，寻找更专业的解决方案（如Zookeeper或Chubby）是有意义的。
此外，Zookeeper将其所有数据存储在内存中（这限制了其用例），从而实现了高性能的读取。大多数数据库通常不是这种情况。
当你试图弄清楚Zookeeper的目的时，我认为你问自己一个错误的问题，而不是问Zookeeper可以做什么，“数据库”不能做（顺便说一句，Zookeeper也是一个数据库），问Zookeeper比其他可用的数据库更擅长什么。如果你开始问自己这个问题，你会希望理解为什么人们决定在他们的分布式服务中使用Zookeeper。
以临时节点为例，使用它们的巨大好处并不是它们比其他方式更好地锁定。使用临时节点的好处是，如果客户端失去与 Zookeeper 的连接，它们将自动被删除。
然后我们可以看看CAP定理，其中Zookeeper最接近CP系统。您必须再次确定这是否是您想要从数据库中获得的。
tldr：与其他数据库相比，Zookeeper在某些方面更好，而在其他方面则更差。
