リアルタイム分散システムの本質は何ですか？

Question

私は契約に足を踏み入れており、今日、請負業者のポジションについての最初の面接を受けました。私は合格しましたが、主にUI開発者であると言われましたが、バックエンドに必要なものの基本のみを取り上げたので、第2ラウンドの前に分散システムについて読む必要があります。

これまでの私のキャリアでは、リアルタイムが必要とされなかったポストオペレーションで働いてきました。残り日数が少ないので、どのトピックをカバーする必要がありますか？最初に彼の質問に答えることができ、一般的に分散システムではほぼ適切であると見なされていますか？

問題は、UIにほぼリアルタイムでデータを表示する方法でしたか？バックエンドで何をする必要がありますか？リアルタイムデータフィードの生産者/消費者パターンについて説明しました。彼はそれが好きだったが、彼は2回目の面接でもっと必要だと言った。

どんな助けでも本当にありがたいです、

andersoj · Accepted Answer

分散リアルタイムシステムの本質は何ですか？

分散リアルタイムシステムは、問題のドメインまたはソリューションのドメイン（あるいはその両方）によって課せられる2つの難しいプロパティのセットを構成します。

分散

Distributedシステムは、通信メカニズムを介して、多数の独立したコンピューティングエンティティをローカルプロパティにリンクします。結果として、アルゴリズムおよびその他の設計コンポーネントは、synchronyおよびfailure modelを考慮に入れる必要があります。分散コンピューティングの懸念に関する有用な要約（完全に客観的ではない）は、ドイツの分散コンピューティングの8つの落とし穴に含まれています。（この有用な説明を参照してください。）これらはすべて、（リアルタイムの）分散設計で検討するのに役立ちます。それぞれが、設計と実装に関する重要な懸念事項の出発点です。

ネットワークは信頼できます
レイテンシーはゼロです
帯域幅は無限大です
ネットワークは安全です
トポロジーは変わりません
管理者が1人います
輸送費はゼロです
ネットワークは均質です

リアルタイム

real-timeシステムは、操作完了の適時性がシステムの機能要件と正確性の尺度の一部であるシステムです。（私はこれを明確にするためにここでSOの質問を開きました。）実際には、ほぼすべてのシステムが「ソフト」リアルタイムと見なされる可能性があります。オペレーション。real-timeの用語は、が正しくないシステム用に、softまたはhardで修飾される場合があります。 時間の制約が満たされていない場合。上記の誤謬に要約されている懸念の多くは適時性と交差していることに注意してください。（リアルタイムタグウィキも参照してください）

RT（およびDRT）システムは、「決定論的」（または従来はハードリアルタイム）の一連の要件に存在することに注意してください。ただし、多くのシステムには非常に重要な時間制約がありますが、それでも決定論的ではありません。特にDRTシステムのコンテキストでは、アクティビティの概念をurgencyから分離することも役立ちます。アクティビティpriority。遅延と障害が現実的で重要な要因である大規模なシステムでは、適時性やその他の設計要件に影響を与えるコンピューティングおよび通信リソースの明示的な管理がより重要になり、これらの2つの次元が重要になります。

リアルタイムで分散して作成する

明示的な適時性の要件—要件とは何か、アクティビティにどのようにマッピングされるか、真のノード間適時性の要件、設計と実装で時間の制約を明示的に表す方法、障害を検出、報告、回復する方法？
時間同期—クロック同期を実現するための要件とメカニズムは何ですか？ Wiki on クロック同期 ;多くのアプリケーションは [〜＃〜] ntp [〜＃〜] ;のみを必要とします。より厳しい要件では、特別なハードウェア（ IRIG-B など）またはアプローチが必要になる場合があります。
同期要件—同期の前提条件とシステム同期の要件は何ですか？これはクロックの同期に関連していますが、同一ではありません。いくつかダグジェンセンからの正式なモデルについての考え ; 非同期システムおよび同期に関するウィキペディア; 部分的なイベントの順序に関するSOの質問 ;
デザインパターン—可動部品とは何ですか？また、それらは輸送全体でどのように関連していますか？（特に、これらの関係は適時性にどのように影響しますか？）
ミドルウェア—システムの分散された側面をどのようにエンコードしますか？例としては、リアルタイムCORBA（ここに OISの良いページ）または [〜＃〜] dds [〜＃〜] があります。
時間の制約—システムで時間の制約をどのように文書化し、測定し、実施しますか？
部分的な障害—リアルタイムシステムには通常、信頼性の要件があります。分散システムのユニークな側面の1つは、真のクラッシュ/通信障害または障害として扱われる必要のある適時性エラーのいずれかが原因で、「部分的」障害と呼ばれるクラス全体の障害が発生する可能性があることです。フェイルオーバーアプローチに関するSOの質問 ;
[〜＃〜] rtos [〜＃〜]—どのリアルタイムオペレーティングシステムが採用されますか？

いくつかの参考文献

DRTシステムのかなり伝統的なプレゼンテーションについては、 Kopetzの本をご覧ください。よりダイナミックな見方をするには、ジェンセンの作品と彼のウェブサイトをお勧めします。 Javaレルムでは、優れた "信頼性の高い分散プログラミング入門" を読むことをお勧めします。適時性の問題の完全なレルムには対応していませんが、部分的な問題には対応しています。特に明確な方法での失敗。

最近、（信頼性の低い）障害検出器の概念が有用な同期構造として登場し、DRTシステムの有用な理論的推論と実用的な定式化/設計/構築技術が可能になりました。このトピックに関する独創的な論文は リアルタイムのフォールトトレラントシステムに対する高速障害検出器の影響について 、Aguilera、Le Lann、およびTouegによるものです。この論文は重いそりですが、知的投資のすべてのオンスに報います。

Justin Ethier · Answer

大まかに言うと、バックエンドからフロントエンドにリアルタイムデータを取得する2つの基本的な方法があります。

プッシュ：メッセージを送信することにより、データをクライアントに「プッシュ」できます。私は過去にこれを使用してプロセス間メッセージをクライアントに送信し、更新が発生したことをUIに警告しました。これは情報を送信するための最速の方法ですが、複雑さがあります。たとえば、FlashやSilverlightなどを使用しない限り、（まだ）IPCメッセージをWebアプリケーションに送信することはできません。また、送信するメッセージが多すぎると、これらのメッセージを調整する必要があります。 UIの応答性を低下させます。ここで調べるテクノロジーには、MSMQ、TCP/IP、および同等のWCFがあります。
プル：UIは定期的にバックエンドからデータを要求できます。この方法の利点は、UIでのコーディングが簡単なことです。つまり、Xごとにデータソースをポーリングするだけです。ただし、明らかに欠点は、更新が発生してからアプリケーションがその更新を受信するまでに遅延があることです。これは、リアルタイム処理には受け入れられない場合があります。とにかく、このモデルでは、Webサービスを呼び出すか、データベースを呼び出すことができます。

もちろん、これは出発点にすぎません。どちらの方法も使用でき、データをクライアントにキャッシュすることもできます。すべて、アプリケーションのニーズによって異なります。