リポジトリインタフェースは実装のキャッシュをクリアするclear（）メソッドを公開する必要がありますか？

Question

リポジトリパターンに関する質問があります。私はデータがメモリに保存されているが、データの耐久性のためのデータベースがある分散プロジェクトに取り組んでいます。システムの規模を拡大するために、データはアプリの複数のインスタンスにわたって分割されます。このため、いずれかのノードに問題が発生するたびに、データはデータベースから再ロードされ、分散キューを使用して再構築されます。

私たちはリポジトリインターフェイスを作成して、ドメインがデータを処理するようにしました。このインターフェイスの実装では、マップを内部キャッシュとして使用し、Hibernateを使用してデータベースと通信します。

再作成を開始するためにアプリケーションのインスタンスが作成または削除されるたびにキャッシュをクリアする必要があるため、私はこの目的のためにリポジトリにメソッドを公開しています。これは正しい方法ですか？これは、実装の内部に関連するメソッドを公開するインタフェースではありませんか？もう1つの解決策は、リフレッシュをトリガするサービスにキャッシュを挿入することですが、それはパーシスタンス層の実装に関する情報が漏れることを意味します。

アイデア？

ありがとうございました。アプリについてもう少し

EDIT

。シャーディングが実行された理由は、データが増加した場合にアプリケーションを拡張できることでした。これらのチャンネルは最大数千になることがありますが、1秒あたり最大2件のメッセージを送信するさまざまなチャンネルを購読する必要があります。受信したすべてのメッセージについて、すべてのデータを調べ、メッセージの情報と一致するものを見つけて、それらのすべての通知を送信する必要があります。これをスケールするには、データは各インスタンス間で分割され、各インスタンスは所有するデータを処理します。

データはユーザーによって作成され、そのために作成されたRESTエンドポイントがいくつかあります。その意味では、クライアントは作成したデータを作成、更新、削除、取得することができるシンプルなアプリケーションとして動作します。リポジトリは、典型的なCRUD操作およびメソッドを特定の情報に基づいて照会するように公開しており、実装はキャッシュおよびデータベースにデータを追加し、要求に応じて一方または他方からデータを取得します。キャッシュミスが発生した場合、データベースからデータを取り出してキャッシュに入れることはできません。なぜなら、データが存在しなければ、別のものが必要になるからですクラスタ内のインスタンスで、独自のキャッシュにデータを格納します。これを処理するために、リクエストをリダイレクトするために使用するキューとトピックがあります。

このため、キャッシュをクリアする必要があります。クラスタのトポロジに変更があるたびに、新しいノードがある場合、またはキャッシュの1つとしてデータベースからデータを再度取得する必要がある場合に、キャッシュ内のデータを再調整する必要があることを意味します下がった。どのデータが欠落しているか正確にはわからないので、キャッシュをクリアしてデータベースから再投入します.1つのノードをデータローダーとして使用し、分散キューを使用してデータを破棄します。 このジョブはかなり高速に処理されるので、この間にクライアントからの要求は拒否されます。アプリにはクライアントからの多くの同時リクエストはありません。問題は、引き続き維持する必要があるサブスクリプションチャンネルにあります。

Answer 1

実際、clear()メソッドを公開したくないです。

2つのサービスがあるとします。説明したリポジトリと、クラスタの状態と変更された時期を知っているクラスタマネージャ。

トポロジが変更されたときに、クラスタマネージャがリポジトリAPIを消費し、必要な操作をすべて呼び出すコードを追加できるようになりました。 しかし、リポジトリー実装からクラスター・マネージャーへの依存性だけがあります。クラスタマネージャは、他のクライアントにサービスを提供するためにリポジトリを知る必要はありません。

唯一の問題は、呼び出しが元に戻り、クラスタマネージャがリポジトリを呼び出す必要があることです。これを解決するには、クラスター・マネージャーAPIの一部であるイベント（例：TopologyChanged）を定義して、リポジトリーの実装で通知を受けたいことをクラスター・マネージャーに伝えさせます。

サイドノート：

すでに業務のまさにこのような操作を行う可能な製品は、例えば、ありますApache Ignite、Hazelcast、Infinispan