读/写数据库不能达到同样的效果吗？
理论上，是的，这是可能的，但是通常，使用数据库来处理分布式协调的苛刻用例不是一个好主意。我见过微服务使用关系数据库来管理分布式锁，结果非常糟糕（例如，数据库中有数千个死锁），这反过来又导致了糟糕的DBA-开发人员关系：-）
Zookeeper具有一些关键特性，这些特性使其成为管理应用程序元数据的理想选择

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

以上所有这些都可以通过数据库来实现，但需要应用程序客户端的大量努力。此外，* 监视 * 和 * 短暂节点 * 也可以通过使用触发器、超时等技术由数据库来实现，但它们通常被认为是低效的或反模式的。
关系数据库提供了强大的事务保证，这通常是有代价的，但通常不是管理应用程序元数据所必需的，因此寻找更专业的解决方案（如Zookeeper或Chubby）是有意义的。
此外，Zookeeper将所有数据存储在内存中（这限制了它的使用），从而产生高性能的读取。

我认为当你试图弄清楚Zookeeper的用途时，你问了自己一个错误的问题，而不是问Zookeeper能做什么“数据库”不能做的（顺便说一句，Zookeeper也是一个数据库），而是问Zookeeper比其他可用的数据库更擅长什么。如果你开始问自己这个问题，你将有希望理解为什么人们决定在他们的分布式服务中使用Zookeeper。
以临时节点为例，使用临时节点的巨大好处并不在于它们比其他方式提供了更好的锁定效果，而在于如果客户端失去了与Zookeeper的连接，临时节点会自动被删除。
然后我们可以看一下CAP定理，Zookeeper最接近于CP系统，你必须再一次决定这是否是你想从你的数据库中得到的。
tldr：与其他数据库相比，Zookeeper在某些方面更好，在其他方面更差。

派对太晚了。我再提一个想法：
是的，在生产环境中使用SQL数据库进行服务器协调是很常见的。但是，您可能会被要求构建HA（高可用性）系统，对吗？因此您的SQL DB必须是HA。这意味着您将需要领导者-跟随者架构（一个跟随者SQL DB），如果领导者死亡，跟随者将需要提升为领导者（MHA节点+管理器），当先前的领导者复活时，它必须知道它不再是领导者。这些问题有答案，但将花费工程师的努力来设置它们。因此，Zookeeper被发明。
我有时认为Zookeeper是HA SQL集群的简化版本，具有一个功能子集。
类似地，为什么人们选择使用NoSQL VS SQL。有了适当的分区，SQL也可以很好地扩展，对吗？那么为什么选择NoSQL呢？一个动机是减少处理节点故障时的工作量。当NoSQL节点死亡时，它可以自动回退到另一个节点，甚至触发数据迁移。但如果您的SQL分区领导者之一死亡，它通常需要手动处理。2这就像SQL VS Zookeeper。3有人为你编写了HA +故障转移逻辑，所以我们可以轻松应对不可避免的节点故障。

ZooKeeper写操作是线性化的。线性化意味着所有操作都是完全有序的。总有序意味着对于每个操作a和b，要么a发生在b之前，要么b发生在a之前。
线性化是最强的一致性级别。大多数数据库给予线性化，因为它会影响性能，并提供较弱的一致性保证-例如偶然性（偶然顺序）。
ZooKeeper使用此来实现原子广播算法，该算法相当于共识。