Zookeeper zookeeper.forceSync、Zab 和 Paxos
Zookeeper zookeeper.forceSync, Zab and Paxos
我注意到 zookeeper.forceSync 的默认配置是 "no"。
这意味着 FileChannel.Force() 不会在预写日志上调用。
我的印象是 zookeeper 使用的 Zab 共识算法能够正常工作。在响应领导者之前，所有条目都必须保存到磁盘。
否则在领导人选举期间，一些数据可能会丢失。
默认为"no"安全吗？
不，运行 和 forceSync=no 不安全。
正如在 zookeeper 用户列表中所讨论的 in 2014:
There's a big warning in the documentation that says that's a possibility.
If you don't force both Java and the OS to flush their IO buffers to disk,
then you have no guarantees that your data is consistent.
看看 2020 年的 zookeeper admin docs 它只会说：
forceSync
(Java system property: zookeeper.forceSync)
Requires updates to be synced to media of the transaction log before
finishing processing the update. If this option is set to no,
ZooKeeper will not require updates to be synced to the media.
您必须查看该部分标题和该部分的第一段才能意识到危险：
Unsafe Options
The following options can be useful, but be careful when you use them.
The risk of each is explained along with the explanation of what the
variable does.
对我来说，这不是 "big warning in the documentation"，而是说将该部分中的所有设置描述为 "unsafe"。没有关于使用该选项的风险的信息。例如，我希望可靠的文档能够提及下面讨论的相关故障的风险。您可能会考虑提出一张罚单，认为该不安全选项的文档没有应有的清晰和有用。
2014年的讨论似乎表明当时默认启用了forceSync。他们谈论 forceSync=no 中的一个错误，人们没有看到预期的性能改进。这表明默认设置是安全的，您必须通过设置 forceSync=no 来 "opt-out of safety" 以提高性能。如果现在默认为 forceSync=no，我建议您提交错误。
论坛上的讨论继续表明对于单个节点故障应该没有问题。出现这种情况是因为在数据至少位于两个节点上之前，在 ZAB 下的集合中不会有写入确认。如果数据没有被刷新并且没有被复制到多个节点上，那么你会在单个节点崩溃时丢失数据。
当数据没有刷新到磁盘时，最大的问题是当你有一个相关的节点故障时。如果磁盘未在至少一个节点上刷新，则向客户端确认的写入可能会丢失。 Zookeeper 通常用于低容量 meta-data，例如领导者选举结果。 Zookeeper 的全部卖点在于它应该可以安全地保存这些关键数据。忘记谁赢得了领导选举可能会对依赖 Zookeeper 确保安全但实际上并未将数据写入 Zookeeper 的系统造成巨大损害。在这种低吞吐量写入用例中，通常部署 Zookeeper 的人通常可以，因此应该 运行 安全地使用 forceSync=yes。
正如 2014 年线程强调的那样，可以采取一些方法来尝试不强制磁盘安全。 Battery-backed 提到了 raid 控制器，我记得在世纪之交的物理服务器上。我们还在每台连接到两个外部电网、冗余网卡、冗余发电机以恢复供电等的服务器中组合电源。然后您可以将服务器 运行 整合到不同的机架中，以便所有网络流量都可以通过多个 top-of-rack 开关。这会将相关故障的风险降低到可以忽略不计的程度。到那时，您可以在晚上睡觉，只担心意外 运行 部署会同时终止多个进程。也许这就是文档在使用该选项时关于 "being careful" 的意思。
问题是，在我工作过的最后三个跨国公司中，部署了 Zookeeper，它们都在库存 VM 上，没有提供任何关于机架位置或 anti-affinity 或相关故障的保证。无法保证如果我设置五个 VM 来托管 Zookeeper 整体，它们将不会全部分配给同一物理主机。此外，在任何未来的硬件升级期间，基础设施团队保留在不咨询我们的情况下在物理主机周围移动 VM 的权利。当 VM 在同一台主机上时，您几乎无法防止相关故障。如果不确定防弹措施是否到位以确保不会发生相关故障，我根本不会在 forceSync=no 晚上睡觉。
我注意到 zookeeper.forceSync 的默认配置是 "no"。
这意味着 FileChannel.Force() 不会在预写日志上调用。
我的印象是 zookeeper 使用的 Zab 共识算法能够正常工作。在响应领导者之前，所有条目都必须保存到磁盘。 否则在领导人选举期间，一些数据可能会丢失。
默认为"no"安全吗？
不，运行 和 forceSync=no 不安全。
正如在 zookeeper 用户列表中所讨论的 in 2014:
There's a big warning in the documentation that says that's a possibility.
If you don't force both Java and the OS to flush their IO buffers to disk,
then you have no guarantees that your data is consistent.
看看 2020 年的 zookeeper admin docs 它只会说：
forceSync
(Java system property: zookeeper.forceSync)
Requires updates to be synced to media of the transaction log before
finishing processing the update. If this option is set to no,
ZooKeeper will not require updates to be synced to the media.
您必须查看该部分标题和该部分的第一段才能意识到危险：
Unsafe Options
The following options can be useful, but be careful when you use them.
The risk of each is explained along with the explanation of what the
variable does.
对我来说，这不是 "big warning in the documentation"，而是说将该部分中的所有设置描述为 "unsafe"。没有关于使用该选项的风险的信息。例如，我希望可靠的文档能够提及下面讨论的相关故障的风险。您可能会考虑提出一张罚单，认为该不安全选项的文档没有应有的清晰和有用。
2014年的讨论似乎表明当时默认启用了forceSync。他们谈论 forceSync=no 中的一个错误，人们没有看到预期的性能改进。这表明默认设置是安全的，您必须通过设置 forceSync=no 来 "opt-out of safety" 以提高性能。如果现在默认为 forceSync=no，我建议您提交错误。
论坛上的讨论继续表明对于单个节点故障应该没有问题。出现这种情况是因为在数据至少位于两个节点上之前，在 ZAB 下的集合中不会有写入确认。如果数据没有被刷新并且没有被复制到多个节点上，那么你会在单个节点崩溃时丢失数据。
当数据没有刷新到磁盘时，最大的问题是当你有一个相关的节点故障时。如果磁盘未在至少一个节点上刷新，则向客户端确认的写入可能会丢失。 Zookeeper 通常用于低容量 meta-data，例如领导者选举结果。 Zookeeper 的全部卖点在于它应该可以安全地保存这些关键数据。忘记谁赢得了领导选举可能会对依赖 Zookeeper 确保安全但实际上并未将数据写入 Zookeeper 的系统造成巨大损害。在这种低吞吐量写入用例中，通常部署 Zookeeper 的人通常可以，因此应该 运行 安全地使用 forceSync=yes。
正如 2014 年线程强调的那样，可以采取一些方法来尝试不强制磁盘安全。 Battery-backed 提到了 raid 控制器，我记得在世纪之交的物理服务器上。我们还在每台连接到两个外部电网、冗余网卡、冗余发电机以恢复供电等的服务器中组合电源。然后您可以将服务器 运行 整合到不同的机架中，以便所有网络流量都可以通过多个 top-of-rack 开关。这会将相关故障的风险降低到可以忽略不计的程度。到那时，您可以在晚上睡觉，只担心意外 运行 部署会同时终止多个进程。也许这就是文档在使用该选项时关于 "being careful" 的意思。
问题是，在我工作过的最后三个跨国公司中，部署了 Zookeeper，它们都在库存 VM 上，没有提供任何关于机架位置或 anti-affinity 或相关故障的保证。无法保证如果我设置五个 VM 来托管 Zookeeper 整体，它们将不会全部分配给同一物理主机。此外，在任何未来的硬件升级期间，基础设施团队保留在不咨询我们的情况下在物理主机周围移动 VM 的权利。当 VM 在同一台主机上时，您几乎无法防止相关故障。如果不确定防弹措施是否到位以确保不会发生相关故障，我根本不会在 forceSync=no 晚上睡觉。