災害に強い言語は存在しますか?

StackOverflow https://stackoverflow.com/questions/1403915

質問

高い信頼性が必要なシステム サービスを作成する場合、次のような場合に備えて多くの「フェールセーフ」メカニズムを作成することになります。失われた通信 (DB との通信など)、電源が失われ、サービスが再起動された場合はどうなるでしょうか。ピースを拾い上げて正しい方法で続ける方法（そして、ピースを拾っている間に再び電源が落ちる可能性があることを覚えておいてください...）などなど

それほど複雑ではないシステムの場合、これに対応できる言語が非常に実用的であると想像できます。つまり、電源が切れても、いつでもその状態を記憶し、中断したところから続行する言語です。

これはまだ存在しますか?もしそうなら、どこで見つけられますか?そうでなければ、なぜこれが実現できないのでしょうか？重要なシステムにとっては非常に便利だと思われます。

追記DB 接続が失われた場合は、問題が発生したことを示しており、手動による介入が必要です。接続が復元されると、中断したところから続行されます。

編集：議論が終わったようなので、いくつかの点を追加させてください（質問に報奨金を追加できるまで待っている間）

Erlang の応答は現在最高の評価を得ているようです。私は Erlang のことは知っており、Armstrong (主な作成者) による実用的な本を読んだことがあります。それはすべて非常に素晴らしいことですが (関数型言語は再帰のせいで頭がクラクラしますが)、「フォールト トレラント」部分は自動的には得られません。それとは程遠い。Erlang は、プロセスを監視し、必要に応じてプロセスを再起動するための多くのスーパーバイザーやその他の方法論を提供します。ただし、これらの構造で動作するものを適切に作成するには、アーランのかなりの達人である必要があり、ソフトウェアをこれらすべてのフレームワークに適合させる必要があります。また、電力が低下した場合、プログラマもその部分を拾い上げて、次回プログラムを再起動するときに回復を試みる必要があります。

私が探しているのは、もっと単純なものです。

DB クエリを実行したり、それに基づいて操作したり、ファイル操作を実行したり、フォルダー操作を実行したりすることができる言語 (たとえば PHP などの単純な言語) を想像してください。

ただし、その主な機能は次のとおりです。電源が切れて再起動すると、中断したところから動作します (つまり、どこにあったかを記憶するだけでなく、変数の状態も記憶します)。また、ファイルコピーの途中で停止した場合も、適切に再開します。などなど

最後に重要なことですが、DB 接続が切断されて復元できない場合、言語は停止するだけで、人間の介入を求める信号 (おそらく syslog) を送り、中断したところから続行します。

このような言語があれば、多くのサービスのプログラミングがはるかに簡単になるでしょう。

編集：（すべてのコメントと回答から判断すると）そのようなシステムは存在しないようです。そして、それを正しく理解するのは（ほぼ？）不可能であるため、おそらく近い将来にはそうならないでしょう。

残念な....繰り返しになりますが、私は月に行くため、または誰かの心拍数を監視するためにこの言語 (またはフレームワーク) を探しているわけではありません。ただし、小規模な定期的なサービス/タスクでは、ボーダーケース (途中で電源障害が発生し、接続が切断され、復旧しないなど) を処理する大量のコードが常に必要になるため、ここで一時停止し、問題を修正します。 ..中断したところから続行するアプローチはうまく機能します。

(または、コメント投稿者の 1 人が指摘したように、(ビデオゲームのような) チェックポイント アプローチです。チェックポイントを設定します...プログラムが終了した場合は、次回ここで再起動します。)

授与された報奨金:誰もがそれは不可能だという結論に達していた土壇場で、Stephen C が、私が探していた属性を備えていると思われる napier88 を付属してくれました。これは実験的な言語ではありますが、それができることを証明しており、さらに研究する価値のあるものです。

.Net または別の VM に探している機能を追加するために、独自のフレームワーク (おそらく永続的な状態とスナップショットを含む) を作成することを検討しています。

皆様、ご意見と素晴らしい洞察をありがとうございました。

役に立ちましたか？

解決

Napier88と呼ばれる実験的な言語があり、（理論上）耐災害性のいくつかの属性があります。この言語は直交持続性をサポートしており、一部の実装では、これは計算全体の状態を含めるために拡張（拡張）されます。具体的には、Napier88ランタイムシステムが実行中のアプリケーションを永続ストアにチェックポイントすると、現在のスレッド状態がチェックポイントに含まれます。その後、アプリケーションがクラッシュし、正しい方法で再起動した場合、チェックポイントから計算を再開できます。

残念ながら、この種の技術が主流で使用できるようになる前に対処する必要がある多くの困難な問題があります。これらには、直交永続性のコンテキストでマルチスレッドをサポートする方法の把握、複数のプロセスが永続ストアを共有する方法の把握、および永続ストアのスケーラブルなガベージコレクションが含まれます。

そして、主流言語で直交持続性を実行するという問題があります。 Sunに関連する人々（Pjamaプロジェクト）によって行われたものを含め、JavaでOPを実行しようとする試みがありましたが、現在アクティブなものはありません。最近では、JDO / Hibernateアプローチがより好まれています。

Orthogonal Persistenceは、広い意味で実際には災害対策ではないことを指摘する必要があります。たとえば、次のことに対処できません：

  • 「外部」との接続などの再確立再起動後のシステム、
  • 保存されたデータの破損を引き起こすアプリケーションのバグ、または
  • チェックポイント間でシステムがダウンすることによるデータの損失。

それらについては、実用的な一般的な解決策があるとは思わない。

他のヒント

ソフトウェアトランザクショナルメモリ（STM）を不揮発性RAMと組み合わせることで、OPの改訂された質問をおそらく満たすでしょう。

ＳＴＭは、「トランザクション」、例えば、アトミック操作として効果的に行われる、またはまったく行われないアクションのセットを実装するための技術である。通常、STMの目的は、従来のlock-that-resourceプログラミングよりも理解しやすい方法で、高度に並列化されたプログラムが共有リソースを介して対話できるようにすることです。プログラミング。

基本的な考え方は単純です。「トランザクション」内のすべての読み取りと書き込みブロックが記録されます（なんとか！）;いずれかのトランザクションの終了時にこれらのセットで2つのスレッドが競合（読み取り/書き込みまたは書き込み/書き込みの競合）した場合、1つが勝者として選択されて続行され、もう1つのスレッドは状態を最初にロールバックしますトランザクションの再実行。

すべての計算がトランザクションであり、各トランザクションの開始（/終了）の状態が不揮発性RAM（NVRAM）に保存されていると主張した場合、電源障害はトランザクション障害として扱われ、「ロールバック」が発生します;。信頼できる方法で処理された状態からのみ計算が進みます。最近のNVRAMは、フラッシュメモリまたはバッテリバックアップで実装できます。プログラムには多くの状態があるため、多くのNVRAMが必要になる場合があります（最後のミニコンピューターのストーリーを参照）。または、コミットされた状態の変更をディスクに書き込まれたログファイルに書き込むこともできます。これは、ほとんどのデータベースと信頼できるファイルシステムで使用される標準的な方法です。

STMでの現在の質問は、潜在的なトランザクションの競合を追跡するのにどれくらいの費用がかかりますか？ STMを実装すると、マシンの速度がかなり低下する場合、人々はそのパフォーマンスを放棄するのではなく、既存のわずかに信頼性の低いスキームで生活します。これまでのところ話は良くありませんが、研究は早いです。

人々は一般にSTM用の言語を設計していません。研究目的のために、彼らはほとんど STMで強化されたJava（今年の6月のACMの通信の記事を参照してください）。 MSにはC＃の実験版があると聞きました。 Intelには、CおよびC ++の実験バージョンがあります。 ウィキペディアのページには長いリストがあります。そして関数型プログラミングの人たち いつものように、関数型プログラムの副作用のない性質がSTMを関数型言語で実装するのを比較的簡単にしていると主張しています。

正しく思い出せば、70年代には、プロセス（コード+状態）がマシンからマシンへと三回移動する分散オペレーティングシステムでかなり初期の作業がありました。こうしたシステムのいくつかは、ノード障害を明示的に許可し、障害が発生したノードのプロセスを別のノードの保存状態から再起動できると考えています。初期の主要な仕事は Dave Farberによる分散コンピューティングシステム。 70年代の言語の設計が一般的だったため、DCSに独自のプログラミング言語があったことを思い出しますが、その名前は覚えていません。 DCSがノードの障害と再起動を許可しなかった場合、研究システムのフォローはかなり確実だと思います。

編集：一見すると希望するプロパティを持っているように見える1996年のシステムは こちらに記載されています。 アトミックトランザクションの概念は、STMの背後にある考え方と一致しています。 （太陽の下ではそれほど新しいものではないことを証明するために行きます。）

補足：70年代に戻っても、コアメモリは依然として重要でした。コアは磁気であり、電源障害が発生しても不揮発性であり、多くのミニコンピューター（およびメインフレーム）にはソフトに通知する電源障害割り込みがありました。

私が知っていることから＆＃185 ;、 Ada は安全性が重視される場合によく使用されます（フェイルセーフ）システム。

  

Adaは元々   組み込みおよびリアルタイムシステム。

     

Adaの注目すべき機能は次のとおりです。   強力な型付け、モジュール化メカニズム   （パッケージ）、ランタイムチェック、   並列処理（タスク）、例外   処理、およびジェネリック。 Ada 95が追加されました   オブジェクト指向のサポート   動的を含むプログラミング   ディスパッチ。

     

Adaは、実行時チェックを順番にサポートします   へのアクセスから保護するため   未割り当てメモリ、バッファオーバーフロー   エラー、オフバイワンエラー、配列   アクセスエラー、およびその他の検出可能   バグ。これらのチェックはで無効にすることができます   ランタイム効率の関心、   多くの場合、効率的にコンパイルできます。   また、支援する機能が含まれています   プログラム検証。

     

これらについて   理由は、エイダが広く使用されている   重要なシステム、異常がある場合   非常に深刻になる可能性があります   結果、すなわち偶発的な死   またはけが。システムの例   Adaには、航空電子工学、武器などが使用されます   システム（熱核を含む   武器）、宇宙船。

Nバージョンのプログラミングも役立つ参考資料を提供します。

＆＃185; これは基本的に、組み込みのセーフティクリティカルなソフトウェアを作成する知人の1人です

あなたが説明している言語機能が実現可能であるとは思わない。

そして、その理由は、一般的な障害モードと一般的な障害モード、およびそれらから回復する方法を定義するのが非常に難しいからです。サンプルアプリケーションについて少し考えてみてください-何らかのロジックとデータベースアクセスを備えたWebサイト。また、電源のシャットダウンとその後の再起動を検出し、何らかの方法で回復できる言語があるとします。問題は、言語の回復方法を知ることができないことです。

アプリがオンラインブログアプリケーションであるとします。その場合、失敗したポイントから続行するだけで十分で、すべて問題ありません。ただし、オンラインバンクについても同様のシナリオを検討してください。突然、同じポイントから継続するのはもはや賢くありません。たとえば、アカウントからいくらかのお金を引き出しようとしていて、チェック直後に引き出しが実行される前にコンピューターが死に、1週間後に戻った場合、アカウントが負になりました。

つまり、単一の正しいリカバリ戦略はないため、これは言語に実装できるものではありません。言語にできることは、何か悪いことが起こったときに知らせることですが、ほとんどの言語はすでに例外処理メカニズムでそれをサポートしています。残りについては、アプリケーションデザイナーが検討する必要があります。

フォールトトレラントアプリケーションの設計を可能にする多くのテクノロジがあります。データベーストランザクション、永続メッセージキュー、クラスタリング、ハードウェアホットスワップなど。しかし、それはすべて具体的な要件と、エンドユーザーがどれだけ支払いを望んでいるかに依存します。

「フォールトトレランス」と呼ばれるこのような取り組みの大部分は、ソフトウェアではなくハードウェア。

これの極端な例は、タンデムで、その「ノンストップ」マシンには完全な冗長性があります。

ハードウェアレベルでフォールトトレランスを実装するのは魅力的です。ソフトウェアスタックは通常、さまざまなプロバイダーから提供されたコンポーネントで作成されるためです。高可用性ソフトウェアアプリケーションは、オペレーティングシステムの上に、不安定で、明らかに壊れやすいハードウェアデバイスドライバーを使用しています。

ただし、言語レベルでは、ほとんどすべての言語に適切なエラーチェック機能があります。ただし、RAII、例外、制約、およびトランザクションであっても、これらのコードパスは正しくテストされず、複数障害シーンで一緒にテストされることはほとんどなく、通常はバグが隠すエラー処理コードで一緒にテストされます。そのため、言語自体よりもプログラマーの理解、規律、トレードオフが重要です。

これにより、ハードウェアレベルのフォールトトレランスに戻ります。データベースリンクの失敗を回避できる場合は、アプリケーションで危険なエラー処理コードを実行することを回避できます。

いいえ、災害対策言語は存在しません。

編集：

災害対策は完全を意味します。未知の不特定の予期せぬ状況を論理的に解決するために何らかの知性を適用するプロセスのイメージを思い起こさせます。プログラミング言語でこれを行う方法はありません。プログラマーとして、プログラムがどのように失敗し、どのように回復するかを理解できない場合、プログラムもそうすることができません。

ITの観点からの災害は非常に多くの方法で発生する可能性があるため、1つのプロセスでこれらのさまざまな問題をすべて解決することはできません。何かがうまくいかない可能性のあるすべての方法に対処するために言語を設計できるという考えは、単に間違っています。ハードウェアからの抽象化により、多くの問題はプログラミング言語で対処する意味がありません。まだ「災害」です。

もちろん、問題の範囲を制限し始めると、その後、ソリューションの開発について話し始めることができます。したがって、災害対策について話すのをやめて、予期しない電力サージから回復することについて話し始めると、おそらく、スタックのこのような高レベル。ただし、これを現実的な実装に限定すると、言語が非常に具体的になるため、言語としては面白くないという予測を立てます。つまり、私のスクリプト言語を使用して、予期しない電力サージやネットワーク接続の喪失から回復するバッチプロセスを一晩実行します（ある程度の人的支援が必要です）。これは私の心に訴えるビジネスケースではありません。

誤解しないでください。このスレッド内にはいくつかの優れた提案がありますが、私の考えでは、それらはリモートで災害に近づいても何にもなりません。

不揮発性メモリから構築されたシステムを検討してください。プログラムの状態は常に維持され、プロセッサが任意の時間停止した場合、再起動時に残ったポイントから再開します。したがって、プログラムは電源障害に耐えられる範囲で「災害対策」です。

これは、ソフトウェアトランザクションメモリ、および「フォールトトレランス」などについて話しているときに他の投稿で概説されているように、完全に可能です。完全にノイマン建築も。

このような2つの個別のシステムから構築されたシステムを想像してください。わかりやすい例では、1つはデータベースサーバーで、もう1つはオンラインバンキングWebサイトのアプリケーションサーバーです。

一方は一時停止する必要がありますが、もう一方は何をしますか？同僚の突然の不在をどのように処理しますか？

これは言語レベルで処理できますが、それは多くのエラー処理などを意味し、それを正しく行うには扱いにくいコードです。マシンはチェックポイントされていないが、言語は問題を検出し、プログラマーに対処するように依頼する現在の場所よりも、それはましです。

一時停止することもあります。ハードウェアレベルでは、それらを結び付けることができ、電力の観点からは1つのシステムになります。しかし、それはほとんど良い考えではありません。バックアップシステムなどを備えたフォールトトレラントアーキテクチャにより、可用性が向上します。

または、2台のマシン間で永続メッセージキューを使用できます。ただし、ある時点でこれらのメッセージは処理され、その時点では古すぎる可能性があります。そのような状況で何をすべきかを実際に機能させることができるのはアプリケーションロジックのみであり、プログラマーに再び委任する言語に戻っています。

したがって、現在の形では、無停電電源装置、すぐに使えるホットバックアップサーバー、ホスト間の複数のネットワークルートなど、災害対策が優れているようです。そして、ソフトウェアがバグであることを願うだけです。無料！

正確な答え:

エイダ そして スパーク 最大限の耐障害性を実現し、考えられるすべてのバグを実行時ではなくコンパイル時に移動するように設計されています。Ada は米国国防総省によって軍事および航空システム向けに設計され、飛行機などの組み込みデバイス上で実行されます。Spark はその子孫です。米国の初期の宇宙計画で使用されたもう 1 つの言語があります。HAL/S は、宇宙線によるハードウェア障害やメモリ破損の処理に特化したものです。

実際的な答え:

Ada/Spark をコーディングできる人に会ったことがありません。ほとんどのユーザーにとって最良の答えは、自動フェイルオーバーとサーバーのクラスタリングを備えた DBMS 上の SQL バリアントです。整合性チェックにより安全性が保証されます。T-SQL や PL/SQL のようなものは、完全なトランザクション セキュリティを備えており、チューリング完全であり、問​​題に対してかなり耐性があります。

これより良い答えがない理由:

パフォーマンス上の理由から、耐久性を提供することはできません。 毎 プログラムの操作。実行すると、処理は最速の不揮発性ストレージの速度まで遅くなります。CPU キャッシュや RAM よりも何もかもがはるかに遅いため、パフォーマンスはせいぜい 1,000 倍または 100 万倍低下します。

これは、Core 2 Duo CPU から古代の 8086 CPU に移行するのと同じで、1 秒あたり最大で 200 回の操作を実行できます。ただし、これはさらに遅くなります。

電源の再投入やハードウェア障害が頻繁に発生する場合は、DBMS などを使用して、すべてのインスタンスに対して ACID を保証します。 重要 手術。または、高速な不揮発性ストレージ (フラッシュなど) を備えたハードウェアを使用します。これでもかなり遅いですが、処理が単純であれば、これで問題ありません。

あなたの言語はせいぜい、コンパイル時にバグの安全性を適切にチェックし、クラッシュするのではなく例外をスローします。例外処理は、現在使用されている言語の半数の機能です。

Veritas、SunのHA、IBMのHACMPなど、いくつかの商業的に利用可能なフレームワークがあります。 自動的にプロセスを監視し、障害が発生した場合に別のサーバーでそれらを開始します。

HPのタンデムノンストップレンジのような高価なハードウェアもあり、内部ハードウェア障害に耐えることができます。

しかし、ソフトウェアは人々によって構築され、人々はそれを誤解するのが大好きです。 IBMs MVSに同梱されているIEFBR14プログラムの注意書きを検討してください。基本的には、プログラムを実際に実行せずにJCLの宣言ビットを発生させるNOPダミープログラムです。これは元のソースコード全体です：-

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

これ以上簡単なコードはありませんか？このプログラムは長寿命の間に実際にバグバグレポートを蓄積しており、現在はバージョン4です。

3行のコードに対する1つのバグ。現在のバージョンは元のサイズの4倍です。

エラーは常に忍び込みます。エラーから回復できることを確認してください。

この質問により、このテキストを投稿せざるを得ませんでした

（Douglas AdamsのHGTTGから引用：）

クリック、ハム。

巨大な灰色のグレブロン偵察船は静かに黒い隙間を移動しました。それは驚くほど息をのむような速度で移動していましたが、10億個の遠くにある星がまったく動いていないというかすかな背景を背景に現れました。それは、輝かしい夜の無限の粒度に対して凍結したただの暗い斑点でした。

船上では、何千年もの間、すべてが暗く、静かでした。

クリック、ハム。

少なくとも、ほとんどすべて。

クリック、クリック、ハム。

クリック、ハム、クリック、ハム、クリック、ハム。

クリック、クリック、クリック、クリック、クリック、ハム。

うーん。

低レベルの監視プログラムは、船の準不気味なサイバーブレインの奥深くでやや高いレベルの監視プログラムを起動し、クリックするたびにハムになると報告しました。

より高いレベルの監視プログラムは、何を得るべきかを尋ね、低レベルの監視プログラムは、正確に覚えていないが、それはおそらく一種の遠い満足したため息だと思いましたね？このハムが何であるか知らなかった。クリック、ハム、クリック、ハム。それがすべてだった。

高レベルの監督プログラムはこれを考慮し、それを好まなかった。それは低レベルの監視プログラムに正確に何を監視しているかを尋ね、低レベルの監視プログラムはそれが覚えていないと言った。失敗します。エラールックアップテーブルを調べようとしましたが、見つかりませんでした。そのため、上位レベルの監視プログラムに問題を警告していました。

高レベルの監視プログラムは、独自のルックアップテーブルの1つを参照して、低レベルの監視プログラムが何を監視するのかを調べました。

ルックアップテーブルが見つかりませんでした。

奇数。

もう一度見ました。エラーメッセージのみが表示されました。エラーメッセージルックアップテーブルでエラーメッセージを検索しようとしましたが、それも見つかりませんでした。これをすべて繰り返している間、数ナノ秒が経過しました。次に、セクター機能スーパーバイザーを起動しました。

セクター機能スーパーバイザーがすぐに問題に直面しました。問題を抱える監督エージェントと呼ばれています。休眠状態にあった2番目の仮想回路の数百万分の1以内に、何年もの間、何世紀もの間、船全体に生命が広がっていました。どこかで何かがひどく間違っていましたが、どの監視プログラムもそれが何であるかを知ることができませんでした。すべてのレベルで、重要な指示が欠落しており、重要な指示が欠落していることを発見した場合の対処方法に関する指示も欠落していました。

ソフトウェアの小さなモジュール＆＃8212;エージェント＆＃8212;論理的な経路、グループ化、コンサルティング、再グループ化を通じて急増しました。彼らはすぐに、船の記憶が中央ミッションモジュールにまでさかのぼって、ぼろぼろになっていたことを確認しました。質問の量は、それが何が起こったかを決定することができませんでした。中央のミッションモジュール自体も破損しているようです。

これにより、問題全体の処理が非常に簡単になりました。中央ミッションモジュールを交換します。別のもの、バックアップ、元の完全な複製がありました。安全上の理由から、元のバックアップとそのバックアップの間にリンクがまったくなかったため、物理的に交換する必要がありました。中央のミッションモジュールが交換されると、それ自体がシステムの残りの部分の再構築を詳細に監視でき、すべてうまくいきます。

ロボットは、バックアップされた中央ミッションモジュールを、守られているシールドされた強力な部屋から船のロジックチャンバーに持ち込み、設置するよう指示されました。

これにはt

既存のオープンソースのインタープリター言語を使用して、これらの機能の一部を含めるように実装を調整できるかどうかを確認してください。 PythonのデフォルトのC実装は、「処理」に使用される内部ロック（GIL、グローバルインタープリターロックと呼ばれる）を埋め込みます。 n個のVM命令ごとに交互に実行することによるPythonスレッド間の同時実行性。おそらく、この同じメカニズムにフックして、コードの状態をチェックポイントすることができます。

マシンの電源が切れたときに中断したところからプログラムを続行するには、状態をどこかに保存する必要があるだけでなく、OSは「知る」必要もあります。再開します。

＆quot; hibernate＆quot;を実装すると思います。言語の機能を実行することはできますが、それがバックグラウンドで絶えず行われるため、悪いことが起こった場合に備えて準備ができています、私の意見では、OSの仕事のように聞こえます。

  

ただし、主な機能は次のとおりです。電源が切れ、再起動すると、中断した場所から再開します（したがって、場所が記憶されているだけでなく、変数の状態も記憶されます）。また、ファイルコピーの途中で停止した場合も、適切に再開します。などなど

     

... ...

     

過去にアーランを見たことがあります。どんなに優れたフォールトトレラント機能なのか...停電を乗り越えられません。コードが再起動したら、断片を拾わなければなりません

そのような技術が存在した場合、私はそれについて非常に興味があります。とは言っても、Erlangソリューションには複数のノードがあり、理想的には異なる場所にあるため、1つの場所がダウンした場合、他のノードがスラックを拾うことができます。すべてのノードが同じ場所にあり、同じ電源にある場合（分散システムではあまり良い考えではありません）、コメントのフォローアップで述べたように、運が悪いでしょう。

Microsoft Robotics Groupは、質問に適用できると思われる一連のライブラリを導入しました。

  

並行性と調整とは   ランタイム（CCR）？

     

同時実行性と調整ランタイム   （CCR）は高度な並行性を提供します   に基づくプログラミングモデル   強力なメッセージパッシング   オーケストレーションプリミティブの有効化   データと作業の調整なし   手動スレッディング、ロックの使用、   セマフォなど。CCRは   マルチコアおよびコンカレントの必要性   提供することにより、アプリケーション   容易にするプログラミングモデル   非同期操作の管理、   並行性の処理、悪用   並列ハードウェアと部分的な処理   失敗。

     

分散ソフトウェアとは   サービス（DSS）？

     

分散ソフトウェアサービス（DSS）   軽量で状態指向の   結合するサービスモデル   代表状態転送（REST）   正式な構成で   イベント通知アーキテクチャ   システムレベルのアプローチを可能にします   アプリケーションの構築。 DSSでは、   サービスはリソースとして公開されます   両方にアクセス可能です   プログラムおよびUI用   操作。サービスを統合することにより   構成、構造化状態   操作、およびイベント通知   データの分離により、DSSは   高度に書くための統一モデル   観測可能、疎結合   単一ノードで実行されているアプリケーション   またはネットワーク経由で。

回答のほとんどは汎用言語です。組み込みデバイスで使用されている、より専門的な言語を調べてください。ロボットは考える良い例です。停電から回復したときにロボットに何をしたい、または期待しますか？

組み込みの世界では、これはウォッチドッグ割り込みとバッテリーバックアップRAMを介して実装できます。私自身もそのように書きました。

災害の定義に応じて、この責任を言語に委任するのは「難しい」から「実際に不可能」までさまざまです。

その他の例としては、各ステートメントの実行後にアプリケーションの現在の状態をNVRAMに永続化することが含まれます。これは、コンピューターが破壊されない限り機能します。

新しいホストでアプリケーションを再起動すると、言語レベルの機能はどのように知るのでしょうか？

そして、アプリケーションをホストに復元する状況で-かなりの時間が経過し、以前に行われた仮定/チェックが無効になった場合はどうなりますか？

T-SQL、PL / SQL、およびその他のトランザクション言語は、おそらく「災害対策」に近づきます-成功する（データが保存される）か、そうでないかのどちらかです。トランザクションの分離を無効にすることを除けば、「不明」な状態になることは困難です（しかし、実際に一生懸命やるなら不可能ではないでしょう）。

SQLミラーリングなどの手法を使用して、トランザクションがコミットされる前に書き込みが少なくとも2つの場所に同時に保存されるようにすることができます。

安全（コミット）になるたびに状態を保存する必要があります。

質問を正しく理解している場合、特定のアルゴリズム（つまり、プログラムと環境によって提供されるすべての回復オプション）が（任意の数の回復/再起動）。

これが正しい場合、停止の問題を参照します：

  

プログラムの説明と有限の入力が与えられたら、その入力が与えられると、プログラムの実行を終了するか、永久に実行するかを決定します。

あなたの質問を停止問題のインスタンスとして分類することは、その言語を「災害対策」にしたいという理想を考えると公平だと思います。 -つまり、「完全性」を付与します。欠陥のあるプログラムや混oticとした環境へ。

この分類により、環境、言語、プログラムのあらゆる組み合わせが「プログラムと有限入力」まで削減されます。

あなたが私に同意するなら、あなたは停止する問題が決定不能であることを読むことに失望するでしょう。したがって、「災害対策」はありません。言語、コンパイラ、または環境がそうであることが証明される可能性があります。

ただし、さまざまな一般的な問題の回復オプションを提供する言語を設計することは完全に合理的です。

停電の場合..私のように聞こえます：「あなたの唯一のツールがハンマーの場合、すべての問題は釘のように見えます」

プログラム内の電源障害の問題は解決しません。バックアップ電源、バッテリーなどでこの問題を解決します。

障害のモードがハードウェア障害に限定されている場合、 VMwareフォールトトレランスあなたが望む同様のものを主張します。複数のクラスターにわたって仮想マシンのペアを実行し、vLockstepと呼ばれるものを使用して、プライマリvmはすべての状態をリアルタイムでセカンダリvmに送信するため、プライマリエラーが発生した場合、実行は透過的にセカンダリに切り替わります。

これは、ハードウェア障害よりも一般的な通信障害の解決にはならないだろうと思います。深刻な高可用性を実現するには、Birmanのプロセスグループアプローチ（ pdf形式の紙、または本信頼性の高い分散システム：テクノロジー、Webサービス、およびアプリケーション）。

最も近い近似はSQLのようです。ただし、実際には言語の問題ではありません。これは主にVMの問題です。これらのプロパティを持つJava VMを想像できます。それを実装することは別の問題です。

アプリケーションのチェックポイント設定により、高速で汚れた近似値が得られます。 「いつでも死ぬ」を失います。プロパティですが、かなり近いです。

回復のための基本的な間違いは、顕著なデザインの問題ではないと思います。環境に対して排他的に責任を課すことは、一般的に内部故障に耐えられない脆弱なソリューションにつながります。

私なら、信頼性の高いハードウェアに投資し、あらゆる状態から自動的に回復できるようにソフトウェアを設計しました。サンプルごとに、データベースセッションのメンテナンスは、十分に高いレベルのAPIによって自動的に処理される必要があります。手動で再接続する必要がある場合は、間違ったAPIを使用している可能性があります。

他の人が指摘しているように、現代のRDBMSシステムに組み込まれた手続き言語は、エキゾチックな言語を使用せずに取得するのに最適です。

VMは一般に、この種の目的のために設計されています。 VMベンダー（vmware..et al）APIを使用して、必要に応じてアプリケーション内の定期的なチェックポイントを制御できます。

VMWareには特に、すべてを記録し、特定の時点での再生を可能にする再生機能（拡張実行記録）があります。このアプローチでは明らかにパフォーマンスが大幅に低下しますが、要件を満たします。ディスクドライブにバッテリバックアップ式の書き込みキャッシュがあることを確認するだけです。

ほとんどの場合、Java仮想マシン内で実行されるJavaバイトコードの同様のソリューションを見つけることができます。 GoogleフォールトトレラントJVMおよび仮想マシンのチェックポイント。

プログラム情報を保存したい場合、どこに保存しますか？

保存する必要があります。ディスクに。しかし、これはディスクが故障した場合には役に立ちませんので、すでに耐災害性はありません。

保存した状態で特定のレベルの粒度のみを取得します。 tihsのようなものが必要な場合、おそらく最適なアプローチは、アトミック操作を構成する要素に関して粒度レベルを定義し、各アトミック操作の前にデータベースに状態を保存することです。その後、そのレベルのアトミック操作のポイントに復元できます。

これを自動的に行う言語は知りません。状態をセカンダリストレージに保存するコストが非常に高いためです。したがって、粒度のレベルと効率の間にはトレードオフがあり、任意のアプリケーションで定義するのは困難です。

  • 最初に、フォールトトレラントアプリケーションを実装します。 8つの機能と5つの障害モードがある場合、40のすべての組み合わせが意図したとおりに機能することを実証するために分析とテストを行いました（特定の顧客の要望どおり：2つは同意しません）。 >
  • 次に、サポートされているフォールトトレラント機能のセットの上にスクリプト言語を追加します。それは可能な限りステートレスに近い必要があるため、ほぼ確実に非チューリング完全な何か。
  • 最後に、各障害モードに適応したスクリプト言語の状態の復元と修復を処理する方法を見つけます。

もちろん、これはロケット < a href = "http://www.aiaa.org/spaceops2006/presentations/56767.ppt" rel = "nofollow noreferrer"> science 。

Windows Workflow Foundationが問題を解決する場合があります。 .Netベースであり、状態とアクションを含むワークフローとしてグラフィカルに設計されています。

データベースへの永続化を可能にします（自動またはプロンプトが表示された場合）。状態/アクション間でこれを行うことができます。これにより、ワークフローのインスタンス全体がデータベースにシリアル化されます。いくつかの条件のいずれかが満たされると、再水和され、実行が継続されます（特定の時間、プログラムによって再水和され、イベントの発生など）

WWFホストが起動すると、永続性データベースをチェックし、そこに保存されているワークフローを復元します。その後、永続化のポイントから実行を続けます。

ワークフローの側面を使用したくない場合でも、おそらく永続化サービスを使用できます。

あなたのステップがアトミックである限り、これは十分なはずです-特に、UPSがあると推測しているので、UPSイベントを監視し、電源の問題が検出された場合、永続性を強制できます。

問題を解決しようとしていた場合、トランザクションですべてのデータベース対話を行うデーモン（おそらくCで）を作成して、中断された場合に不正なデータが挿入されないようにします。次に、システムに起動時にこのデーモンを起動させます。

明らかに、CでのWebの開発は、スクリプト言語で行うよりもかなり遅くなりますが、パフォーマンスが向上し、安定します（もちろん、適切なコードを記述した場合：）。

現実的には、Ruby（またはPHPなど）で記述し、Delayed Job（またはcronまたは任意のスケジューラ）のようなものを頻繁に実行します。 p>

意味のある希望。

障害回復の概念は、ほとんどの場合、ビジネス上の問題であり、ハードウェアや言語の問題ではありません。

例を挙げます。1つのUI層と1つのサブシステムがあります。 サブシステムの信頼性はそれほど高くありませんが、UI層のクライアントは、それが存在するかのように認識しなければなりません。

今、あなたのサブシステムが何らかの形でクラッシュすることを想像してください。あなたが想像する言語は、このサブシステムに応じてUI層をどのように処理するかを考えられると本当に思いますか？

サブシステムが信頼できないことをユーザーは明示的に認識してください。メッセージングを使用して高い信頼性を提供する場合、クライアントはそれを認識しなければなりません2週間後）。彼がこれに気づく必要がある場合、これはそれを隠すためのアブストラクトが最終的にリークすることを意味します。

クライアントとは、エンドユーザーを意味します。また、UIはこの信頼性を反映し、隠さないようにする必要があります。その場合、コンピューターはあなたのために考えることはできません。

＆quot;だから、電源が切れても、いつでもその状態を記憶する言語で、電源が切れたところから継続します。＆quot;

＆quot;中断したところから継続します＆quot; は、多くの場合、正しい回復戦略ではありません。世界の言語や環境は、特定の障害から自動的に回復する方法を推測しようとしません。最善の方法は、ビジネスロジックに干渉しない方法で独自の復旧戦略を作成するためのツールを提供することです。例：

  • 例外処理（高速で失敗しても状態の一貫性を確保するため）
  • トランザクション（未完了の変更をロールバックするため）
  • ワークフロー（自動的に呼び出される回復ルーチンを定義するため）
  • ロギング（障害の原因を追跡するため）
  • AOP /依存性注入（上記のすべてを行うためにコードを手動で挿入する必要を避けるため）

これらは非常に汎用的なツールであり、多くの言語と環境で利用できます。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top