Hardware 谷歌、Facebook等如何处理内存损坏等问题

我想知道Google、Facebook等如何处理硬件错误，如内存损坏、CPU计算错误等。考虑到电路密度的增加（以及尺寸的缩小），硬件错误的频率似乎在上升，而不是下降。此外，像谷歌和Facebook这样的大型供应商拥有如此多的机器，以至于内存损坏肯定每天都会发生。所以我想知道他们对此有什么样的政策。毕竟，大多数算法都假设底层硬件运行正常，并且内存中的数据不会发生变化，等等。如果发生了变化，那么所有的赌注基本上都没有了。这不仅会导致受错误影响的特定数据损坏，而且还可能扩展到其他计算。例如，如果错误影响锁定/同步协议，则可能导致线程或节点等的数据危险，或者可能损坏数据库，导致违反其他地方假定的不变量等。这可能导致发现损坏的其他节点失败。我在实践中看到过这种情况，数据库中的错误数据（配置相关行中的无效时间戳）导致整个系统失败，因为应用程序在读取行时验证了时间戳

希望在大多数情况下，错误只会导致节点崩溃等，甚至可能在提交任何数据之前（例如，如果操作系统结构损坏）。但是，由于错误基本上是随机发生的，因此它可能会在任何地方发生，并且错误可能会继续存在而不被注意

这一定有点挑战性。此外，我认为大型提供者必须偶尔在其日志中看到错误/堆栈跟踪，这无法通过代码检查/分析来解释，因为如果代码“按编写方式”执行，这种情况根本不会发生。但这通常很难下结论，因此在最终得出结论认为一定是硬件错误之前，可能需要对错误进行大量调查

当然，这并不局限于大型服务提供商，因为这些错误可能无处不在。但大型服务提供商更容易接触到这一点，他们在这方面制定政策是有意义的

我可以看到不同的解决方法：

1） 务实，在前进的过程中修复错误。通常，修复只是重新启动机器。如果客户数据损坏，有人投诉，则修复该问题

2） 强化在单个节点上运行的代码。我不知道可以使用什么技术，但举例来说，在提交之前计算两次特定结果并进行比较。这当然会产生开销，而且比较逻辑本身也可能会受到损坏，但风险可能相当低，因为它特别需要在该领域出现错误。此外，这种逻辑也可以复制

3） 在锁定步骤中运行的不同节点，在允许提交结果之前在节点之间进行比较

4） 减少局部错误造成的损害的大规模体系结构计划。确保将数据库内容与以前的备份进行比较，以检测位腐烂（在盲目地对当前数据进行另一次备份之前）等。执行各种完整性检查。在数据损坏的情况下，其他节点的弹性（不太依赖不变量保持等）。本质上是“在你接受的东西上保持自由”

---

可能还有其他我没有想到的事情，这就是我提出这个问题的原因：）

至少内存内容必须是可靠的：

---

还有其他各级使用的错误检测/纠正代码（校验和、哈希等）。

您好，我认为ECC内存是件好事，但遗憾的是，普通消费者不容易使用它。但是，在将数据提交到内存（并计算校验和）之前或在读取数据（并验证校验和）之后发生的错误又如何呢。这样的错误不会被发现。我想CPU中的内存结构（寄存器文件等）也可能会被破坏。此外，我还认为Google/Facebook试图使用廉价的商品硬件。至少对于英特尔来说，你必须购买相对高端的CPU才能支持ECC。网络协议有自己的保护。内部计算机总线有自己的保护。硬盘有自己的保护。因此，剩下的易受攻击的组件是RAM，ECC可以在其中提供帮助，而CPU则必须很快解决同样的问题。