使用Zookeeper而不仅仅是数据库来管理分布式系统的目的是什么？

Question

我正在学习Zookeeper，到目前为止，我还没有理解将它用于数据库无法解决的分布式系统的目的。

我读过的用例是通过让Zookeeper客户端读/写Zookeeper服务器来实现分布式系统的锁，屏障等。 读取/写入数据库 不能实现相同的目标吗？

例如，我的书中描述了使用Zookeeper实现锁定的方法是让想要获取锁定的Zookeeper客户端创建ephemeral znode，并在lock-znode下设置顺序标志。然后锁定由其子znode具有最低序列号的客户端拥有。

本书中的所有其他Zookeeper示例再次仅使用它来存储/检索值。

似乎唯一让Zookeeper与数据库/任何存储区别开来的是“观察者”概念。但这可以使用其他东西构建。

我知道我对Zookeeper的简化看法是一种误解。那么有人能告诉我Zookeeper真正提供的数据库/自定义观察者不能做什么吗？

Answer 1

我认为当你试图找出Zookeeper的目的时，你会问自己一个错误的问题，而不是询问Zookeeper可以做什么，“数据库”不能做（btw Zookeeper也是一个数据库）问什么Zookeeper是比其他可用的数据库更好。如果你开始问自己这个问题，你将有希望了解为什么人们决定在他们的分布式服务中使用Zookeeper。

以短暂的节点为例，使用它们的巨大好处并不是它们比其他方式更好地锁定它们。使用短暂节点的好处是，如果客户端失去与Zookeeper的连接，它们将自动被删除。

然后我们可以看看CAP定理，其中Zookeeper最接近CP系统。并且您必须再次确定这是否是您想要的数据库。

tldr：与其他数据库相比，Zookeeper在某些方面更好，在其他方面更差。

Answer 2

  

通过读/写数据库不能实现同样的目标吗？

理论上，是的，这是可能的，但通常情况下，将数据库用于要求分布式协调的用例并不是一个好主意。我已经看到微服务使用关系数据库来管理分布式锁，结果非常糟糕（例如数据库中有数千个死锁），这反过来又导致DBA与开发人员关系不佳： - ）

Zookeeper具有一些关键特性，使其成为管理应用程序元数据的良好候选者

• 通过向 ensemble
添加新节点来水平扩展的可能性
• 保证数据在特定时间范围内最终保持一致。如果客户需要，可以以更高的成本实现严格的一致性（Zookeeper是CAP中的CP系统）
• 订购保证 - 保证所有客户能够按照订单的顺序读取数据

以上所有内容都可以通过数据库来实现，但只有应用程序客户才能付出巨大努力。此外， watch 和短暂节点可以通过使用诸如触发器，超时等技术来实现。但是它们通常被认为是低效或反模式。

关系数据库提供强大的事务保证，通常需要付出代价，但通常不需要管理应用程序元数据。因此，寻找更专业的解决方案是有意义的，例如Zookeeper或Chubby。

此外，Zookeeper将其所有数据存储在内存中（限制其使用情况），从而实现高性能读取。大多数数据库通常不是这种情况。