java - ZooKeeper 食谱和 Apache Curator

Question

我正在尝试确切地了解 Apache ZooKeeper(“ZK”)解决了哪些类型的问题，也许还有他们的 Recipes page是最好的起点。

首先，我做出以下假设:

• ZooKeeper API(在 Java 和 C 中均可用)公开了 these 7 simple methods然后允许您建立自己的使用模式，称为“ZK 食谱”
• 然后由您使用这些 ZK Recipes 自己解决分布式编程中的问题
• 或者，您可以只使用 Apache Curator 附带的那些，而不是构建您自己的 ZK 食谱。
• 因此，无论哪种方式，您都在使用 ZK Recipes(还是自行开发或由 Curator 提供)来解决分布式计算问题

我相信Apache Kafka就是一个例子，Kafka 使用 ZK 创建一个 distributed Queue (这是列出的 ZK 食谱之一)。因此，如果我的假设是正确的，ZK 会公开这些 API 方法，Apache Kafka 的创建者要么直接使用 ZK，要么使用 Curator 来实现“Queue”ZK Recipe。

如果我上面的任何假设是错误的，请首先纠正我!假设我或多或少走上正轨:

查看 ZK 食谱列表，我看到以下内容(非详尽无遗):

• 障碍
• 锁
• 领导人选举

为了让我欣赏这些食谱和它们提供的解决方案，我首先需要欣赏它们解决的问题!我从基本的 Java 并发中了解锁是什么，但我只是没有看到何时需要“分布式锁”的用例。对于领导选举，我能想到的 - 作为一个首先需要它的用例 - 如果你正在构建一个你想要与内置主/从一起发布的应用程序或主要/次要能力。也许在那种情况下你会使用 ZK 来实现你自己的“领导人选举”配方，或者可能只使用 Curator 的 Leader Latch盒子外面。至于屏障，我看不出它们与锁有什么不同。所以我问:

• 我的主/从或主要/次要问题是否是 ZK 领导者选举配方的准确用例？
• 什么是分布式锁的例子？它解决了什么问题？
• Barriers 同样如此:Locks 和 Barriers 之间有什么区别？

Answer 1

1. 是的。您的 Zk 领导者选举配方示例是正确的。一般来说，如果食谱已经存在，为什么要重写它？

引用 Zookeeper 文档:

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services.

1. 关于分布式锁 - 假设您有一个分布式系统，其中所有配置都保存在 Zookeeper 上，并且不止一个实体负责更新特定配置 - 在这种情况下，您希望配置更新是同步。

2. 关于屏障，我个人从未使用过它们 - 但是有了锁，您需要获取锁才能在节点上实际执行某些操作，屏障是您等待它空闲但不一定需要设置屏障一旦它是免费的。