Zookeeper 适合这种场景吗?

发布于 2024-12-21 18:29:18 字数 475 浏览 1 评论 0原文

这是我的要求。

我在一个集群中有一堆机器(比如说 4 - A、B、C、D)。

A 的工作是轮询数据库以获取更新(因此,A 可能会在订单表中查找新订单)。
一旦 A 收到更新,它就会验证 B、C、D 中哪一个相对空闲(我猜负载平衡是正确的词)。然后它命令 B、C、D 之一开始处理订单。 A 跟踪 B/C/D 上正在处理哪个订单。

B、C、D 就像从属设备 - 它们仅接收来自 A 的更新,并在完成订单处理后通知 A。如果 A 宕机(由于网络问题或其他原因),B、C、D 中的一个将成为主节点并执行 A 的职责。A 关于正在运行的作业的元数据也会定期备份到备份节点 E。 B/C/D 成为新的 master,它会从 E 读取元数据。

我知道这听起来有点像 hadoop,但是订单处理无法适应 MapReduce 模型,所以我正在寻找利用 ZooKeeper 等其他框架的方法这可以帮助协调A、B、C 和 D.

ZooKeeper 适合这里吗?

Here's my requirement.

I have got a bunch of machines in a cluster ( say about 4 - A,B,C,D).

A's job is to poll a database for updates (so, A could be looking for new orders in order table).
Once, A receives an update, it verifies which one of B,C,D is relatively free (load balances is the right word I guess). It then orders one of B,C,D to start processing the order. A keep tracks of which order is being processed on B/C/D.

B,C,D are like slaves - they only receive updates from A and notify A, when they are done with order processing. If A goes down (due to network issue or something), One of B,C,D would become a master and perform duties of A. A's metadata about what jobs are running is also periodically backed up to a backup node E. So when B/C/D becomes the new master, it would read metadata from E.

I know it sounds a bit like hadoop, but the order processing cannot fit into a map reduce model, so I am looking for ways to leveraging other frameworks like ZooKeeper which can help with the coordination between A,B,C and D.

Is ZooKeeper a fit here?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

海风掠过北极光 2024-12-28 18:29:18

Zookeeper 是解决协调问题的自然选择。

以下食谱可用于您的用例。

A 的工作是轮询数据库以获取更新(因此,A 可以在订单表中查找新订单)。
一旦 A 收到更新,它就会验证 B、C、D 中哪一个相对空闲(我猜负载平衡是正确的词)。然后它命令 B、C、D 之一开始处理订单。 A 跟踪 B/C/D 上正在处理哪个订单。

分布式队列可用于任务调度。

B、C、D 就像从属设备 - 它们仅接收来自 A 的更新,并在完成订单处理后通知 A。如果A出现故障(由于网络问题或其他原因),B、C、D中的一个将成为Master并履行A的职责。

看起来像 领导者选举问题

A 的有关正在运行的作业的元数据也会定期备份到备份节点 E。

您可以使用 Zookeeper 来存储元数据。

Zookeeper is a natural choice for coordination problems.

Following recipes can be used for your use cases.

A's job is to poll a database for updates (so, A could be looking for new orders in order table).
Once, A receives an update, it verifies which one of B,C,D is relatively free (load balances is the right word I guess). It then orders one of B,C,D to start processing the order. A keep tracks of which order is being processed on B/C/D.

Distributed Queue can be used for task scheduling.

B,C,D are like slaves - they only receive updates from A and notify A, when they are done with order processing. If A goes down (due to network issue or something), One of B,C,D would become a master and perform duties of A.

Looks like a leader election problem

A's metadata about what jobs are running is also periodically backed up to a backup node E.

You can use zookeeper for storing metadata.

她说她爱他 2024-12-28 18:29:18

Zookeeper 非常适合集群同步(例如主选择)。另一个可以帮助您的相关(Zookeeper 子项目)是 bookkeeper

请注意,hadoop 不使用 Zookeeper(0.23 版本使用了,但尚未发布) - HBase 即使在当前和以前的版本中也使用它

Zookeeper is a good fit for cluster synchronization (e.g. master selection). Another related (sub-project of Zookeeper) that can help you is bookkeeper

Note that hadoop doesn't use zookeeper (version 0.23 does but it isn't released yet) - HBase does use it even in current and previous versions

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文