这是我的要求。
我在一个集群中有一堆机器（比如大约 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，但是订单处理不适合 map reduce 模型，所以我正在寻找利用其他框架（如 ZooKeeper）的方法，它可以帮助 A、B、C 和 D 之间的协调。
ZooKeeper 适合这里吗？
Zookeeper 是协调问题的自然选择。
以下食谱可用于您的用例。
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。
您可以使用 zookeeper 来存储元数据。
Zookeeper 非常适合集群同步（例如主节点选择）。另一个可以帮助您的相关（Zookeeper 的子项目）是bookkeeper
请注意，hadoop 不使用 zookeeper（版本 0.23 使用但尚未发布） - HBase 即使在当前和以前的版本中也使用它