まず、金融業界のリアルタイム システムで許容されるエンド ツー エンドのレイテンシが 200 ミリ秒未満であることを確認したいと思います。さて、これが私が求めているものです。リアルタイム システムの設計では、パフォーマンスを向上させる (処理時間の短縮、スケーラビリティの向上など) "設計パターン" (または手法) があります。
私が求めていることの例は、主キーの割り当てに連番の代わりに GUID を使用することです。GUID の根拠は、ハンドラーが互いに「相談」することなく、独自の主キー ジェネレーターを持っていることです。これにより、並列処理が可能になり、スケーリングが可能になります。
ここにいくつかあります。できたらリストに追加しようと思います。
私はコミュニティの集合的な知恵に頭を下げます。ありがとうございます！
一般的なリアルタイム システム作業の古典的なルールは、可変性を追求してそれを無効にすることです。リアル ハード リアルタイムとは、静的なスケジュール、合理化されたオペレーティング システム、効率的なデバイス ドライバー、および厳格な優先順位を使用することを意味します。計算 X を既知の制限時間 T 内で終了させたい場合は、動的または適応的なものは実行できません。
ここで言っていることは、その点でリアルタイムではないと思います。システムは、センサーの読み取り、制御ループの計算、アクチュエーターの起動よりも少し複雑だと思います。制約がここにあることを知っておくと、さらに詳細が得られます。
Event Driven Architecture については既に言及しましたが、Staged Event Driven Architectures (SEDA) をご覧になることをお勧めします。
ステージは基本的に、イベントのキューであり、イベントを操作する関数です。このアーキテクチャの「型にはまらない」点は、各ステージを独自のスレッドで実行できることと、通常、関数に非同期 I/O などが必要なことです。 QoS、微調整されたスケジューリングなど
Welsh の Berkeley 論文と彼のWeb サイトを参照してください。また、Minor Gordon のプロジェクト (ケンブリッジ UK から) と呼ばれるyieldを参照することもできます。彼はいくつかの非常に良い結果を残しました。このプロジェクトは最初は Python を対象としているように見えるかもしれませんが、純粋な C++ にも使用できます。
基本的に聞こえるかもしれませんが、ほとんどの基幹業務アプリケーションは冗長な計算で満たされているため、それらを排除します。計算のリファクタリングは、最適化パターンのバックボーンです。処理サイクルが表示されるたびに、次のことを尋ねる必要があります。
このサイクル内のものは、サイクル外と同じ出力で計算されます。基本的な例として:
for(int i=0;i< x/2; i++)
//do something
ここでは、安全に x/2 を取得して cicle の前に計算し、その値を再利用できます (最近のコンパイラはこれらの些細な最適化を処理するようになりました)。
この単純なルールの影響を確認するために、データベース クエリに適用される例を示します。頻繁に繰り返されるフィールドを取得するために 2 つのテーブルの INNER JOIN を回避するために、正規化ルールに違反して、値を持つテーブルに関連するテーブルに複製することができます。これにより、反復的なテーブル結合処理が回避され、トランザクションでテーブルの 1 つだけをロックする必要があるため、並列化を解放できます。例：
クライアント テーブル クエリではクライアント割引が繰り返し必要ですが、割引はクライアント タイプ テーブルに保存されます。
「壊れている」ことが確実にわかっていない限り、何も「修正」しないでください。
私が最初に行うことは、高速に実行する必要があるそのプログラムから炎を調整することです。私は私の好きなテクニックを使用します。そうすれば、アーキテクチャをいじる余地が十分にある可能性があります。