私は契約に足を踏み入れており、今日、請負業者のポジションについての最初のラウンドの面接を受けました。私は合格しましたが、主にUI開発者であると言われましたが、バックエンドに必要なものの基本のみを取り上げたので、第2ラウンドの前に分散システムについて読む必要があります。
これまでの私のキャリアでは、リアルタイムが必要とされなかったポストオペレーションで働いてきました。あと数日しか残っていないので、カバーする必要のある重要なトピックは何ですか？最初に彼の質問に答えることができ、一般的に分散システムではほぼ適切であると見なされていますか？
問題は、UIにほぼリアルタイムでデータを表示する方法でしたか？バックエンドで何をする必要がありますか？リアルタイムデータフィードのプロデューサー/コンシューマーパターンについて説明しました。彼はそれが好きだったが、彼は2回目のインタビューでもっと必要だと言った。
どんな助けでも本当にありがたいです、
分散リアルタイムシステムは、問題のドメインまたはソリューションのドメイン（あるいはその両方）によって課せられる2つの難しいプロパティのセットを構成します。
分散システムは、通信メカニズムを介して、多数の独立したコンピューティングエンティティをローカルプロパティにリンクします。結果として、アルゴリズムおよびその他の設計コンポーネントは、同期性と障害モデルを考慮に入れる必要があります。分散コンピューティングの懸念に関する有用な要約（完全に客観的ではない）は、ドイツの分散コンピューティングの8つの落とし穴に含まれています。（この便利な説明を参照してください。）これらはすべて、（リアルタイムの）分散設計で検討するのに役立ちます。それぞれが、重要な設計と実装の懸念事項の出発点です。
リアルタイムシステムとは、運用完了の適時性がシステムの機能要件と正確性の尺度の一部であるシステムです。（これを明確にするために、ここでSOの質問を開きました。）実際には、ほとんどすべてのシステムが「ソフト」リアルタイムと見なされる可能性があります。通常、運用の適時性に対する暗黙の要件/期待があります。時間の制約が満たされていない場合に正しくないシステムのために、リアルタイムの用語を予約します。これは、ソフトまたはハードで修飾される場合があります。上記の誤謬に要約されている懸念の多くは適時性と交差していることに注意してください。（リアルタイムタグウィキも参照してください）
RT（およびDRT）システムは、「決定論的」（または従来はハードリアルタイム）という極端な要件の連続体に存在することに注意してください。ただし、多くのシステムには非常に重要な時間制約がありますが、それでも決定論的ではありません。特にDRTシステムのコンテキストでは、アクティビティの緊急性の概念をアクティビティの優先度から分離することも役立ちます。遅延と障害が現実的で重要な要因である大規模なシステムでは、適時性やその他の設計要件に影響を与えるコンピューティングおよび通信リソースの明示的な管理がより重要になり、これら2つの次元の分離が重要になります。
DRTシステムのかなり伝統的なプレゼンテーションについては、Kopetzの本をご覧ください。よりダイナミックな見方をするには、ジェンセンの作品と彼のウェブサイトをお勧めします。Javaの領域では、優れた「信頼性の高い分散プログラミング入門」を読むことをお勧めします。適時性の問題の全領域に対処するわけではありませんが、特に明確な方法で部分的な障害に対処します。
最近、（信頼性の低い）障害検出器の概念が有用な同期構造として浮上し、DRTシステムの有用な理論的推論と実用的な定式化/設計/構築技術を可能にしました。このトピックに関する独創的な論文は、Aguilera、Le Lann、およびTouegによる、リアルタイムのフォールトトレラントシステムに対する高速障害検出器の影響についてです。この論文は重いそりですが、知的投資のすべてのオンスに報います。
大まかに言うと、バックエンドからフロントエンドにリアルタイムデータを取得するための2つの基本的な方法があります。
プッシュ：メッセージを送信することにより、データをクライアントに「プッシュ」できます。私は過去にこれを使用してプロセス間メッセージをクライアントに送信し、更新が発生したことをUIに警告しました。これは情報を送信するための最速の方法ですが、複雑さがあります。たとえば、FlashやSilverlightなどを使用しない限り、（まだ）IPCメッセージをWebアプリケーションに送信することはできません。また、送信するメッセージが多すぎるとUIの応答性が低下する可能性があるため、これらのメッセージを調整する必要があります。ここで検討するテクノロジには、MSMQ、TCP / IP、および同等のWCFがあります。
プル：UIはバックエンドから定期的にデータをリクエストできます。この方法の利点は、UIでのコーディングが簡単なことです。つまり、Xごとにデータソースをポーリングするだけです。ただし、明らかに欠点は、更新が発生してからアプリケーションがその更新を受信するまでに遅延があることです。これは、リアルタイム処理には受け入れられない場合があります。とにかく、このモデルでは、Webサービスを呼び出すか、データベースを呼び出すことができます。
もちろん、これは出発点にすぎません。どちらの方法も使用でき、データをクライアントにキャッシュすることもできます。すべて、アプリケーションのニーズによって異なります。