キャッシュ内のイベント通知: 概要
分散キャッシュ パラダイムでは、クライアント アプリケーションは、キャッシュで発生するさまざまな操作について通知を受ける必要がある場合があります。 NCache さまざまなタイプのイベントを生成できますが、クライアント アプリケーションは関心のあるイベントに登録して通知を受け取ることができます。
Note
この機能はでのみ利用可能です NCache Enterprise.
キャッシュ内のイベントに関連するいくつかの重要なポイントを次に示します。
- イベントは、クライアント アプリケーションが登録した場合にのみ生成されます。
- イベントは、サブスクライブしたクライアントにのみ発行されます。
- キャッシュはイベントが発生するタイミングを決定し、クライアントはイベントに応じて実行するアクションを決定します。
- クライアントは複数のイベントに登録でき、複数のキャッシュからの複数のイベントを処理することもできます。
Note
アプリケーションは、特定のイベント登録 API 呼び出しを使用してアプリケーション自体をキャッシュに登録しない限り、イベントを受信できません。
キャッシュ内のイベント通知の重要性
今日の多くのアプリケーションは、データの整合性を確保するために、実行時に互いに非同期でデータを共有する必要があります。 さらに、データの状態を更新するか、データのスナップショットをサーバー側の状態と同期する必要があります。 したがって、アプリケーションには、サーバーでデータの状態を監視するメカニズムが必要です。 イベント通知は、キャッシュ内のデータが変更されるたびにクライアント アプリケーションに通知するためのこのメカニズムを提供します。
したがって、イベントは許可します ランタイムデータ共有 別々のアプリケーションまたは同じアプリケーションの別々のモジュール間。 さらに、イベント ドリブンのデータ フェッチがサポートされています。 NCache キャッシュ サーバーへの明示的なデータ フェッチ要求なしで、クライアント アプリケーションがデータを受信できるようにします。
のイベント NCache
データまたは管理操作に固有のキャッシュ レベルのアクティビティに対してイベントが発生する場合があります。 ここでは、イベントを分類し、関連する詳細について説明します。
データ固有のイベント
名前が示すように、これらのイベントは、キャッシュ内のデータが変更されたときにトリガーされます。 加えます, updateまたは 削除します オペレーション。 これらの基本的な CRUD 操作とは別に、データがキャッシュ内で追加、更新、または削除されたときにもデータ固有のイベントが発生します。 キャッシュスタートアップローダー/リフレッシャー および バッキングソース.
これらのイベントを通知用に登録するには、 MessagingService.RegisterCacheNotification
という方法が使われます。 同様に、データ固有の通知は、不要になった場合は、 MessagingService.UnRegisterCacheNotification
方法。
適切な EventType
を使用してデータ固有のイベントに登録している間 イベントタイプ 列挙。 次の通知は、登録済みに基づいて起動できます EventType
:
通知を追加: 通知の追加は、
ItemAdded
イベント タイプが登録され、新しいアイテムがキャッシュに追加されます。更新通知: 更新通知は、次の場合にトリガーされます。
ItemUpdated
イベント タイプが登録され、キャッシュ内の既存のアイテムが更新されます。通知を削除します。 削除通知は、
ItemRemoved
イベント タイプが登録され、アイテムがキャッシュから削除されます。
を使用して、イベントの実行時に返される情報を制御することもできます イベントデータフィルター これについては、 イベントフィルタ のセクションから無料でダウンロードできます。
データ固有のイベントは、次のようにさらに分類できます。
キャッシュレベルのイベント
キャッシュレベルのイベント の実行時にトリガーされるキャッシュの一般的なイベントです。 Add, アップデイトまたは 削除します キャッシュ データの操作。 目的は、キャッシュで実行されるすべての操作について、さまざまなクライアントに通知することです。
警告
キャッシュ データ セット全体のすべての操作に対して通知が登録されている場合、キャッシュ レベル イベントによってアプリケーションのパフォーマンスが低下する可能性があります。
デフォルトでは、キャッシュ レベル イベントはどのキャッシュ構成でも無効になっており (キャッシュ クリア操作を除く)、 NCache 管理センター.
アイテムレベルのイベント
アイテムレベルのイベント キャッシュで実行されるすべての操作ではなく、限定されたデータ セットについて通知する場合に役立ちます。 たとえば、キャッシュに大量のデータが含まれており、データ セットに変更が発生するたびに通知を受けると、オーバーヘッドが発生し、アプリケーションのパフォーマンスに影響を与えます。
Note
パフォーマンスを向上させるために、関心のあるデータ セットのみの通知を登録できます。
キャッシュは、指定されたキーの変更を監視する役割を果たします。 選択したデータ セットはすでにキャッシュに存在するため、項目レベルのイベントは更新または削除操作でのみ受信されます。 アプリケーションは、API 呼び出しを使用してキャッシュ内の特定のキーのコールバック メソッドを登録し、そのキーが更新またはキャッシュから削除されたときに通知を受け取ります。 これらの通知は非同期でクライアントに送信されるため、クライアントのアクティビティにオーバーヘッドはかかりません。
Note
アイテムレベルのイベントは、既にキャッシュに存在するデータセットに対して登録されるため、追加通知を受け取ることができません。
管理レベルのイベント
管理レベルのイベント を使用してキャッシュ クラスター上で管理操作が実行されたときに通知を受けるように登録できます。 通知サービス インタフェース。
これらのイベントは、キャッシュ上で操作が継続されるかどうかを確認する検証に使用できます。 たとえば、クライアントはマルチスレッド アプリケーションであり、スレッドは一定のレートで項目を挿入することに特化しています。 挿入中にキャッシュが停止した場合、 NCache クライアントがスローします OperationFailedException
。 例外がスローされないようにするには、スレッドはキャッシュの停止時に適切なアクションを実行する必要があります。 これは、キャッシュ停止アクションに対するイベントを登録することで簡単に実現できます。
この例は、クライアント アプリケーションのスレッドがキャッシュのクリア中に実行中に操作を検証する場合のキャッシュ クリア通知にも適用されます。 クライアント アプリケーションがキャッシュのクリア イベントを考慮しない場合、すべての検証は失敗します。
キャッシュで管理操作が実行されると、次の通知が発行されます。
キャッシュクリア通知: キャッシュがクリアされると、キャッシュクリア通知が発行されます。
キャッシュ停止通知: キャッシュが停止すると、キャッシュ停止通知が発生します。 キャッシュが停止していることを知らずに、キャッシュが停止しているときにアプリケーションが操作を実行し続けると、実行された操作に対して例外がスローされます。
メンバー参加通知: メンバーがクラスターに参加すると、メンバー参加通知が発行されます。 キャッシュ管理者または操作中にキャッシュの状態を監視するユーザーは、クラスターの状態を監視するタスクを自動化できます。 したがって、メンバーがクラスターに参加する場合は、自動化されたタスクが中断されないようにイベントを処理する必要があります。
メンバーの左通知: メンバーがクラスターを離れると、メンバーの離脱通知が発生します。
クライアントアクティビティイベント
クライアントアクティビティイベントは、クライアントの接続/切断を通知します。 クラスター化キャッシュに接続されている各クライアントは、これらのイベントをサブスクライブして、他のクライアントの接続/切断イベントに関する通知を受け取ることができます。
また、保持期間を指定することもできます。保持期間は、切断されたクライアントが切断されたとみなされ、その切断イベントが発生するまでの期間です。 クライアントが保持期間内に再接続した場合、その切断イベントは発生しません。
これは、バグのあるネットワークが原因で発生した偶発的な切断を補償するためのものです。 NCache クライアントは、クライアントの操作を中断することなく、そのようなネットワークに自動的に再接続します。 これは、手動で破棄して再初期化するクライアントには適用されないことに注意してください。
次のことを行う必要があり クライアント アクティビティ通知を有効にする in NCache 管理センター 使用前に。
イベントデータフィルター
NCache は、大阪で EventDataFilter
データ固有のイベントの実行時に返される情報の量を制御します。 イベントフィルターの種類は次のとおりです。
警告
不必要なネットワーク帯域幅の消費を避けるために、イベント データ フィルタを慎重に設定する必要があります。
なし
このフィルターは、イベント通知の操作によって影響を受けるキーのみを返します。 これは、アプリケーションがどのキーが影響を受けたかを知ることのみに関心がある場合に使用されます。 たとえば、e コマース サイトは、値自体ではなく、どのプロダクト キーが追加されたかを知りたいと考えています。
このフィルターを使用すると、影響を受けるキーとそのメタデータがイベント通知で返されます。 返されるメタデータには、 グループヘッド, キャッシュアイテムの優先度, 期限切れ, キャッシュアイテムのバージョン, 再同期オプション, CacheItemRemovedReason, エントリータイプ。 この情報はユーザーによって要求される場合があります。 たとえば、アプリケーションがどのキーがキャッシュから削除されたか、およびそれらがどのグループに属しているかを知りたい場合です。
メタデータ付きデータ
このフィルターは、キャッシュされたアイテムおよびそれらに関連するメタデータとともにキーを返します。 これは、アプリケーションが変更されたデータを処理する必要がある場合に使用できます。 たとえば、銀行アプリケーションでは、どの顧客の情報が変更されたかを知る必要がある場合があります。 したがって、このフィルターを使用してアイテム更新操作の通知を登録できるため、イベントが発生するとアイテム キーと変更されたアイテムもユーザーに返されます。
使い方 DataWithMetadata
フィルターは、アイテムを再度取得する際の手間を省きます。 入手 API。 ただし、返されるデータの量が大量になるとネットワークの占有が発生する可能性があるため、このフィルターは必要に応じて使用する必要があります。
警告
クライアントが切断された場合、クライアントの切断された期間中はイベントはログに記録されません。
トポロジーの賢明な振る舞い
イベント通知は、使用されているキャッシュ トポロジに従って発生します。 イベント通知のトポロジに関する動作は次のとおりです。
ミラートポロジ: ミラー トポロジでは、クラスターのアクティブ ノードがクライアントにイベントを通知する役割を果たします。
複製されたトポロジー: レプリケートされたトポロジでは、クライアントに接続されているクラスター内のノードがイベント通知を生成します。
パーティション-レプリカ トポロジ: パーティション レプリカ トポロジでは、イベントはアクティブ ノードから発生します。 基準ベースのデータが存在するノードは、イベント通知を担当します。
パーティション化されたトポロジ: パーティショントポロジでは、イベントはすべてのノードから発生します。 基準ベースのデータが存在するノードは、イベント通知を担当します。
も参照してください
。ネット: Alachisoft.NCache.ランタイム.イベント 名前空間
Java: comの。alachisoft.ncache.イベント 名前空間
Node.js: イベントキャッシュアイテム とに提供されます。
Python: ncache.runtime.caching.events とに提供されます。