7

私たちのシステムは、パフォーマンス上の理由から、完全にメモリ (約 10 Gb) に保持される構造化モデル (いくつかの種類の関係を持つ約 30 の異なるエンティティ) を持っています。このモデルでは、3 種類の操作を行う必要があります。

  1. 1 つまたはいくつかのエンティティを更新する
  2. 特定のデータのクエリ (これには通常、何千ものエンティティを読み取る必要があります)
  3. 統計データの取得 (メモリ使用量、種類に対するクエリ数など)

現在のアーキテクチャはかなり標準的なもので、共有モデルを使用するサーブレット用のスレッドのプールがあります。モデル内には多くの同時コレクションがありますが、いくつかのエンティティが「よりホット」であり、ほとんどのスレッドがそれらを読み書きしたいため、まだ多くの待機があります。通常、クエリは書き込みよりもはるかに多くの CPU と時間を消費することにも注意してください。

モデルを単一のスレッドに保持し、可能なすべて (妥当性チェック、監査など) を別のコンシューマーのモデルから移動する Disruptor アーキテクチャに切り替える可能性を研究しています。

もちろん、最初の質問は次のとおりです。それは理にかなっていますか?

Secondo の質問: 理想的には、書き込み要求は読み取り要求よりも優先されるべきです。ディスラプターで優先順位を付ける最良の方法はどれですか? 私は2つのリングバッファについて考えていたので、優先度の低いものよりも優先度の高いものからより頻繁に読み取ろうとしました。

質問を明確にすることは、LMAX Disruptor の実際のコードよりもアーキテクチャに関するものです。

詳細を更新

データは複雑なドメインであり、多くの異なるタイプ (~20) の多くのエンティティ (>100k) が、多くの異なるコレクションを持つツリー構造でリンクされています。

通常、クエリでは、何千ものエンティティを走査して正しいデータを見つけます。更新は頻繁に行われますが、一度に 10 個のエンティティのようにかなり制限されているため、データ全体ではあまり変化していません (1 時間で 20% など)。

私はいくつかの予備テストを行いましたが、モデルを並行してクエリすることによる速度の利点は、時折発生する書き込みロックの遅延を上回るようです。

4

2 に答える 2

2

「理想的には、書き込み要求は読み取り要求よりも優先されるべきです。」

なんで ?C# ReaderWriterLockSlim のようなほとんどの高速ロックは、その逆を行います。部分的な読み取りを避けるために、書き込みはすべての読み取りをブロックする必要があります。したがって、そのようなロックは、物事が「かなり」取得されてから書き込みが行われることを期待して、多くの同時読み取りを可能にします.. (書き込みはキュー内のその番号で実行されますが、ロックされる前に処理された後に発生した多くの読み取りが発生する可能性が非常に高くなります)..

書き込みを優先することは、並行性を殺す良い方法です..

最終的な同時実行/CQRS はオプションですか?

于 2012-11-03T12:14:43.453 に答える