個別のキャッシュホストプロセス
以前は、 NCache サービスとすべてのキャッシュ インスタンスは XNUMX つのプロセス内に限定されていました。 これは、プロセスがクラッシュすると、サービスとともにキャッシュとそのリソース情報 (メモリ、アドレス、ポート) が失われることを意味します。
NCache は、サービス専用の別のプロセスと各キャッシュ ホスト専用のプロセスを使用することで、より高い信頼性を提供できるようになりました。
Note
この機能は以下でも利用できます NCache Professional.
クライアントとキャッシュの通信
クライアントとキャッシュ ホストとの最初の通信は 2 ホップ通信です。
まずサービスと対話し、ポート転送メカニズムを使用してクライアントをキャッシュ ホストに接続します。
次に、ポート転送を使用してキャッシュと通信します。 クライアントに対する今後のすべての対話は、キャッシュを使用して直接行われます。
キャッシュが独自の別のプロセスで開始されると、サービスが通信する管理ポートが割り当てられます。 このポートは範囲 (デフォルトは 8300 ~ 8400、設定可能) から動的に生成されます。 サービス.exe.config).
Note
パーティション-レプリカ トポロジの場合、XNUMX つのポートが割り当てられることに注意してください。
ポートが転送されると、クライアントは、キャッシュへの項目の追加、キャッシュからの項目の取得や削除など、すべてのキャッシュ要求をキャッシュに送信します。
キャッシュ ホスト プロセスの 8301 つが停止した場合、そのキャッシュによって通信に使用されているポートは、使用可能なポートのプールに追加されて戻されます。 たとえば、パーティション レプリカ ノードがポート 8302 と 8301 を使用していてプロセスが終了した場合、そのポートは他のキャッシュで使用できるようになります。 新しいキャッシュのプロセスが開始されると、ポート XNUMX をこのキャッシュに再利用できるようになりました。
以前は、ポートがキャッシュに割り当てられると、キャッシュの状態に関係なく、そのポートは使用されていると見なされていました。 これは、ポート範囲が意図せず狭まっていることを意味します。
サーバーとキャッシュの通信
サーバーは、動的に生成された管理ポート上のキャッシュ ホストと通信します。 すべての管理操作はこの経路を通じて行われます。
サービスが再起動した場合はどうなりますか?
サービスが再起動された場合、キャッシュ プロセスは失われませんが、キャッシュ プロセスは失われません。 redis以前の状態が発生することをカバーします。 これは、サービスがクラッシュする前にどのキャッシュが実行されていたかを、プロセス ID やポートなどの資格情報とともに確認する必要があることを意味します。 これ redisその結果、covery はキャッシュ プロセスがゾンビ状態にないことを保証します。
に使用されるXNUMXつのツールがあります redisカバー:
Windows Management Instrumentation サービス (WMI)
エンタープライズ環境内のデバイス、アプリケーション、およびサーバーの管理情報にアクセスし、統合し、共有するための標準化されたサービス。 次のいずれかを実行できます。 winmgmt.exe ツールまたはコマンドラインツール WMIC サービスに関する情報を取得するため。
例:
wmic PROCESS WHERE (Description=”Alachisoft.NCache.Service.exe”)
を使用して、他の複数のコマンドを操作できます。 Windows Management Instrumentation コマンド ライン ツール.
netstatツール
このコマンド ライン ツールは、受信および送信 TCP 通信のネットワーク接続、ルーティング テーブル、およびネットワーク プロトコル統計を表示します。 あなたはできる redisアクティブな接続と使用されているポートを表示することで、キャッシュに関する失われた情報をカバーします。 ポート範囲内の任意のポート サービス.exe.config ポートを使用しているキャッシュホストを示します。
例:
netstat –o
アクティブな各接続のローカル アドレス、外部アドレス、状態、およびプロセス ID が表示されます。
このツールに関する詳細は、から入手できます。 Microsoft の Technet ページ。