问题描述
我正在学习 Zookeeper，到目前为止我不明白将其用于数据库无法解决的分布式系统的目的.
I’m learning Zookeeper and so far I don't understand the purpose of using it for distributed systems that databases can't solve.
我读过的用例是通过让 Zookeeper 客户端读/写 Zookeeper 服务器来为分布式系统实现锁、屏障等.不能通过读/写数据库来实现吗?
The use cases I’ve read are implementing a lock, barrier, etc for distributed systems by having Zookeeper clients read/write to Zookeeper servers. Can’t the same be achieved by read/write to databases?
例如，我的书描述了使用 Zookeeper 实现锁的方法是让想要获取锁的 Zookeeper 客户端创建一个 ephemeral znode，并在 lock 下设置一个顺序标志-znode.那么锁就归子znode序列号最小的那个客户端所有.
For example my book describes the way to implement a lock with Zookeeper is to have Zookeeper clients who want to acquire the lock create an ephemeral znode with a sequential flag set under the lock-znode. Then the lock is owned by the client whose child znode has the lowest sequence number.
本书中所有其他 Zookeeper 示例再次仅使用它来存储/检索值.
All other Zookeeper examples in the book are again just using it to store/retrieve values.
Zookeeper 与数据库/任何存储的唯一区别似乎是观察者"概念.但这可以使用其他东西来构建.
It seems the only thing that differs Zookeeper from a database/any storage is the "watcher" concept. But that can be built using something else.
我知道我对 Zookeeper 的简化看法是一种误解.那么有人能告诉我 Zookeeper 真正提供了什么数据库/自定义观察者不能提供的吗?
I know my simplified view of Zookeeper is a misunderstanding. So can someone tell me what Zookeeper truly provides that a database/custom watcher can’t?
推荐答案
理论上，是的，这是可能的，但通常，将数据库用于要求苛刻的分布式协调用例并不是一个好主意.我已经看到微服务使用关系数据库来管理分布式锁，结果非常糟糕(例如，数据库中有数千个死锁)，这反过来导致 DBA 与开发人员之间的关系不佳 :-)
In theory, yes it is possible, but usually, it is not a good idea to use databases for demanding usecases of distributed coordination. I have seen microservices using relational databases for managing distributed locks with very bad consequences (e.g. thousands of deadlocks in the databases) which in turn resulted in poor DBA-developer relation :-)
Zookeeper 具有一些关键特性，使其成为管理应用程序元数据
Zookeeper has some key characteristics which make it a good candidate for managing application metadata
- 可以通过向 ensemble 中添加新节点来水平扩展
- 数据保证在特定时间范围内最终保持一致.如果客户需要，可以以更高的成本实现严格的一致性(Zookeeper 是 CAP 术语中的 CP 系统)
- 顺序保证——保证所有客户端都能够按照写入的顺序读取数据
- Possibility to scale horizontally by adding new nodes to ensemble
- Data is guaranteed to be eventually consistent within a certain timebound. It is possible to have strict consistency at a higher cost if clients desire it (Zookeeper is a CP system in CAP terms)
- Ordering guarantee -- all clients are guaranteed to be able to read data in the order in which they have been written
以上所有内容都可以通过数据库实现，但需要应用程序客户端的大量努力.此外，监视和临时节点可以通过数据库使用触发器、超时等技术来实现.但它们通常被认为是低效或反模式的.
All of the above could be achieved by databases, but only with significant effort from application clients. Also watches and ephemeral nodes could be achieved by databases by using techniques such as triggers, timeouts etc. But they are often considered inefficient or antipatterns.
关系数据库提供强大的事务保证，这通常是有代价的，但通常不需要管理应用程序元数据.因此，寻找更专业的解决方案(例如 Zookeeper 或 Chubby)是有意义的.
Relational databases offer strong transactional guarantees which usually come at a cost but are often not required for managing application metadata. So it make sense to look for a more specialized solution such as Zookeeper or Chubby.
此外，Zookeeper 将其所有数据存储在内存中(这限制了其用例)，从而实现了高性能读取.大多数数据库通常不是这种情况.
Also, Zookeeper stores all its data in memory (which limits its usecases), resulting in highly performant reads. This is usually not the case with most databases.
这篇关于使用 Zookeeper 而不仅仅是数据库来管理分布式系统的目的是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！