Подтвердить что ты не робот

Существует ли язык, защищенный от стихийных бедствий?

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

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

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

p.s. В случае потери соединения с БД, это будет означать, что возникла проблема, и требуется ручное вмешательство. В тот момент, когда соединение будет восстановлено, оно будет продолжено там, где оно остановилось.

EDIT: Поскольку обсуждение, кажется, скончалось, позвольте мне добавить несколько моментов (ожидая, прежде чем я смогу добавить щедрость на вопрос)

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

То, что я ищу, намного проще:

Представьте себе язык (такой же простой, как PHP), где вы можете делать такие вещи, как запросы БД, действовать на нем, выполнять манипуляции с файлами, выполнять манипуляции с папками и т.д.

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

И последнее, но не менее важное: если соединение с БД падает и не может быть восстановлено, язык просто останавливается и сигналы (возможно, syslog) для вмешательства человека, а затем продолжаются там, где это было остановлено.

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

EDIT: Кажется (судя по всем комментариям и ответам), что такой системы не существует. И, вероятно, не будет в ближайшем обозримом будущем из-за того, что он (рядом?) Не может быть прав.

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

(или подход контрольной точки, как указывал один из комментаторов (например, в видеоигре). Установите контрольную точку.... и если программа умрет, перезапустите здесь в следующий раз.)

Награда за награду: В последнюю возможную минуту, когда все пришли к выводу, что это невозможно сделать, Стивен C приходит с napier88, который, похоже, имеет атрибуты, которые я искал. Хотя это экспериментальный язык, он доказывает, что это можно сделать, и это то, что стоит исследовать больше.

Я буду искать создание собственной фреймворка (с постоянным состоянием и моментальными снимками), чтобы добавить функции, которые я ищу в .Net или другой виртуальной машине.

Всем спасибо за вклад и большие идеи.

4b9b3361

Ответ 1

Существует экспериментальный язык под названием Napier88, который (в теории) имеет некоторые признаки того, что он является бедствием. Язык поддерживает Orthogonal Persistence, и в некоторых реализациях это расширяет (расширяет), чтобы включить состояние всего вычисления. В частности, когда система времени выполнения Napier88 проверяет запущенное приложение на постоянное хранилище, текущее состояние потока будет включено в контрольную точку. Если приложение затем разбилось и вы перезапустили его правильно, вы можете возобновить вычисление с контрольной точки.

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

И есть проблема выполнения ортогональной стойкости в основном языке. Были попытки сделать OP на Java, в том числе и теми, которые были сделаны людьми, связанными с Sun (проект Pjama), но в настоящий момент нет ничего активного. В наши дни более популярны подходы JDO/Hibernate.


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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

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

EDIT: система 1996 года, которая появляется с первого взгляда, чтобы обладать желаемыми свойствами документировано здесь. Его концепция атомных транзакций согласуется с идеями STM. (Идет, чтобы доказать, что под солнцем нет ничего нового).

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

Ответ 4

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

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

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

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

Для этих причины, Ада широко используется в критические системы, где любая аномалия может привести к очень серьезным последствия, то есть случайная смерть или травмы. Примеры систем, в которых Используется Ada: авионика, оружие систем (включая термоядерные оружие) и космических аппаратов.

Программирование N-версии также может дать вам полезное фоновое чтение.

¹Что в основном один знакомый, который пишет встроенное безопасное для безопасности программное обеспечение

Ответ 5

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

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

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

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

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

Ответ 6

Большинство таких усилий, называемых " отказоустойчивость, - это аппаратное обеспечение, а не программное обеспечение.

Крайним примером этого является Tandem, чьи "безостановочные" машины имеют полную избыточность.

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

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

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

Ответ 7

Нет, язык, защищенный от стихийных бедствий, не существует.

Edit:

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

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

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

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

Ответ 8

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

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

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

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

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

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

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

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

Ответ 9

Точный ответ:

Ada и SPARK были разработаны для максимальной отказоустойчивости и для перемещения всех ошибок, которые могут быть использованы для компиляции, а не для времени выполнения. Ада была разработана Департаментом обороны США для военных и авиационных систем, работающих на встроенных устройствах в таких вещах, как самолеты. Искра - ее потомок. Там был еще один язык, используемый в ранней космической программе США, HAL/S, предназначенный для обработки отказа аппаратного обеспечения и повреждения памяти из-за космических лучей.


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

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


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

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

Это был бы эквивалент перехода от CPU Core 2 Duo к древнему процессору 8086 - в большинстве случаев вы могли бы выполнять пару сотен операций в секунду. Кроме того, это будет даже SLOWER.

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

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

Ответ 10

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

(Его цитируют из HGTTG ​​от Дугласа Адамса:)


Нажмите, гул.

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

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

Нажмите, гул.

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

Нажмите, нажмите, гул.

Нажмите, гул, нажмите, гул, нажмите, гул.

Нажмите, нажмите, щелкните, щелкните, щелкните, нажмите.

Хммм.

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

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

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

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

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

Нечетный.

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

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

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

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

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

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

Это обеспечило первый важный ключ к тому, что это было, что было неправильно.

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

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

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

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

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

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

"Твоя!!!!!!!!!!!!!!! год миссия -!!!!!!!!!!!!!!!!!!!!,!!!!!!!!!!!!!!!!!!!!, земля!!!!!!!!!!!!!!! безопасное расстояние!!!!!!!!!!..................., земля............... монитор.!!!!!!!!!!!!!!!..."

Все остальное было полным мусором.

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

Он должен также оживить весь свой экипаж.

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

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

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

Ответ 11

Попробуйте использовать существующий язык с открытым исходным кодом и посмотрите, можете ли вы адаптировать его реализацию, чтобы включить некоторые из этих функций. Реализация Cython по умолчанию для Python включает встроенную блокировку (называемую GIL, Global Interpreter Lock), которая используется для "обработки" concurrency среди потоков Python путем поочередования каждой инструкции "n" VM. Возможно, вы можете подключиться к этому же механизму, чтобы проверить состояние кода.

Ответ 12

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

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

Ответ 13

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

......

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

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

Ответ 14

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

Что такое Concurrency и координация Runtime (CCR)?

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

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

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

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

Ответ 15

В встроенном мире это может быть реализовано с помощью прерывания сторожевого таймера и оперативной памяти с батарейным питанием. Я написал такое.

Ответ 16

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

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

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

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

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

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

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

Ответ 17

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

Если это правильно, я хотел бы обратиться к проблеме остановки:

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

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

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

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

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

Ответ 18

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

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

Ответ 19

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

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

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

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

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

Thats 1 ошибка до трех строк кода, текущая версия в четыре раза превышает размер оригинала.

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

Ответ 20

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

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

Ответ 21

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

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

Ответ 22

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

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

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

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

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

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

Ответ 23

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

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

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

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

Ответ 24

  • Во-первых, выполните отказоустойчивое приложение. Один, где, где, если у вас есть 8 функций и 5 режимов отказа, вы провели анализ и тест, чтобы продемонстрировать, что все 40 комбинаций работают по назначению (и по желанию конкретного клиента: два из них, скорее всего, не согласятся).
  • второй, добавьте язык сценариев поверх поддерживаемого набора отказоустойчивых функций. Он должен быть как можно ближе к апатриду, так что почти наверняка что-то не-Тьюринга завершено.
  • наконец, рассмотрим, как обрабатывать восстановление и восстановление состояния языка сценариев, адаптированного к каждому режиму отказа.

И да, это в значительной степени ракета science.

Ответ 25

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

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

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

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

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

Ответ 26

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

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

Реально, я бы записал его в Ruby (или PHP или что-то еще) и что-то вроде Delayed Job (или cron или любого другого планировщика) запускает его каждый раз так часто, потому что мне не понадобится обновлять когда-либо тактовый цикл.

Надеюсь, что это имеет смысл.

Ответ 27

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

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

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

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

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

Ответ 28

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

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

  • Обработка исключений (для быстрого сбоя и обеспечения согласованности состояния)
  • Транзакции (для отмены незавершенных изменений)
  • Рабочие процессы (для определения процедур восстановления, которые вызываются автоматически)
  • Ведение журнала (для отслеживания причины сбоя)
  • AOP/инъекция зависимостей (во избежание необходимости вручную вставлять код для выполнения всего вышеперечисленного)

Это очень общие инструменты и доступны во множестве языков и сред.