3

CQRS を使用したプロジェクトの実装に着手しており、J Oliver EventStore V2.0 をイベントの永続化エンジンとして使用する予定です。

1) ドキュメントでは、ExampleUsage.cs は "BuildSerializer" で 3 つのシリアライザーを使用しています。これは、逆シリアル化プロセスの柔軟性を示すためのものだと思いますか?

2) 一部のイベントがディスパッチされなかった「失敗後の再起動」の場合、GetUndispatchedCommits() を呼び出してディスパッチするスタートアップ コードが必要だと思いますが、正しいですか?

3) 繰り返しますが、「ExampleUseage.cs」では、「TakeSnapshot」が 3 番目のイベントをイベントストアに追加し、次に「LoadFromSnapShotForward」が最新のスナップショットを取得するだけでなく、ポスト スナップショットのイベントを取得して再構築をシミュレートすると便利です。集合体。

4) 古いスナップショットを保持する用途が見当たりません。それらが役立つユースケースを教えてください。

5) コマンドの受信とイベントの生成を処理するサービスがある場合、特定の集計の最後のスナップショット以降のイベント数を追跡​​するための推奨戦略は何ですか。「GetStreamsToSnapshot」をあまり頻繁に呼び出したくないのは確かです。

6) SqlPersistence.SqlDialects 名前空間では、SQL ステートメント名は「GetStreamsRequiringSnapShots」ではなく「GetStreamsRequiringSnaphots」です。

4

1 に答える 1

3

1) Binary、JSON、BSON シリアライザーなど、いくつかの「ベース」シリアライザーがあります。この例の他の 2 つ (GZip/圧縮および暗号化シリアライザー) はラッピング シリアライザーであり、既にバイト ストリームにシリアライズされているものを変更することのみを目的としています。例として、私は柔軟性を示しているだけです。暗号化したくない場合は、暗号化する必要はありません。実際、すべてがテキストであるため、デバッグを非常に簡単にする単純な JSON を使用する運用を実行しています。

2) SynchronousDispatcher と AsychronousDispatcher の実装は両方とも、ディスパッチされていないコミットを照会して検索するように構成されています。特別なことをしなくていいです。

3) Greg Young は、スナップショットをメイン イベント ストリームに「インライン化」していた方法について話しましたが、ハイ パフォーマンス システムでは多くの楽観的な同時実行と競合状態が発生しました。したがって、彼はそれらを「帯域外」に移動することにしました。私は多くの同じ理由でこの決定に従いました。

さらに、SLA が非常に低い場合、スナップショットは実際にはパフォーマンスの考慮事項です。数千のイベントを含むストリームがあり、SLA が低くない場合は、システムに複雑さを追加するのではなく、パフォーマンスへの影響を最小限に抑えてみませんか。つまり、スナップショットは「補助的な」概念です。それらは EventStore API にありますが、特定のユース ケースで考慮する必要があるオプションの概念です。

4) 数千万のイベントの集計があり、最新のスナップショットの前から「what if」シナリオを実行したいとします。別のスナップショットから先に進む方がはるかに安価です。スナップショットが二次的な概念であることの本当に良い点は、古いスナップショットを削除したい場合でも、システムにまったく影響を与えないことです。

5) IPersistStreams の各実装には、GetStreamsRequiringSnapshots と呼ばれるメソッドがあります。たとえば、50 のしきい値を指定すると、最後のスナップショット以降に 50 以上のイベントを持つすべてのストリームが検出されます。これは、通常の処理とは非同期に行うことができます (そしておそらくそうすべきです)。

6) 「スナップショット」は、その単語の正しい大文字小文字です。「ウェブサイト」は以前は「ウェブサイト」でしたが、一般的な用法のために「ウェブサイト」になりました。

于 2011-03-18T16:17:48.350 に答える