Apache Zookeeper 设置的模棱两可的文档答案

【问题标题】：Ambiguous documentation for Apache Zookeeper setupApache Zookeeper 设置的模棱两可的文档
【发布时间】：2015-07-22 18:00:38
【问题描述】：

在此链接Official Zookeeper doc，我发现引用含糊不清。

ZooKeeper 将其数据存储在数据目录中，并将其事务日志存储在事务日志目录中。默认情况下，这两个目录是相同的。服务器可以（并且应该）配置为将事务日志文件存储在与数据文件不同的目录中。当事务日志驻留在专用日志设备上时，吞吐量会增加，延迟会减少。

它说事务日志文件应该将事务日志存储在单独的目录中。然后它说专用设备是最佳的？为什么默认将数据目录文件和事务日志文件存储在同一位置？我相信我很困惑，因为我可能不明白他们所说的“目录”是什么意思。当我听到目录时，我会想到文件夹。当他们说目录时，他们是指硬件存储设备吗？如果这些文件存储在同一设备上但在不同的文件夹中，我不希望吞吐量增加和延迟减少。如果文件存储在不同的设备上，我预计吞吐量会增加，延迟会减少。

我是否正确解释了他们的文档？仅将事务日志和数据文件存储在单独的文件夹中不会提高性能。它们只是意味着如果将它们存储在不同的硬件存储设备上，就会获得这些收益对吗？

【问题讨论】：

标签： logging apache-zookeeper apache-curator

【解决方案1】：

你是对的。要点是将事务日志放在专用设备上，因为 ZooKeeper 需要 fsync 到该磁盘。这部分的任何延迟都可能导致严重的问题。

从 ZK 配置的角度来看，单独的目录只是实现这一点的先决条件。

【讨论】：

您能否进一步详细说明 fsync 发生时会发生什么？我找到了 fsync 的这个解释，linux.die.net/man/2/fsync，但我很好奇这个问题会是什么样子。我会崩溃吗？只是有时表现不佳？我只是不知道会发生什么。
Fsync 是一项非常昂贵的操作 - 确保将数据刷新到磁盘。如果其他东西正在使用同一个磁盘，fsync 可能需要很长时间。由于 ZooKeeper 实例需要确保在确认写入之前将事务写入磁盘，这使得 fsync 成为 ZK 写入的关键路径的一部分。有一个选项可以禁用此功能（forceSync=false），在这种情况下 zk 不会等待 fsync。但是，这可能会破坏 ZK 提供的一些核心保证。
通过破坏保证，这是否意味着持久性和恢复状态的能力？在我的应用程序中，我更担心性能和崩溃是可以容忍的，因为没有“丢失数据”，我们只是在重新启动时重新计算结果。听起来我应该在我的情况下禁用 forceSync 。这对我来说是一个天真的假设吗？是否还有其他与禁用 forceSync 相关的问题？
在您确定这是一个问题之前，我不会禁用 fsync。在 AWS 等虚拟化环境中或 ZK 与大量磁盘用户共享机器时，这可能是一个问题。修复它的方法不是禁用 fsync，而是给 zk 一个专用磁盘。禁用 fsync 意味着您可能会丢失已确认的写入，这可能会导致暂时或零星的故障/错误，难以跟踪和调试。我会尝试搜索有关此类问题的故事。