問題タブ [akka-persistence]

新しいプロジェクトで CRQS + イベント ソーシングのアイデアを実装するために、akka-persistence イベント ソーシング機能を使用したいと考えています。問題は、ドキュメント ( http://doc.akka.io/docs/akka/snapshot/scala/persistence.html ) 以外に、良い例やアプローチ方法のガイドラインが見つからなかったことです。ドキュメントは、プロセッサ、ビュー、チャネルなどのアーキテクチャのすべての構成要素を説明するという点では優れていますが、それらを組み合わせる方法については説明していません。

問題は、akka-persistence で書き込みモデルと読み取りモデルをどのように接続すればよいかということです。私は3つのオプションを思いつきました：

• 直接接続 EventsourcedProcessor -> ビュー、ビューはすべてのイベントをジャーナルから直接受け取ります。これは最も単純な解決策のように思えますが、このアプローチを使用してプロセッサとビューを異なるノードに分散できるのではないでしょうか。

• EventsourcedProcessor -> Channel -> View/normal Actor。最初のオプションとの違いは何ですか? これが正しい解決策である場合、なぜ akka-persistence ビルディング ブロックにビューがあるのでしょうか? Channels または PersistentChannels を使用する必要がありますか?

• EventsourcedProcessor -> ある種のイベント バス (例: context.system.eventStream) -> ビュー/アクター。

最善の方法とその理由は何ですか?

残念ながら、取得している Enumeration を含む Persistent メッセージを送信しているときに、akkas 永続モジュール (2.3.0) を使用しようとしています java.io.NotSerializableException。これが私の素朴な例です：

これで終わります

ここで何が起こっているのか、それを修正する方法を知っている人はいますか?

ライブラリの依存関係に Akka を追加してtestタスクを実行した後、次のエラーが発生する理由は何ですか?

そして、runタスクを実行すると:

私の関連build.sbt設定

と私project/plugin.sbt

これは、次のライブラリで akka-persistence プラグインを追加した後に始まりました。

Cassandra をインストールし、これを実行しながらローカルで実行しています。

これらの行のいずれかをコメントアウトして , を実行しても、sbt cleanまだこのエラーが表示されます。それらをすべてコメントアウトした場合にのみ、アプリを実行してテストできます。sbt updatesbt test

私の唯一の推測は、永続化ライブラリと Play2 の Akka のバージョンに互換性がないということです。

そうですか？

2 つのイベントを生成する書き込みモデル (ドメイン) があるとします。

• CarrierAdded(...)
• BusConnectionCreated(キャリア、...)

Carrier クラスと BusConnection クラスは、別個の集約 (の一部) です。BusConnection は Carrier に割り当てられ、その CarrierId を含みます (個別の集計は ID によってのみ参照されます)。

コマンドとイベントの通常のフローでは、書き込みモデルと読み取りモデルの両方ですべて問題ありませんが、新しい読み取りモデルを最初から再構築/追加する場合に問題が発生します。

多くの人が (akka-persistence ライブラリなど)、イベントはイベント ストアに集約ごとに保存することを提案しています。デノーマライザーがイベントに応答するように要求すると、各集計から 2 つの独立したイベント ストリームを取得します。問題は、上記の例のように、異なる集約からの一部のイベントが、イベント ストアに追加されたのと同じ順序で応答する必要があることです。つまり、何らかの因果関係/部分的な順序付けが必要です。

そして最後に私の質問：

• ドメインの設計を再考する必要があります (集約境界が不適切ですか?) または
• 部分的な順序を強制するだけでよいですか?

後者の場合、それを行う最も効率的な方法は何ですか?

• グローバルカウンター？スケーラブルではないようです。
• ある種のベクトル時計？
• そのような問題が発生したときに、デノーマライザーでそのような問題を検出しますか? たとえば、CarrierId を取得しましたが、この ID を持つ CarrierAdded イベントがまだないため、イベントを隠して、最初に予想されるイベントを待ちます
• 再生モードでイベントを処理するという観点から、いくつかの順序を導入しますか? たとえば、Carriers に関するすべてのイベントが最初で、BusConnection 関連のイベントは後でですか?

特定のユーザー アクションに基づいて定義済みのイベントを発生させる必要があるユース ケースが複数あります。

たとえばNewUser、アプリケーションで が作成されたときにCreateUserInWorkflowSystem、FireEmailToTheUser非同期で呼び出す必要があるとしましょう。ユースケースに基づいてイベントが事前定義される、この種のビジネス ケースは他にも多数あります。Promises/Futures を使用して、これらのイベントを以下のようにモデル化できます

これらのFuture呼び出しはすべて、失敗した呼び出しを再試行できるように、どこかに失敗を記録する必要があります。呼び出しは、それらの(イベントごとのイベント) が完了するNewUserのを待機しないことに注意してください。Futures

それはプレーンなFutures/PromisesAPI を使用していました。ただし、ここではAkka Persistenceが適切であり、ブロック呼び出しが引き続きFutures. Akka の永続性を使用すると、すぐに使用できるなどの理由で障害の処理が簡単になります。Akka の永続性はまだ実験段階にあることは理解していますが、タイプセーフは通常、これらの新しいフレームワークを昇格する前に実験的な状態に保つため、大きな懸念事項ではないようです。将来のリリースなどに（同じことがマクロにも当てはまりました）。これらの要件を考えるとFutures/Promises、Akka の永続性の方が適していると思いますか?

以下のようないくつかのユースケースがあります。

1) createUserAPI 呼び出しはフロントエンド経由で行われます。この呼び出しが成功すると、データが db に正常に保存されたことを意味し、フロント エンドに成功を返します。API コントラクトは、フロントエンドとバックエンドの間で終了します。

2) バックエンドは、CreateUserユーザーをサード パーティ アプリに作成するイベントを生成して起動する必要があります (例として、createUser を外部エンタイトルメント システムに作成すると言えます)。これは完全に非同期でバックグラウンド タイプのプロセスであり、クライアントはそれを認識しておらず、この API の成功または失敗を待機していません。ただし、このCreateUserイベントへのすべての呼び出しは、監査および修復 (失敗の場合) の目的で、失敗または成功と共にログに記録する必要があります。

最初のアプローチFutureは、これらの非同期イベント用にベースの非同期 APIを設計し(アプリの残りの部分Futuresはasync頻繁に使用されます)、着信イベントと結果の成功/失敗を db に記録することです。

2 番目のアプローチは、Akka を使用し、これらのイベントに対して個別のアクターを用意することです (例:CreateUserは 1 つの例です)。次のように見えるかもしれません

}

3 番目のアプローチAkka Persistenceを使用して、イベント ソーシング ジャーナリングを使用してイベントの永続化をすぐに実行できるようにします。ただし、イベントの成功または失敗の 2 番目の永続性は手動になります (そのためのコードを記述します)。この 3 番目のアプローチは有望に見えるかもしれませんが、イベントを永続化するために Akka の永続性に依存しているため、うまくいかない可能性があります。など）ここでたくさん購入するかどうかわかりませんか？

2 番目のアプローチでは、両方のケース (着信イベントとイベントの結果) に対して永続的なコードを記述する必要があります。

最初のアプローチはあまり有望に見えないかもしれません。

そのように聞こえるかもしれませんが、「意見に基づく」ように聞こえるかもしれない質問を作成するつもりはありませんでしたが、言及されたアプローチまたはここにうまく適合する可能性のある他のものについて、その長所/短所を備えた真のアドバイスに応えようとしました.

参考までに: この特定のアプリケーションはプレイ サーバー上で実行されるプレイ アプリケーションであるため、アクターの使用は問題になりません。