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