这是我的要求。
我在群集中有一堆机器（比如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的职责。关于正在运行的作业的元数据也会定期备份到备份节点E.所以当B / C / D成为新的主人，它将从E读取元数据。
我知道这听起来有点像hadoop，但订单处理无法适应map reduce模型，所以我正在寻找利用ZooKeeper等其他框架的方法，它可以帮助A，B，C和D之间的协调。
ZooKeeper适合吗？
答案 0 :(得分：11)
Zookeeper是协调问题的自然选择。
以下配方可用于您的用例。
A的工作是轮询数据库以获取更新（因此，A可以在订单表中查找新订单）。 一旦A接收到更新，它就会验证B，C，D中哪一个相对空闲（负载均衡是我猜的正确的单词）。然后它命令B，C，D中的一个开始处理订单。 A保留在B / C / D上处理订单的跟踪。
Distributed Queue可用于任务调度。
B，C，D就像奴隶一样 - 他们只接收来自A的更新并在完成订单处理时通知A.如果A发生故障（由于网络问题或其他原因），B，C，D中的一个将成为主人并执行A的职责。
看起来像leader election问题
有关正在运行的作业的元数据也会定期备份到备份节点E。
您可以使用zookeeper存储元数据。
答案 1 :(得分：3)
Zookeeper非常适合群集同步（例如主选择）。可以帮助您的另一个相关的（Zookeeper子项目）是bookkeeper
请注意，hadoop不使用zookeeper（版本0.23但它尚未发布） - HBase甚至在当前版本和以前的版本中也使用它