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