問題タブ [akka-persistence]

私は Akka Persistence をいじっており、理解度をテストするために次のプログラムを作成しました。問題は、このプログラムを実行するたびに異なる結果が得られることです。正解は 49995000 ですが、いつもそうとは限りません。実行ごとにジャーナルディレクトリを一掃しましたが、違いはありません。何が問題なのか誰にもわかりますか？このプログラムは、1 から n までのすべての数値を単純に合計します (以下のコードでは、n は 9999 です)。

正解は (n * (n+1)) / 2 です。n=9999 の場合、49995000 です。

編集: JDK 7 よりも JDK 8 の方が一貫して動作するようです。JDK 8 のみを使用する必要がありますか?

SBTファイル

application.conf ファイル

正しい出力:

間違った実行:

別の間違った実行:

akka アクターを使用 - アクターの状態を更新する大量のメッセージをアクターに送信しています

このようにpersistAsyncを使用する

システムを正常にシャットダウンするために、永続化プロセスが完了したことを確認するにはどうすればよいですか?

通常の Akka アクターが最大 1 回の配信セマンティクスを提供することはよく知られています。一方で、akka-persistence は at-least-once 配信セマンティクスも提供します。後者は、より多くの定型文を必要とし、実装時にいくつかの違いがあります (つまり、配信が確認されたら、受信または再送信を避けるためにシーケンス番号を処理します)。

ここで、多数の重要なトランザクションを処理する大規模なエンタープライズ アプリケーション (銀行など) があるとします。このトランザクションは、システムを構成するアクター間の特定のメッセージ フローとして内部的にモデル化されます (複数のマシンに展開される可能性があります)。

したがって、前述のメッセージ フローで 1 つのメッセージが失われたことが、トランザクションが失敗したか、黙って破棄されたことを意味する場合、この状況では、すべてのボイラープレートで at-least-once 配信を EVERYWHERE で使用することを実装に強制しますか? これにより、コード ベースの保守がややこしくなるのではないでしょうか? コードの保守性と全体的なシステム パフォーマンスのバランスの観点から、この種の状況を効率的に処理するにはどうすればよいでしょうか。安全な方法で少なくとも1回の配信の使用を一般的に最小限に抑える方法は?

どうもありがとう。

私はPersistentActor、特定のイベントに対して、彼の状態や行動を変化させることができる を持っています。状態を永続化するために問題はありませんが、状態の一部として動作を永続化する必要があることがわかりました。そうしないと、スナップショットからの障害回復の場合に正しく初期化されません。状態であり、動作ではありません。これを正しく達成する方法は？

現在、状態と動作のタプルを保存していますが、これが正しい方法かどうかはわかりません。私はあらゆる種類の提案やアイデアを受け入れます。FWIW、この種のアクターの使用例は、クラスター シャーディングのエントリです。ここでは、各エントリが (become/unbecome) を使用していくつかの状態を通過し、エントリの状態とその動作を保持する必要があります。どうもありがとう。

問題を示すコードは次のとおりです。