CQRSの読み取り側での順序違反イベントの処理

Question

Jonathan Oliverからの不適切な投稿を読んだことがあります。

http://blog.jonathanoliver.com/cqrs-out-of-sequence-messages-and-read-models/

我々が使用するソリューションは、メッセージをデキューするために、前の配列と、すべてのメッセージが 受信されるまで、「保持テーブル」に配置することです。以前のすべてのメッセージが受信されたら、 メッセージを保持テーブルから取り出し、 適切なハンドラを通して順番に実行します。 すべてのハンドラが正常に実行されると、保持テーブルからメッセージが削除され、読み取ったモデルの更新が にコミットされます。

ドメインがイベントを公開し、 に適切なシーケンス番号を付けるため、これは私たちのために機能します。これがなければ、以下の解決方法 は不可能ではないにしても、はるかに難しくなります。

このソリューションでは、永続ストレージ メカニズムとしてリレーショナルデータベースを使用していますが、 ストレージエンジンの関係性の側面は使用していません。同時に、このすべてに警告があります。 メッセージ2,3,4が届いても、メッセージ1は届かない場合は、 は適用されません。エラーメッセージ メッセージ1を処理している場合、またはメッセージ1が何らかの形で消失した場合にのみ、シナリオが発生します。幸いにも、 メッセージハンドラのエラーを修正するのは簡単で、 はメッセージを再実行します。または、メッセージが失われた場合は、 をイベントストアから直接読み込んで再構築してください。

イベントの不足をイベントストアにいつでも頼むことができるとのことについて、いくつか質問がありました。

1. CQRSの書き込み側は、イベントの再生を要求する側のサービスを公開する必要がありますか。たとえば、イベント1に は受信されていませんが、2,3,4,3が受信できた場合は、イベントストアを サービスでリクエストして1から開始してイベントを再公開することができますか？
2. このサービスはCQRSの書き込み側の責任ですか？
3. これを使用して読み込みモデルを再構築するにはどうすればよいですか？

Answer 1

シーケンス番号がある場合は、現在のイベントが異常である状況を検出できます。 currentEventNumber！= lastReceivedEventNumber + 1

これを検出すると、例外がスローされます。あなたのサブスクライバが「再試行」の仕組みを持っている場合、このイベントをもう1秒程度で再度処理しようとします。この時間の間に、以前の出来事が処理され、シーケンスが正しいことがかなり良いチャンスです。これは、アウトオブオーダーのイベントがめったに起きない場合の解決策です。

このような状況に直面している場合は、グローバルロックメカニズムを実装する必要があります。これにより、特定のイベントを順番に処理できるようになります。 たとえば、MSSQLでsp_getapplockを使用して、特定の状況でグローバルな「クリティカルセクション」の動作を実現していました。 Apache ZooKeeperは、分散アプリケーションの複数の部分が単なる単純なロック以上のものを必要とする場合、さらに複雑なシナリオに対処するためのフレームワークを提供します。

Answer 2

あなたがここで説明しているのは、イベントソース（ES）です。コマンドモデルで発行されたイベントを永続ストレージに格納します。 イベントタイプ、コマンドモデルID（集約ルートID）、コマンドモデルタイプ（集約ルートタイプ）別にストアドイベントを再生します。 ESを持つことの利点があります。後でこれらのイベントを再生して、新しいタイプのクエリモデルを作成することもできます。 ESアプローチを使用すると、UnitOfWorkスコープのアプリケーショントランザクションを使用することもできます。コミット時に、発行されたイベントは永続化され、イベントリスナーに配信されます（QMメンテナンスサービス）。コミットステージでの検証には、シーケンス番号（db）による並行アクセスのチェックが含まれている必要があります。