действительно ли бедствие проверяет язык, существуют?

Я сомневаюсь, что возможности языка, которые вы описываете, достижимы.

Причина этого в том, что было бы очень сложно определить типичные и общие режимы отказа и способы их восстановления. от них. Подумайте на секунду о своем примере приложения - о каком-то веб-сайте с некоторой логикой и доступом к базе данных. Допустим, у нас есть язык, который может обнаруживать отключение питания и последующий перезапуск и каким-то образом восстанавливаться после этого. Проблема в том, что невозможно определить язык, на котором выполняется восстановление.

Допустим, ваше приложение представляет собой онлайн-приложение для блога. В этом случае может быть достаточно просто продолжить с того места, где мы потерпели неудачу, и все будет в порядке. Однако рассмотрим аналогичный сценарий для интернет-банка. Внезапно уже неразумно продолжать с одной и той же точки. Например, если я пытался снять немного денег со своего счета, и компьютер умер сразу после проверки, но до того, как он выполнил снятие, а затем он возвращается через неделю, он даст мне деньги, даже если мой счет находится в сейчас отрицательно.

Другими словами, не существует единой правильной стратегии восстановления, поэтому ее нельзя реализовать в языке. Что язык может сделать, так это сообщить вам, когда происходит что-то плохое, но большинство языков уже поддерживают это с помощью механизмов обработки исключений. Об остальном должны думать разработчики приложений.

Существует множество технологий, позволяющих разрабатывать отказоустойчивые приложения. Транзакции базы данных, устойчивые очереди сообщений, кластеризация, горячая замена оборудования и т. Д.

Программная транзакционная память (STM) в сочетании с энергонезависимой RAM, вероятно, удовлетворит исправленный вопрос OP.

STM - это метод реализации «транзакций», например, наборов действий, которые выполняются эффективно как атомарная операция или не выполняются вовсе. Обычно цель STM состоит в том, чтобы позволить высокопараллельным программам взаимодействовать с общими ресурсами способом, который легче понять, чем традиционное программирование с блокировкой ресурсов, и, возможно, имеет более низкие накладные расходы благодаря наличию очень оптимистичного безблокировочного стиля программирование.

Основная идея проста: все операции чтения и записи внутри блока «транзакции» записываются (каким-то образом!); если какие-либо два потока конфликтуют на этих наборах (конфликты чтения-записи или записи-записи) в конце любой из их транзакций, один выбирается в качестве победителя и продолжает работу, а другой вынужден откатить свое состояние до начала транзакции и повторно выполнить.

Если один настаивает, что все вычисления были транзакциями, а состояние в начале (/ end) каждой транзакции хранилась в энергонезависимой ОЗУ (NVRAM), сбой питания можно было рассматривать как сбой транзакции, приводящий к «откату». Вычисления будут производиться только из транзакционных состояний надежным способом. NVRAM в наши дни может быть реализован с флэш-памятью или с резервным аккумулятором. Может потребоваться МНОГО NVRAM, так как у программ много состояний (см. Рассказ о миникомпьютере в конце). В качестве альтернативы зафиксированные изменения состояния могут быть записаны в файлы журнала, которые были записаны на диск; это стандартный метод, используемый большинством баз данных и надежными файловыми системами.

Текущий вопрос о STM: насколько дорого обходится отслеживание потенциальных конфликтов транзакций? Если реализация STM значительно замедлит работу машины, люди будут жить с существующими немного ненадежными схемами, а не откажутся от этой производительности. Пока что история плохая, но исследования еще рано.

Люди обычно не разрабатывают языки для STM; для исследовательских целей они в основном улучшенная Java с помощью STM (см. статью «Сообщения ACM в июне? этого года»). Я слышал, что у MS есть экспериментальная версия C #. У Intel есть экспериментальная версия для C и C ++. На странице википедии есть длинный список. И ребята из функционального программирования как обычно, утверждают, что свойство функциональных программ без побочных эффектов делает STM относительно тривиальным для реализации на функциональных языках.

Если я правильно помню, еще в 70-х годах в распределенных операционных системах проводились значительные ранние работы, в которых процессы (код + состояние) могут тривиально перемещаться от машины к машине. Я считаю, что несколько таких систем явно допускают отказ узла и могут перезапустить процесс на отказавшем узле из состояния сохранения на другом узле. Ранняя ключевая работа была на Распределенная вычислительная система Дэйва Фарбера. Поскольку разработка языков в 70-х годах была популярна, я помню, что в DCS был свой собственный язык программирования, но я не помню его названия. Если DCS не допускает сбоя и перезапуска узла, я почти уверен, что это сделали следующие исследовательские системы.

РЕДАКТИРОВАТЬ: Система 1996 года, которая на первый взгляд кажется обладающей желаемыми свойствами, является задокументировано здесь . Его концепция атомарных транзакций соответствует идеям STM. (Доказывает, что под солнцем не так много нового.)

Примечание: в 70-х годах Core Memory все еще была королем. Ядро, будучи магнитным, было энергонезависимым при сбоях питания, и многие миникомпьютеры (и я уверен, что мэйнфреймы) имели прерывания при сбое питания, которые уведомляли программное обеспечение за несколько миллисекунд до потери питания. Используя это, можно было легко сохранить состояние регистра машины и полностью выключить ее. Когда питание будет восстановлено, управление вернется к точке восстановления состояния, и программа сможет продолжить работу. Таким образом, многие программы могут пережить мигание питания и надежно перезапуститься. Я лично построил систему разделения времени на миникомпьютере Data General Nova; на самом деле вы могли бы запустить 16 телетайпов на полную мощность, получить мощный удар, вернуться и перезапустить все телетайпы, как будто ничего не произошло. Переход от какофонии к тишине и обратно был ошеломляющим, я знаю, мне приходилось повторять это много раз, чтобы отладить код управления сбоями питания, и, конечно, получилась отличная демонстрация (выдернуть вилку, гробовая тишина, снова подключить ... .). Название языка, который это сделал, было, конечно, Ассемблер: -}

Windows Workflow Foundation может решить вашу проблему. Он основан на .Net и графически представляет собой рабочий процесс с состояниями и действиями.

Он обеспечивает постоянство в базе данных (автоматически или по запросу). Вы можете сделать это между состояниями / действиями. Это сериализует весь экземпляр вашего рабочего процесса в базу данных. Он будет повторно гидратирован, и выполнение будет продолжено при выполнении любого из ряда условий (определенное время, регидратация программно, срабатывание событий и т. Д.)

Когда хост WWF запускается, он проверяет постоянную базу данных и повторно гидратирует любые рабочие процессы хранится там. Затем он продолжает выполняться с точки зрения сохранения.

Даже если вы не хотите использовать аспекты рабочего процесса, вы, вероятно, все равно можете просто использовать службу сохранения.

• First, implement a fault tolerant application. One where, where, if you have 8 features and 5 failure modes, you have done the analysis and test to demonstrate that all 40 combinations work as intended (and as desired by the specific customer: no two will likely agree).
• second, add a scripting language on top of the supported set of fault-tolerant features. It needs to be as near to stateless as possible, so almost certainly something non-Turing-complete.
• finally, work out how to handle restoration and repair of scripting language state adapted to each failure mode.

And yes, this is pretty much rocket science.

Если вы хотите сохранить информацию о программе, где бы вы ее сохранили?

Его необходимо сохранить, например, на диск. Но это не помогло бы вам, если бы диск вышел из строя, поэтому он уже не защищен от сбоев.

Вы получите только определенный уровень детализации в сохраненном состоянии. Если вам нужно что-то вроде tihs, то, вероятно, лучшим подходом будет определение уровня детализации с точки зрения того, что составляет атомарную операцию, и сохранение состояния в базе данных перед каждой атомарной операцией. Затем вы можете вернуться к точке атомарной операции этого уровня.

Я не знаю ни одного языка, который делал бы это автоматически, так как стоимость сохранения состояния во вторичном хранилище чрезвычайно высока. Следовательно, существует компромисс между уровнем детализации и эффективности,

Я считаю фундаментальной ошибкой то, что восстановление не является важной проблемой проектирования. Принятие ответственности исключительно за окружающую среду приводит к обычно хрупкому решению, нетерпимому к внутренним сбоям.

Если бы это был я, я бы вложил средства в надежное оборудование И спроектировал бы программное обеспечение таким образом, чтобы оно могло автоматически восстанавливаться в любых возможных условиях. В соответствии с вашим примером обслуживание сеанса базы данных должно выполняться автоматически с помощью API достаточно высокого уровня. Если вам необходимо вручную переподключиться, вы, вероятно, используете неправильный API.

Как отмечали другие, языки процедур, встроенные в современные системы РСУБД, - лучшее, что вы можете получить без использования экзотического языка.

Виртуальные машины в целом предназначены для такого рода вещей. Вы можете использовать API поставщиков виртуальных машин (vmware..et al) для управления периодическими контрольными точками в вашем приложении по мере необходимости.

VMWare, в частности, имеет функцию воспроизведения (Enhanced Execution Record), которая записывает ВСЕ и позволяет воспроизводить в определенный момент времени. Очевидно, что такой подход сильно снижает производительность, но он отвечает требованиям. Я бы просто удостоверился, что у ваших дисковых накопителей есть кэш записи с резервным питанием от батареи.

Скорее всего, вы сможете найти аналогичные решения для запуска байт-кода Java внутри виртуальной машины Java. Отказоустойчивая JVM и контрольная точка виртуальных машин Google.

Наиболее близким приближением является SQL. Однако это не совсем языковая проблема; это в основном проблема виртуальной машины. Я мог представить себе виртуальную машину Java с этими свойствами; реализовать это было бы другое дело.

Быстрое и грязное приближение достигается с помощью контрольной точки приложения. Вы теряете свойство «умереть в любой момент», но оно довольно близко.

В случае сбоя питания ... мне кажется: «Когда твой единственный инструмент - молоток, каждая проблема выглядит как гвоздь»

Вы не решаете проблемы сбоя питания в рамках программы. Вы решаете эту проблему с помощью резервных источников питания, аккумуляторов и т. Д.

Если я правильно понимаю ваш вопрос, я думаю, что вы спрашиваете, действительно ли это '

Если вы согласны со мной, то будете разочарованы, узнав, что проблема остановки неразрешима. Следовательно, нельзя доказать, что ни один "аварийно-устойчивый" язык, компилятор или среда таковы.

Однако вполне разумно разработать язык, который предоставляет варианты восстановления для различных распространенных проблем.

В зависимости от вашего определения бедствия, делегирование этой ответственности языку может варьироваться от «трудно» до «практически невозможно».

Другие приведенные примеры включают сохранение текущего состояния приложения в NVRAM после выполнения каждого оператора. Это работает только до тех пор, пока компьютер не будет разрушен.

Как функция языкового уровня узнает о перезапуске приложения на новом хосте?

А в случае восстановления приложения на хосте - что, если прошло значительное время и сделанные ранее предположения / проверки стали недействительными?

T-SQL, PL / SQL и другие языки транзакций, вероятно, настолько близки к «защите от катастроф» - они либо успешны (и данные сохраняются), либо нет. За исключением отключения изоляции транзакций, трудно (но, вероятно, не невозможно, если вы очень постараетесь) попасть в «неизвестные» состояния.

Вы можете использовать такие методы, как SQL Mirroring, чтобы гарантировать, что записи сохраняются как минимум в двух местах одновременно, прежде чем транзакция будет зафиксирована.

Вам все равно необходимо сохранять свое состояние каждый раз, когда оно безопасно (фиксация).

Во встроенном мире это может быть реализовано через сторожевое прерывание и ОЗУ с резервным питанием от батарей. Я сам такое написал.

Группа робототехники Microsoft представила набор библиотек, которые могут быть применимы к вашему вопросу.

Что такое параллелизм и координация Среда выполнения (CCR)?

Параллелизм и координация Среда выполнения (CCR) обеспечивает высокую степень одновременности модель программирования на основе передача сообщений с помощью мощных примитивы оркестровки, позволяющие согласование данных и работа без использование ручной нарезки, замков, семафоры и т. д. CCR обращается к необходимость многоядерного и параллельного приложений, предоставив модель программирования, которая облегчает управление асинхронными операциями, работа с параллелизмом, использование параллельное оборудование и частичная обработка сбой.

Что такое децентрализованное программное обеспечение Службы (DSS)?

Децентрализованные службы программного обеспечения (DSS) обеспечивает легкий, ориентированный на состояние сервисная модель, сочетающая передача репрезентативного состояния (REST) с формализованным составом и архитектура уведомления о событиях обеспечение системного подхода к создание приложений. В DSS услуги представлены как ресурсы которые доступны как программно и для UI манипуляции. Путем интеграции сервиса состав, структурированное состояние манипуляции и уведомление о событиях с изоляцией данных DSS обеспечивает единая модель для письма высоко наблюдаемый, слабосвязанный приложения, работающие на одном узле или по сети.

Большинство ответов даны на языках общего назначения. Возможно, вы захотите изучить более специализированные языки, которые используются во встроенных устройствах. Робот - хороший пример для размышления. Что бы вы хотели и / или ожидать от робота, когда он восстанавливается после сбоя питания?

Try taking an existing open source interpreted language and see if you could adapt its implementation to include some of these features. Python's default C implementation embeds an internal lock (called the GIL, Global Interpreter Lock) that is used to "handle" concurrency among Python threads by taking turns every 'n' VM instructions. Perhaps you could hook into this same mechanism to checkpoint the code state.

Существует несколько коммерчески доступных фреймворков Veritas, Sun's HA, IBM HACMP и т. Д. И т. Д. который будет автоматически отслеживать процессы и запускать их на другом сервере в случае сбоя.

Существует также дорогостоящее оборудование, такое как HP Tandem Nonstop range, которое может выдерживать внутренние сбои оборудования.

Однако люди создают программное обеспечение, и люди любят его получать. это неправильно. Рассмотрим поучительную историю о программе IEFBR14, поставляемой с IBM MVS. По сути, это фиктивная программа NOP, которая позволяет декларативным битам JCL выполняться без реального запуска программы. Это весь исходный код: -

     IEFBR14 START
             BR    14       Return addr in R14 -- branch at it
             END

Нет ничего проще? За свою долгую жизнь эта программа фактически накопила отчет об ошибке и теперь находится в версии 4.

Это 1 ошибка на три строки кода, текущая версия в четыре раза больше оригинальной.

Ошибки будут всегда подкрадывайтесь, просто убедитесь, что сможете оправиться от них.

Рассмотрим систему, построенную из энергонезависимой памяти . Состояние программы сохраняется все время, и если процессор остановится на какой-то период времени, он возобновится с той точки, на которой он оставался при перезапуске. Следовательно, ваша программа «защищена от бедствий» в той мере, в какой она может пережить сбой питания.

Это вполне возможно, как отмечается в других сообщениях, когда речь идет о программной транзакционной памяти, «отказоустойчивости» и т. д. Любопытно, что никто не упомянул «мемристоры», так как они предложат будущую архитектуру с этими свойствами и такую, которая, возможно, тоже не является полностью архитектурой фон Неймана.

Теперь представьте систему, построенную из двух таких дискретных систем - для простой иллюстрации одна является сервером базы данных, а другая - сервером приложений для веб-сайта онлайн-банкинга.

Если одна приостановить, что делает другой? Как он справляется с внезапной недоступностью своего коллеги?

С этим можно было бы справиться на уровне языка, но это означало бы много обработки ошибок и тому подобное, а исправить этот код сложно. Это почти не лучше, чем то, где мы находимся сегодня, где машины не имеют контрольных точек, но языки пытаются обнаружить проблемы и попросить программиста разобраться с ними.

Это тоже может приостановиться - на аппаратном уровне они могут быть связаны друг с другом, так что с точки зрения мощности они являются одним целым система. Но это вряд ли хорошая идея; лучшая доступность может быть обеспечена отказоустойчивой архитектурой с системами резервного копирования и т. д.

Или мы могли бы использовать постоянные очереди сообщений между двумя машинами. Однако в какой-то момент эти сообщения обрабатываются, и они могут быть слишком старыми! Только логика приложения может реально работать, что делать в этих обстоятельствах, и вот мы снова возвращаемся к языкам, которые снова делегируются программисту.

Таким образом, кажется, что защита от сбоев лучше в нынешней форме - бесперебойное питание, горячее резервирование серверы готовы к работе,

Нет , аварийно-устойчивого языка не существует.

Изменить:

] Защита от стихийных бедствий предполагает совершенство. Он вызывает в памяти образы процесса, который применяет некоторый интеллект для логического решения неизвестных, неопределенных и неожиданных условий. Не существует способа, которым язык программирования мог бы это сделать. Если вы, как программист, не можете понять, как ваша программа выйдет из строя и как восстановиться после этого, то ваша программа не работает. Я тоже не собираюсь этого делать.

С точки зрения ИТ, катастрофы могут возникать в стольких формах, что ни один процесс не может решить все эти различные проблемы. Идея о том, что вы можете разработать язык, учитывающий все способы, при которых что-то может пойти не так, просто неверна. Из-за абстракции от оборудования многие проблемы даже не имеют смысла решать с помощью языка программирования; тем не менее, они все еще являются «бедствиями».

Конечно, как только вы начнете ограничивать масштаб проблемы; тогда мы можем начать говорить о ее решении. Итак, когда мы перестаем говорить о защите от бедствий и начинаем говорить о восстановлении после неожиданных скачков напряжения, становится намного проще разработать язык программирования для решения этой проблемы, даже если, возможно, это не так. Имеет смысл решать эту проблему на таком высоком уровне стека. Тем не менее, я рискну предположить, что, если вы ограничитесь реалистичными реализациями, он станет неинтересным как язык, поскольку стал настолько специфичным. т.е. использовать мой язык сценариев для запуска пакетных процессов в одночасье, которые восстановятся после неожиданных скачков напряжения и потерянных сетевых соединений (с некоторой помощью человека); На мой взгляд, это не убедительное экономическое обоснование.

Пожалуйста, поймите меня правильно. В этой ветке есть несколько отличных предложений, но, на мой взгляд, они не подходят ни к чему, даже отдаленно приближающемуся к аварийному.

Пожалуйста, поймите меня правильно. В этой ветке есть несколько отличных предложений, но, на мой взгляд, они не подходят ни к чему, даже отдаленно приближающемуся к аварийному.

Пожалуйста, поймите меня правильно. В этой ветке есть несколько отличных предложений, но, на мой взгляд, они не подходят ни к чему, даже отдаленно приближающемуся к аварийному.

Большинство таких усилий, называемых « отказоустойчивостью », связаны с аппаратным обеспечением, а не программным обеспечением.

Крайним примером этого является Тандем. , чьи «безостановочные» машины имеют полное резервирование.

Реализация отказоустойчивости на аппаратном уровне привлекательна, поскольку программный стек обычно состоит из компонентов, полученных от разных поставщиков - ваше программное обеспечение высокой доступности может быть установлено вместе с некоторыми явно ненадежные другие приложения и службы поверх ненадежной операционной системы, использующей явно ненадежные драйверы устройств…

Но на уровне языка почти все языки предлагают средства для надлежащей проверки ошибок. Однако даже с RAII, исключениями, ограничениями и транзакциями, эти пути кода редко тестируются правильно и редко тестируются вместе в сценариях с множественными отказами, и обычно ошибки скрываются в коде обработки ошибок. Так что это больше о понимании программиста, дисциплине и компромиссах, чем о самих языках.

Это возвращает нас к отказоустойчивости на уровне оборудования. Если вы можете избежать сбоя связи с базой данных, вы можете избежать использования хитроумного кода обработки ошибок в приложениях.

Насколько я знаю¹, Ада часто используется в критически важных для безопасности (отказоустойчивых) системах.

Ада изначально была нацелена на встроенные системы и системы реального времени.

Примечательные особенности Ada включают: строгая типизация, механизмы модульности (пакеты), проверка во время выполнения, параллельная обработка (задачи), исключение обработка и дженерики. Добавлен Ada 95 поддержка объектно-ориентированных программирование, в том числе динамическое отправка.

Ada поддерживает проверки времени выполнения в порядке для защиты от доступа к нераспределенная память, переполнение буфера ошибки, единичные ошибки, массив ошибки доступа и другие обнаруживаемые ошибки. Эти проверки можно отключить в интерес к эффективности выполнения, но часто может быть эффективно скомпилирован. Он также включает средства, чтобы помочь проверка программы.

Для этих причины, Ада широко используется в critical systems, where any anomaly might lead to very serious consequences, i.e., accidental death or injury. Examples of systems where Ada is used include avionics, weapon systems (including thermonuclear weapons), and spacecraft.

N-Version programming may also give you some helpful background reading.

¹That's basically one acquaintance who writes embedded safety critical software

Erlang был разработан для использования в телекоммуникационных системах, где высокая относительная влажность является фундаментальной. Я думаю, что у них есть стандартная методология построения наборов взаимодействующих процессов, в которых сбои могут быть корректно обработаны.

ERLANG - это параллельный функциональный язык, хорошо подходящий для распределенного, высокопараллельного и отказоустойчивого программного обеспечения. Важной частью Erlang является его поддержка восстановления после сбоев. Отказоустойчивость обеспечивается за счет организации процессов приложения ERLANG в древовидной структуре. В этих структурах родительские процессы отслеживают сбои своих дочерних процессов и несут ответственность за их перезапуск.

Точно ответ:

Ada и SPARK были разработаны для обеспечения максимальной отказоустойчивости и для перемещения всех возможных ошибок во время компиляции, а не во время выполнения. Ada была разработана Министерством обороны США для военных и авиационных систем. работает на встроенных устройствах, например в самолетах. Spark - его потомок. В ранней космической программе США использовался еще один язык, HAL / S, предназначенный для обработки отказов ОБОРУДОВАНИЯ и повреждения памяти из-за космических лучей.

Практический ответ:

Я никогда не встречал никого, кто мог бы кодировать Ada / Spark. Для большинства пользователей лучший ответ - это варианты SQL в СУБД с автоматическим переключением при отказе и кластеризацией серверов. Проверка целостности гарантирует безопасность. Что-то вроде T-SQL или PL / SQL имеет полную безопасность транзакций, является полным по Тьюрингу и довольно устойчиво к проблемам.

Причина, по которой нет лучшего ответа:

По соображениям производительности вы не можете обеспечить надежность для каждой операции программы. Если бы вы это сделали, обработка замедлилась бы до скорости вашего самого быстрого неизменяемого хранилища. В лучшем случае, ваша производительность упадет в тысячу или миллион раз из-за того, насколько НИЧЕГО медленнее, чем кеши ЦП или ОЗУ.

Это было бы эквивалентом перехода от процессора Core 2 Duo к древнему процессору 8086 - самое большее, вы могли бы выполнять пару сотен операций в секунду. За исключением того, что это было бы даже МЕДЛЕННО.

В случаях, когда существуют частые циклы включения питания или отказы оборудования, вы используете нечто вроде СУБД, которая гарантирует ACID для каждой важной операции. Или вы используете оборудование с быстрым энергонезависимым хранилищем (например, флеш-память) - это все еще намного медленнее, но если обработка проста, это нормально.

В лучшем случае ваш язык обеспечивает хорошую безопасность во время компиляции проверяет наличие ошибок и генерирует исключения, а не дает сбой. Обработка исключений - это функция половины используемых в настоящее время языков.

Это было бы эквивалентом перехода от процессора Core 2 Duo к древнему процессору 8086 - самое большее, вы могли бы выполнять пару сотен операций в секунду. За исключением того, что это было бы даже МЕДЛЕННО.

В случаях, когда существуют частые циклы включения питания или отказы оборудования, вы используете нечто вроде СУБД, которая гарантирует ACID для каждой важной операции. Или вы используете оборудование с быстрым энергонезависимым хранилищем (например, флеш-память) - это все еще намного медленнее, но если обработка проста, это нормально.

В лучшем случае ваш язык обеспечивает хорошую безопасность во время компиляции проверяет наличие ошибок и генерирует исключения, а не дает сбой. Обработка исключений - это функция половины используемых в настоящее время языков.

Это было бы эквивалентом перехода от процессора Core 2 Duo к древнему процессору 8086 - самое большее, вы могли бы выполнять пару сотен операций в секунду. За исключением того, что это было бы даже МЕДЛЕННО.

В случаях, когда существуют частые циклы включения питания или отказы оборудования, вы используете что-то вроде СУБД, которая гарантирует ACID для каждой важной операции. Или вы используете оборудование с быстрым энергонезависимым хранилищем (например, флеш-память) - это все еще намного медленнее, но если обработка проста, это нормально.

В лучшем случае ваш язык обеспечивает хорошую безопасность во время компиляции проверяет наличие ошибок и генерирует исключения, а не дает сбой. Обработка исключений - это функция половины используемых в настоящее время языков.

Это было бы эквивалентом перехода от процессора Core 2 Duo к древнему процессору 8086 - самое большее, вы могли бы выполнять пару сотен операций в секунду. За исключением того, что это было бы даже МЕДЛЕННО.

В случаях, когда существуют частые циклы включения питания или отказы оборудования, вы используете что-то вроде СУБД, которая гарантирует ACID для каждой важной операции. Или вы используете оборудование с быстрым энергонезависимым хранилищем (например, флеш-память) - это все еще намного медленнее, но если обработка проста, это нормально.

В лучшем случае ваш язык обеспечивает хорошую безопасность во время компиляции проверяет наличие ошибок и выбрасывает исключения, а не дает сбой. Обработка исключений - это функция половины используемых в настоящее время языков.

Это было бы эквивалентом перехода от процессора Core 2 Duo к древнему процессору 8086 - самое большее, вы могли бы выполнять пару сотен операций в секунду. За исключением того, что это было бы даже МЕДЛЕННО.

В случаях, когда существуют частые циклы включения питания или отказы оборудования, вы используете что-то вроде СУБД, которая гарантирует ACID для каждой важной операции. Или вы используете оборудование с быстрым энергонезависимым хранилищем (например, флеш-память) - это все еще намного медленнее, но если обработка проста, это нормально.

В лучшем случае ваш язык обеспечивает хорошую безопасность во время компиляции проверяет наличие ошибок и генерирует исключения, а не дает сбой. Обработка исключений - это функция половины используемых в настоящее время языков.

В случаях, когда происходят частые отключения питания и отказы оборудования, вы используете что-то вроде СУБД, которая гарантирует ACID для каждой важной операции. Или вы используете оборудование с быстрым энергонезависимым хранилищем (например, флеш-память) - это все еще намного медленнее, но если обработка проста, это нормально.

В лучшем случае ваш язык обеспечивает хорошую безопасность во время компиляции проверяет наличие ошибок и генерирует исключения, а не дает сбой. Обработка исключений - это функция половины используемых в настоящее время языков.

В случаях, когда происходят частые отключения питания и отказы оборудования, вы используете что-то вроде СУБД, которая гарантирует ACID для каждой важной операции. Или вы используете оборудование с быстрым энергонезависимым хранилищем (например, флеш-память) - это все еще намного медленнее, но если обработка проста, это нормально.

В лучшем случае ваш язык обеспечивает хорошую безопасность во время компиляции проверяет наличие ошибок и генерирует исключения, а не дает сбой. Обработка исключений - это функция половины используемых в настоящее время языков.

В лучшем случае ваш язык дает вам хорошие проверки безопасности во время компиляции на наличие ошибок и будет генерировать исключения вместо сбоев. Обработка исключений - это функция половины используемых в настоящее время языков.

В лучшем случае ваш язык дает вам хорошие проверки безопасности во время компиляции на наличие ошибок и будет генерировать исключения вместо сбоев. Обработка исключений - это функция половины используемых в настоящее время языков.

«Таким образом, язык, который запоминает свое состояние в любой момент, независимо от того, отключится ли питание, и продолжает работу с того места, где он был остановлен.»

»продолжается с того места, где он остановился. « часто не является правильной стратегией восстановления. Ни один язык или среда в мире не будут пытаться угадать, как автоматически исправить конкретную ошибку. Лучшее, что он может сделать, - это предоставить вам инструменты для написания собственной стратегии восстановления таким образом, чтобы это не мешало вашей бизнес-логике, например

На мой взгляд, концепция восстановления после сбоя в большинстве случаев является бизнес-проблемой, а не проблемой оборудования или языка.

Возьмем пример: у вас один уровень пользовательского интерфейса и одна подсистема. Подсистема не очень надежна, но клиент на уровне пользовательского интерфейса должен воспринимать это так, как если бы это было так.

Теперь представьте, что каким-то образом происходит сбой вашей подсистемы, вы действительно думаете, что язык, который вы представляете, может думать за вас, как обрабатывать уровень пользовательского интерфейса в зависимости от этой подсистемы?

Ваш пользователь должен четко осознавать, что эта подсистема ненадежна, если вы используете обмен сообщениями для обеспечения высокой надежности, клиент ДОЛЖЕН знать, что (если он не знает, пользовательский интерфейс может просто зависнуть в ожидании ответа, который может прийти через 2 недели). Если он должен знать об этом, это означает, что любые воздержания, чтобы скрыть это, в конечном итоге просочатся.

Под клиентом я имею в виду конечного пользователя. И пользовательский интерфейс должен отражать эту ненадежность, а не скрывать ее, в этом случае компьютер не может думать за вас.

If I were going about solving your problem, I would write a daemon (probably in C) that did all database interaction in transactions so you won't get any bad data inserted if it gets interrupted. Then have the system start this daemon at startup.

Obviously developing web stuff in C is quite slower than doing it in a scripting language, but it will perform better and be more stable (if you write good code of course :).

Realistically, I'd write it in Ruby (or PHP or whatever) and have something like Delayed Job (or cron or whatever scheduler) run it every so often because I wouldn't need stuff updating ever clock cycle.

Hope that makes sense.

Если режим отказа ограничен отказом оборудования, VMware Fault Tolerance заявляет то же самое, что и вы. Он запускает пару виртуальных машин в нескольких кластерах, и, используя то, что они называют vLockstep, основная виртуальная машина отправляет все состояния на вспомогательную виртуальную машину в реальном времени, поэтому в случае отказа основной машины выполнение прозрачно переключается на вспомогательную.

Я предполагаю, что это не поможет сбоям связи, которые встречаются чаще, чем отказ оборудования. Для серьезной высокой доступности вам следует рассмотреть распределенные системы, такие как групповой подход Бирмана ( статья в формате pdf или книга Надежные распределенные системы: технологии, веб-службы и приложения ).

Его главная особенность, однако, должна заключаться в следующем: если питание умирает, и вещь перезапускается, она берет с того места, где была остановлена ​​(так что он не только запоминает, где он был, он будет помнить состояния переменных как хорошо). Кроме того, если он остановился в середине копии файла, он также будет правильно возобновлен. и т. д. и т. д.

... ...

Я уже смотрел на erlang раньше. Какими бы хорошими ни были его отказоустойчивые функции ... Он не выдерживает отключения питания. Когда код перезапустится, вам придется собирать фрагменты

Если бы такая технология существовала, мне ОЧЕНЬ интересно было бы про нее прочитать. Тем не менее, решение Erlang будет иметь несколько узлов - в идеале в разных местах - чтобы, если одно место выйдет из строя, другие узлы могли бы восполнить пробел. Если бы все ваши узлы находились в одном месте и на одном источнике питания (не очень хорошая идея для распределенных систем), вам не повезло, как вы упомянули в следующем комментарии.

Чтобы программа продолжала работу с того места, где она была остановлена, если машина теряет питание, ей нужно не только сохранять состояние в где-то , ОС также должна «знать» "чтобы возобновить его.

Я полагаю, что реализовать функцию" гибернации "на языке можно, но постоянное выполнение этого в фоновом режиме, чтобы он был готов в случае чего-то плохого, звучит как работа ОС, на мой взгляд .

Этот вопрос заставил меня опубликовать этот текст

(Цитата из HGTTG ​​от Дугласа Адамса :)

Щелк, гул.

Огромный серый разведывательный корабль «Гребулон» бесшумно двигался сквозь черную пустоту. Он летел с невероятной, захватывающей дух скоростью, но казалось, что на мерцающем фоне миллиарда далеких звезд он вообще не двигался. Это было всего лишь одно темное пятнышко, застывшее на фоне бесконечной зернистости яркой ночи.

На борту корабля все было так, как было тысячелетиями, в глубокой темноте и Безмолвии.

Щелчок, гул.

По крайней мере, почти все.

Щелчок, щелчок, гул.

Щелчок, гул, щелчок, гул, щелчок, гул.

Щелчок, щелчок, щелчок, щелчок, щелчок, гул.

Хммм.

Программа наблюдения низкого уровня разбудила программу наблюдения немного более высокого уровня глубоко в корабле ' полусонный кибермозг и сообщил ему, что всякий раз, когда он щелкает, все, что он слышит, - это гул.

Программа супервизии более высокого уровня спросила ее, что она должна получить, а программа супервизии нижнего уровня ответила, что не может точно вспомнить, но подумала, что это, вероятно, было чем-то вроде отдаленного удовлетворенного вздоха, не так ли ? Он не знал, что это за гул. Щелк, гул, щелк, гул. Это было все, что он получал.

Программа супервизии более высокого уровня учла это, и ей это не понравилось. Он спросил программу надзора низкого уровня, что именно она контролирует, и программа надзора низкого уровня ответила, что не может вспомнить и этого, просто это было то, что должно было щелкать, вздыхать каждые десять лет или около того, что обычно происходило без потерпеть неудачу. Он пытался просмотреть свою таблицу поиска ошибок, но не смог Я не нашел его, поэтому он предупредил о проблеме программу надзора более высокого уровня.

Программа супервизии более высокого уровня обратилась к одной из своих справочных таблиц, чтобы выяснить, что программа супервизии нижнего уровня должна была контролировать.

Не удалось найти справочную таблицу.

Нечетный.

Он посмотрел снова. Все, что он получил, это сообщение об ошибке. Он попытался найти сообщение об ошибке в своей таблице поиска сообщений об ошибке, но также не смог его найти. Это позволило пройти пару наносекунд, пока он снова прошел через все это. Затем он разбудил своего начальника секторальной функции.

Супервизор секторных функций немедленно столкнулся с проблемами. Он позвонил своему контролирующему агенту, который тоже нашел проблемы. В пределах нескольких миллионных долей секунды виртуальные цепи, которые бездействовали, некоторые годы, некоторые века, пылали по всему кораблю. Что-то где-то пошло не так, но ни одна из контролирующих программ не могла сказать, что это было. На каждом уровне отсутствовали жизненно важные инструкции, и инструкции о том, что делать в случае обнаружения того, что жизненно важные инструкции отсутствуют.

Небольшие программные модули - агенты - пронеслись по логическим путям, группировке, консультациям, перегруппировке. Они быстро установили, что память корабля, вплоть до его центрального модуля, была испорчена. Никакие допросы не могли определить, что именно произошло. Кажется, поврежден даже сам центральный модуль.

Это упростило решение всей проблемы. Замените центральный модуль миссии. Был еще один, резервный, точная копия оригинала. Его пришлось физически заменить, потому что по соображениям безопасности не было никакой связи между оригиналом и его резервной копией. Как только центральный модуль миссии был заменен, он мог сам контролировать реконструкцию остальной системы во всех деталях, и все было в порядке.

Роботам было приказано доставить резервный центральный модуль миссии из экранированной сейфовой комнаты, где они его охраняли, в логическую камеру корабля для установки.

Это включало длительный обмен аварийными кодами и протоколами, когда роботы опрашивали агентов на предмет подлинности инструкций. Наконец роботы убедились, что все процедуры выполнены правильно. Они вытащили резервный центральный модуль миссии из отсека для хранения, вынесли его из камеры хранения, упали с корабля и полетели в пустоту.

Это стало первым важным ключом к разгадке того, что было не так.

Дальнейшее расследование быстро установило, что именно произошло. Метеорит пробил в корабле большую дыру. Корабль ранее не обнаруживал этого, потому что метеорит аккуратно выбил ту часть технологического оборудования корабля, которая должна была определить, был ли корабль поражен метеоритом.

Первое, что нужно было сделать, - это попытаться опечатать дыра. Это оказалось невозможным, потому что датчики корабля не могли видеть, что есть дыра, а наблюдатели, которые должны были сказать, что датчики не работают должным образом, не работали должным образом и продолжали говорить, что датчики в порядке. Корабль мог сделать вывод о существовании дыры только по тому факту, что роботы явно выпали из нее. забрав свой запасной мозг, который позволил бы ему увидеть дыру, с ними.

Корабль попытался осмыслить это, но потерпел неудачу, а затем на некоторое время полностью отключился. Он, конечно, не осознавал, что отключился, потому что отключился. Просто удивился, увидев прыгающие звезды. После третьего прыжка звезд корабль наконец понял, что он, должно быть, тускнеет, и что пора принимать серьезные решения.

Он расслабился.

Затем он понял, что на самом деле еще не принял серьезных решений, и запаниковал. Он снова немного погас. Когда он снова проснулся, он запечатал все переборки вокруг, где, как он предполагал, должна быть невидимая дыра.

Он явно еще не добрался до места назначения, судорожно подумал он, но так как он больше не имел ни малейшего представления о том, где находится его пункт назначения и как его достичь, казалось, не было смысла продолжать. Он сверился с тем, какие крохотные обрывки инструкций можно было восстановить из обломков своего центрального модуля.

"Ваша !!!!! !!!!! !!!!! год миссия !!!!! !!!!! !!!!! !!!!!, !!!!! !!!!! !!!!! !!!!!, земля !!!!! !!!!! !!!!! на безопасном расстоянии !!!!! !!!!! ..... ..... ..... ...., земля ..... ..... ..... следи за ней. !!!!! !!!!! !!!!!. .. "

Все остальное - полная чушь.

Прежде чем он отключится навсегда, корабль должен передать эти инструкции своим более примитивным вспомогательным системам.

Он также должен оживить всю свою команду.

Возникла еще одна проблема. Пока экипаж находился в спячке, умы всех его членов, их воспоминания, их личности и понимание того, для чего они пришли, были перенесены в центральный модуль миссии корабля для безопасного хранения. Экипаж не имел бы ни малейшего представления о том, кто они такие и что там делают. Ну что ж.

Незадолго до того, как он в последний раз отключился, корабль понял, что его двигатели тоже начали отказывать.

Корабль и его ожившая и сбитая с толку команда плыли под контролем вспомогательных автоматических систем, которые просто смотрели на землю, где бы они ни находились, и наблюдали за всем, что могли найти для наблюдения.

Незадолго до того, как он в последний раз отключился, корабль понял, что его двигатели тоже начали отказывать.

Корабль и его ожившая и сбитая с толку команда плыли под контролем вспомогательных автоматических систем, которые просто смотрели на землю, где бы они ни находились, и наблюдали за всем, что могли найти для наблюдения.

Незадолго до того, как он в последний раз отключился, корабль понял, что его двигатели тоже начали отказывать.

Корабль и его ожившая и сбитая с толку команда плыли под контролем вспомогательных автоматических систем, которые просто смотрели на землю, где бы они ни находились, и отслеживали все, что они могли найти для наблюдения.