我想知道谷歌、脸书等如何处理硬件错误，如内存损坏、CPU计算错误等。考虑到电路密度的增加(和尺寸的缩小(，硬件错误的频率似乎在上升，而不是下降。此外，像谷歌和脸书这样的大型供应商拥有如此多的机器，内存损坏肯定是每天都会发生的事情。所以我想知道他们对此有什么样的政策。毕竟，大多数算法都假设底层硬件运行正常，内存中的数据不会发生变化。如果发生了变化，那么所有的赌注基本上都会落空。这不仅可能导致受错误影响的特定数据损坏，而且可能会扩散到其他计算中。例如，如果错误影响了锁定/同步协议，则可能会对线程或节点等造成数据危害。或者可能损坏数据库，导致违反其他地方假定的不变量等。这可能会导致发现损坏的其他节点失败。我在实践中看到过这种情况，数据库中的错误数据(与配置相关的行中的无效时间戳(导致整个系统失败，因为应用程序在读取行时都验证了时间戳！
希望大多数时候，错误只会导致节点崩溃等，甚至可能在提交任何数据之前(例如，如果操作系统结构损坏(。但由于错误基本上是随机发生的，它可能发生在任何地方，而且错误可能会一直存在而不会被注意到。
这一定有些挑战性。此外，我认为大型提供商必须偶尔在其日志中看到错误/堆栈跟踪，这无法通过代码检查/分析来解释，因为如果代码"按编写"执行，这种情况根本不会发生。但这通常很难得出结论，因此在最终得出一定是硬件错误的结论之前，可能需要对错误进行大量调查。
当然，这并不局限于大型服务提供商，因为这些错误可能无处不在。但大型服务提供商更容易受到这种影响，他们在这方面制定政策是有意义的。
我可以看到不同的解决方法：
1( 务实，不断修正错误。通常，修复只是重新启动机器。如果客户数据被破坏，有人投诉，那么就修复它。
2( 强化在单个节点上运行的代码。我不知道可以使用什么技术，但例如计算两次某些结果，并在提交之前进行比较。这当然会产生开销，而且比较逻辑本身也可能会被破坏，但风险可能很低，因为它需要在该领域出现错误。此外，这种逻辑也可能是重复的。
3( 在锁定步骤中运行的不同节点，在允许提交结果之前，在节点之间进行比较。
4( 大规模架构计划，以减少局部错误造成的损害。确保将DB内容与以前的备份进行比较，以检测位腐烂(在盲目地对当前数据进行另一次备份之前(等。各种完整性检查到位。其他节点在数据损坏的情况下的弹性(不太依赖不变量等(。本质上是"在你接受的东西上是自由的"。
可能还有其他事情我没有想到，这就是我问这个问题的原因：(
至少内存内容必须可靠：
https://en.wikipedia.org/wiki/ECC_memory
还有其他错误检测/校正代码用于不同级别(校验和、散列等(。