Мне было интересно, как Google, Facebook и т. Д. Справляются с аппаратными ошибками, такими как повреждение памяти, вычисление ошибок в CPU и т. Д. Учитывая увеличение плотности (и уменьшения размера) цепей , кажется, что частота аппаратных ошибок растет, а не вниз. Кроме того, у крупных поставщиков, таких как Google и Facebook, есть так много машин, что повреждение памяти должно быть повседневным явлением. Поэтому мне интересно, какую политику они имеют в отношении этого. В конце концов, большинство алгоритмов предполагают, что базовое оборудование работает правильно и что данные не изменяются в памяти и т. Д. Если это так, все ставки в основном отключены. Это может привести к повреждению не только для конкретных данных, которые подвержены этой ошибке, но и может быть распространено на другие вычисления. Например, если ошибка влияет на протокол блокировки/синхронизации, это может привести к опасностям, связанным с данными, с потоками или узлами и т. Д. Также может привести к повреждению базы данных, что приведет к возникновению нарушений инвариантов в другом месте и т. Д. Это может привести к сбою других узлов, обнаруживающих повреждение. Я видел это на практике, когда ошибочные данные в базе данных (недопустимая метка времени в строке, связанной с конфигурацией) приводили к сбою всей системы, потому что приложение проверяло метку времени при чтении строки!Как Google, Facebook и т. Д. Имеют дело с повреждением памяти и т. Д.
Надеюсь, в большинстве случаев ошибки просто приведут к сбою узла и т. Д., Возможно, даже до того, как будут выполнены какие-либо данные (например, если структура операционной системы повреждена). Но поскольку ошибки происходят в основном случайным образом, это может произойти повсюду, и ошибка может продолжаться, не будучи замеченной.
Это должно быть несколько сложной задачей. Кроме того, я думаю, что крупные провайдеры должны случайно видеть ошибки/стеки в своих журналах, которые не могут быть объяснены с помощью проверки/анализа кода, потому что ситуация просто не может произойти, если код выполнил «как написано». Но это может быть довольно сложно сделать, поэтому может быть проведено большое расследование по ошибке, прежде чем он окончательно придет к выводу, что это была аппаратная ошибка.
Конечно, это не ограничивается крупными поставщиками услуг, поскольку эти ошибки могут возникать повсюду. Но крупные поставщики услуг гораздо более подвержены этому воздействию, и для них было бы целесообразно проводить политику в этой области.
я могу увидеть различные способы, как это можно решить:
1) прагматические, ошибки ремонта, как вы идете вперед. Часто ремонт - это просто перезагрузка машины. В случаях, когда данные клиента повреждены, а кто-то жалуется, тогда исправьте это.
2) Укрепление кода, выполняющегося на отдельных узлах. Я не знаю, какие методы могут быть использованы, но, например, для вычисления некоторых результатов дважды и сравнения перед фиксацией. Разумеется, это приведет к накладным расходам, а сама логика сравнения может быть подвержена коррупции, но, возможно, довольно низкому риску, поскольку она требует ошибки в этой области. Кроме того, эту логику можно было бы дублировать.
3) Различные узлы, работающие в режиме блокировки, выполняются сравнения между узлами до того, как результаты будут разрешены.
4) Крупномасштабные архитектурные инициативы по уменьшению ущерба от локализованной ошибки. Убедитесь, что вы сравниваете содержимое БД с предыдущими резервными копиями, чтобы обнаружить битную гниль (прежде чем вслепую сделать другую резервную копию текущих данных) и т. Д. Различные проверки целостности на месте. Устойчивость в других узлах в случае поврежденных данных (не слишком сильно полагаясь на сохранение инвариантов и т. Д.). По существу «быть либеральным в том, что вы принимаете».
Там могут быть и другие вещи, которые я Havent мысль о том, что мой разум для задавая вопрос :)
Привет, да, я думаю, что память ECC - это хорошо и грустно, что она не доступна для обычных потребителей. Но все же, что касается ошибок, возникающих до того, как данные передаются в память (и вычисляется контрольная сумма), или после того, как она была прочитана (и проверена контрольная сумма). Такие ошибки не будут пойманы. Я полагаю, что внутренние структуры памяти в CPU (файл регистра и т. Д.) Потенциально подвержены коррупции. – Morty
Кроме того, я думал, что Google/Facebook попытался использовать дешевое сырьевое оборудование. По крайней мере, с Intel вы должны покупать относительно высокопроизводительные процессоры для поддержки ECC. – Morty
Сетевые протоколы имеют свои собственные защиты. Внутренние компьютерные шины имеют свои собственные защиты. У жестких дисков есть своя защита. Таким образом, оставшиеся уязвимые компоненты - это оперативная память, в которой может помочь ECC, и CPU, где в то же время необходимо решить ту же проблему. – dlask