現在、redis をクエリするだけでどのメッセージが処理されたかを監視できるため、akka で redis を使用するのが好きです。Redis はディスクにも保持されます。
akka の永続性は、単に redis を使用する場合と比べてどうですか?
現在、redis をクエリするだけでどのメッセージが処理されたかを監視できるため、akka で redis を使用するのが好きです。Redis はディスクにも保持されます。
akka の永続性は、単に redis を使用する場合と比べてどうですか?
提供されるものは異なりますが、どちらのオプションも他のオプションより優れているとは言えません。Akka 永続化とは、アクターが処理する各イベントを永続化することであり、これらのイベントを再生してアクターの状態を再構築できます。これは、イベント ソーシングhttp://martinfowler.com/eaaDev/EventSourcing.htmlの実装です。システムの動作に関する分析など、他の目的のために保存されたイベントを調べることもできます。すべての履歴イベントが記録されるため、詳細な分析が可能です。http://www.cakesolutions.net/teamblogs/using-spark-to-analyse-akka-persistence-events-in-cassandra
別の永続化メカニズムには、システムの現在の状態のみが含まれている可能性があるため、履歴の分析は不可能です。
イベント ソーシングは、Martin Fowler の記事を引用して、すべてのアプリケーションに適しているとは限りません。
アプリケーションへのすべての変更をイベントとしてパッケージ化することは、誰もが慣れているわけではなく、多くの人がぎこちないインターフェイス スタイルです。結果として、それは自然な選択ではなく、それを使用することは、何らかの形で見返りを得ることを期待することを意味します.
Redis (またはその他のデータベース) を直接使用することで、永続化の方法をより完全に制御できます。Akka Persistence では、その方法を使用する必要がありますが、詳細の一部は抽象化されています。これはある程度、柔軟性 (Redis を使用して独自の永続レイヤーを作成する) と使いやすさ (Akka Persistence ライブラリを使用する) のトレードオフです。
Akka Persistence は、永続化に使用するシステムに関してプラグ可能です。Redis を含む多くのストレージ システム用のプラグインがあります: https://github.com/hootsuite/akka-persistence-redis
したがって、Akka Persistence の利点の 1 つは、アプリケーション コードを変更する必要なく、永続化レイヤーを変更できることです (たとえば、テストと運用の間、またはアプリケーションが時間の経過とともに変化する必要があるため、RDBMS から NoSQL へ)。