最近我一直在阅读Paxos论文、FLP定理等，并评估Apache Zookeeper用于一个项目。我也一直在阅读在线上关于Google的分布式锁服务Chubby的各种文献。我使用Zookeeper的基本用例是为了实现分布式系统的复制和通用协调。
但是我想知道的是，Zookeeper或类似Chubby的分布式锁系统到底有什么具体优势。基本上我想知道为什么我不能只使用MySQL NDB Cluster。我不断听到MySQL存在很多复制问题。我希望有更多经验的人能为此提供一些解释。
先感谢您的回答。
以下是我的需求清单：
这取决于您管理的数据类型以及所追求的规模和容错性。
我可以从ZooKeeper的角度回答。在开始之前，我应该提到ZooKeeper不是Chubby的克隆。具体来说，它不直接执行锁定操作。它也被设计用于考虑不同的顺序和性能要求。
在ZooKeeper中，整个系统状态的副本都存储在内存中。使用原子广播协议复制更改，并由大多数ZooKeeper服务器同步到磁盘（使用更改日志）后进行处理。由于这个原因，只要大多数服务器运行，ZooKeeper就具有确定性能力，可以容忍故障。即使出现大停机，例如停电，只要大多数服务器重新上线，系统状态就会得到保留。存储在ZooKeeper中的信息通常被认为是系统的真相，因此这些一致性和耐久性保证非常重要。
ZooKeeper提供的其他功能与监控动态协调状态有关。临时节点使您能够轻松检测故障和组成员资格。排序保证允许您进行领导者选举和客户端锁定。最后，监视器允许您监视系统状态并快速响应系统状态的更改。
因此，如果您需要管理和响应动态配置，检测故障，选举领导者等。那么ZooKeeper就是您要寻找的。如果您需要存储大量数据或需要该数据的关系模型，则MySQL是更好的选择。
MySQL与Innodb提供了一个良好的通用解决方案，使用不太昂贵的硬件可能很容易满足您的性能要求。在配置为双四核处理器和良好磁盘的服务器上，它可以轻松处理每秒数千次的更新操作。内置的异步复制功能可以满足可用性需求，但是如果主服务器出现问题，您可能会丢失几秒钟的数据。当主服务器恢复正常时，这些丢失的数据可能部分可恢复，或者可以从应用程序日志中恢复。能否容忍此类数据丢失取决于系统的工作方式。更少有数据丢失但速度较慢的备选方案是，在主/故障转移单元之间共享MySQL Innodb的磁盘。在此情况下，故障转移单元将接管磁盘，而无需丢失数据，前提是主服务器没有发生某种形式的磁盘灾难。如果没有共享磁盘，则可以使用DRBD来模拟该过程，通过同步复制写入的磁盘块到故障转移单元：这可能会影响性能。
使用Innodb和上述其中一种复制解决方案，可以将数据复制到故障转移单元，这是恢复问题的重要一步，但需要额外的工作来重新配置系统以使故障转移单元上线。通常使用类似于RHCS或Pacemaker或Heartbeat（在Linux上）或MS集群工具来执行此操作。这些系统是工具包，您需要亲手动手将它们构建成适合您环境的解决方案。但是，在所有这些系统中，当系统注意到主服务器已经出现问题并重新配置系统以使用故障转移单元时，短暂的停机期是不可避免的。这可能需要几十秒钟时间：试图减少此时间可能会使您的故障检测系统过于敏感，导致系统被错误地转移。
向上扩展，MySQL NDB 旨在缩短恢复时间，并在一定程度上帮助扩展数据库以提高性能。但是，MySQL NDB 的适用范围相对较窄。该系统将关系型数据库映射到分布式哈希表上，因此对于涉及多个表之间的复杂查询，MySQL 组件和存储组件（NDB 节点）之间存在大量流量，导致复杂查询运行缓慢。然而，适合的查询确实非常快速。我曾多次研究这个产品，但我的现有数据库过于复杂，无法很好地适配，需要进行大量重新设计才能获得良好的性能。但是，如果您正在设计新系统阶段，只要记住 NDB 的限制，它将非常有效。此外，您可能需要相当多的机器来提供良好的 NDB 解决方案：几个 MySQL 节点加上3个或更多的 NDB 节点——尽管如果您的性能需求不太极端，MySQL 和 NDB 节点可以共存。