イベントソースなしのCQRS：イベントログのエラー処理

Question

CQRSアプリケーションでEvent Sourcingを使用しないので、私は読み取りストアを更新できるシンプルなイベントログを導入しました。

これは私のアプリケーションへの状態変化は、2つのアクションで構成されていることを意味します例えば、書き込みモデル状態を更新

• SQLのINSERT
• 両方が操作を1つのアトミック操作として発生する必要があり、書き込み

イベントログにイベントを挿入します。残念ながら、イベントログは別のデータベースに存在するため、分散トランザクションについて考える必要があります。

ほとんどのCQRSサンプルはサガパターンを扱っており、すべてイベントソーシングを利用しているように見えるので、作業がはるかに簡単になります。

私の問題は、「半完成」の状態変更です。

SQLTransaction.Commit(); // if this fails, all is fine. Nothing to revert 
try 
{ 
    EventLog.Insert(event); 
} 
catch(Exception ex) 
{ 
    // Try to undo the SQL stuff. 
    CompensatingSQLTransaction().Commit(); 
    // uh-oh! The commit fails!! 

    // What now? Do a Retry? 
} 

を助けることができる任意の概念があります。

• SQL挿入は
• イベントログの挿入は、私は補償SQL操作（擬似コード）を思い付くことができ

を失敗した成功します私は出る？ 私が読ん-データベースを同期外れを防ぐために、次のシナリオについて考え：

• 読み取り側の複製はその後、未処理のイベント（例えば40を受信し、検出された場合、各イベントは、シーケンス番号
• を持っています42）、イベントログにイベント41を照会します。
• イベント41が利用できない場合、システムは誰かが注意を喚起するまでイベントの複製を停止します。

これは、手動によるメンテナンスが必要ですが、読み取りdbの同期が外れないようにします。

実生活体験はありますか？

Answer 1

両方の書き込み操作は、1つのアトミック操作として行う必要があります。

この時点では、本当に重要な質問があります。なぜですか？リモートイベントログが記録された本と同期していない場合、ビジネスへのコストはいくらですか？

同期を必要としない場合は、イベント・ログのコピーを書き込みモデルと同じデータベースに配置してください。 Udi DahanはこのアプローチをReliable Messaging Without Distributed Transactionsで説明します。書き込みトランザクションが成功した後、SQLストアからリモートイベントログにイベントを複製できます。

これは、以前はの一部の状態と常に一致するリモートイベントログを提供しますが、現状に追いつくことはできません。

これは通常十分です;結局のところ、イベントログ自体は過去のスナップショットであり、イベントログの表現が消費者にコピーされている間は記録簿が変化している可能性がある。

ただし、そうしないと、許容できる妥協策を提供する分散トランザクションエンジンを見つけるか、リモート書き込みが失敗した場合にsagasを使用してローカルストアの変更を元に戻すことです。

順番に、Caitieマキャフリーの2015 talk on sagas in distributed systemsを参照この点を提起saga pattern in awsのヤン崔さんの議論、：

補償アクションはまた、我々は成功するまで、それらを再試行できるようにする必要がありますので、失敗する可能性があるためには、手段それらは等冪でなければならない。

実際には、no。あなたが人間の介入を警告する前に再試行をしてください。

だから、再試行します。