JP2012528382A - キャッシュクラスタを構成可能モードで用いるキャッシュデータ処理 - Google Patents

Abstract

キャッシュデータを処理することは、複数のキャッシュサービス・ノードを含むキャッシュクラスタ内のマスタ・キャッシュサービス・ノードに、キャッシュ処理要求を送信することを含んでいる。そのキャッシュクラスタは、複数のキャッシュサービス・ノードのすべてが稼働状態にあって、マスタ・キャッシュサービス・ノードが複数のキャッシュサービス・ノードの中から選択されるアクティブ・クラスタ構成モードか、あるいは、複数のキャッシュサービス・ノードの中で唯一稼働状態にあるノードがマスタ・キャッシュサービス・ノードであるスタンバイ・クラスタ構成モードに構成可能である。キャッシュデータの処理は、さらに、マスタ・キャッシュサービス・ノードからの応答を待つこと、マスタ・キャッシュサービス・ノードに障害が発生したか否か判断すること、および、マスタ・キャッシュサービス・ノードに障害が発生した場合にバックアップ・キャッシュサービス・ノードを選択することを含んでいる。
【選択図】図１２

Description

［他の出願の相互参照］
本出願は、全ての目的のために参照により本明細書に組み込まれる、発明の名称を“ＭＥＴＨＯＤ，ＳＹＳＴＥＭ ＡＮＤ ＤＥＶＩＣＥ ＦＯＲ ＣＡＣＨＥ ＤＡＴＡ ＰＲＯＣＥＳＳＩＮＧ（キャッシュデータ処理の方法、システムおよびデバイス）”とする、２００９年５月２５日に出願された中華人民共和国特許出願番号２００９１０１４３７３６．３に基づく優先権を主張する。

本出願は、概して、ネットワーク技術の分野に関し、より具体的には、キャッシュデータ処理に関するものである。

分散キャッシュとは、分散システムのメモリにデータを保存することである。キャッシュするコンテンツを物理的に分離されたキャッシュサービス・ノードに分散させることで、イベント駆動型アプリケーションにおいて、高い可用性、高いパフォーマンス、およびスケーラビリティを実現することができる。イベント駆動型サードパーティ・アプリケーションは、出力イベントをいくつかの分散キャッシュに分散させることができ、これにより、結果の高可用性を確保することができる。多くのイベント駆動型サードパーティ・アプリケーションは、ストリームデータを、永続記憶装置から取得したデータなどの外部データと結合する必要がある。キャッシングを利用することで、非ストリームデータへのアクセス速度を向上させることができ、ひいてはアプリケーション全体のパフォーマンスを向上させることができる。このため、キャッシングは、インターネットベースのアプリケーションおよび大規模ウェブサイトのアーキテクチャ設計において広く用いられている。

現在の分散キャッシュには、一般的に、サーバ分散キャッシュとクライアント分散キャッシュとが含まれる。データは、所定のアルゴリズムによりキャッシュサービス・ノードに分散される。キャッシュサービス・ノードが異常動作すると、そのキャッシュサービス・ノードのすべてのデータが失われることがある。さらに、キャッシュサービス・ノードの障害によって、正常なサービスが中断されることがある。また、データは所定のアルゴリズムによりキャッシュサービス・ノードに分散されるので、ひとたびキャッシュサービス・ノードが異常動作し始めると、そのキャッシュサービス・ノードに分散される更なる要求は受け付けられなくなる。

本発明の様々な実施形態は、以下の詳細な説明および添付の図面において開示される。

典型的なサーバ分散キャッシュを示す図である。

典型的なクライアント分散キャッシュの構造図である。

キャッシュ処理方法の一実施形態を示すフローチャートである。

クラスタ内の複数のキャッシュサービス・ノードがアクティブ・クラスタ構成モードにあるときのキャッシュ要求処理プロセスの一実施形態を示すフローチャートである。

マスタ・キャッシュサービス・ノードを選択するプロセスの一実施形態を示すフローチャートである。

キャッシュサービス・ノードがスタンバイ・クラスタ構成モードに構成されているキャッシュクラスタにおけるキャッシュデータ処理プロセスの一実施形態を示すフローチャートである。

アクティブ構成モードでのキャッシュデータ処理プロセスの一実施形態において用いられるメッセージおよびステップを示すフローチャートである。

非同期処理プロセスの一実施形態を示すフローチャートである。

アクティブ構成モードでのキャッシュデータ処理プロセスの一実施形態において用いられるメッセージおよびステップを示すフローチャートである。

障害タグが付けられたキャッシュサービス・ノードについてハートビート検出を実行するプロセスの一実施形態を示すフローチャートである。

障害タグが付けられていないキャッシュサービス・ノードについてハートビート検出を実行するプロセスの一実施形態を示すフローチャートである。

データキャッシング・システムの一実施形態を示すブロック図である。

キャッシュ・クライアントの一実施形態を示すブロック図である。

アクティブ・クラスタ構成モードにあるキャッシュ・クライアントを示すブロック図である。

スタンバイ・クラスタ構成モードにあるキャッシュ・クライアントを示すブロック図である。

容量拡張が可能なキャッシュ・ノードを示す図である。

本発明は、数多くの方法で実施することが可能であり、それには、プロセス、装置、システム、組成物、コンピュータ読み取り可能な記憶媒体上で実現されるコンピュータプログラム・プロダクトとしての実施、および／または、プロセッサに結合されたメモリに記憶された命令および／またはそれにより提供される命令を実行するように構成されたプロセッサなど、プロセッサとしての実施が含まれる。本明細書では、このような実施の形態、あるいは本発明が取り得るその他の形態を、技術と呼ぶ場合がある。一般的に、開示されるプロセスのステップの順序は、発明の範囲内で変更することができる。特に明記しない限り、タスクを実行するように構成されたものとして記載されるプロセッサまたはメモリなどのコンポーネントは、所与の時間に一時的にそのタスクを実行するように構成された汎用コンポーネント、あるいはそのタスクを実行するように作製された専用コンポーネントとして実現することができる。本明細書において用いられる場合の「プロセッサ」
という用語は、コンピュータプログラム命令などのデータを処理するように構成された１つまたは複数のデバイス、回路、および／または処理コアを指している。

本発明の１つまたは複数の実施形態についての詳細な説明が、以下で、本発明の原理を示す添付図面と共に提供される。本発明は、それらの実施形態に関連させて説明されるが、本発明は、いずれの実施形態にも限定されるものではない。本発明の範囲は、請求項によってのみ限定されるものであり、本発明は、多くの代替案、変形、および均等物を包含している。発明についての完全な理解を与えるため、様々な具体的詳細が以下の説明において記載される。これらの詳細は、例示目的で提供されるものであり、本発明は、これら特定の詳細の一部または全部を省いて、請求項に基づき実施することができる。明確にする目的で、発明が不必要に不明瞭になることがないよう、本発明に関連する技術分野で知られている技術的事項については詳細に記載していない。

図１は、典型的なサーバ分散キャッシュを示す図である。このシステムは、キャッシュ・クライアント、キャッシュ・ノードＡ、キャッシュ・ノードＢ、およびキャッシュ・ノードＣを含んでいる。分散オペレーションは、キャッシュ・ノードＢでサーバにより実行される。ノード間で通信プロトコルを実行するために、ＪＧｒｏｕｐｓによるマルチキャスト通信がしばしば用いられ、オペレーションおよびデータ同期は、通常、３段階のビジネスプロトコルにより実行される。この種の代表的なシステムは、ＪＢｏｓｓ ＣａｃｈｅおよびＥｈＣａｃｈｅを含んでいる。マルチキャスト通信は信頼性が低く、また、３段階のビジネスプロトコルは非常に複雑であるため、このような設定は、効率が低く、頻度および同時性の高い要求を処理しなければならないシステムには一般的に適さない。

図２は、典型的なクライアント分散キャッシュの構造図である。このシステムは、キャッシュ・クライアント、キャッシュ・ノードＡ、キャッシュ・ノードＢ、およびキャッシュ・ノードＣを含んでいる。キャッシュ・サーバは、分散型キャッシュである。異なるクライアントには異なるキーを配布することができ、これにより、拡張可能なクライアント分散キャッシュシステムを形成している。この種の代表的なシステムは、Ｍｅｍｃａｃｈｅｄシステムを含んでいる。この種のシステムは、拡張性に優れ、高効率であるが、フォールトトレラント機構を欠いている。データキャッシュサービス・ノードの一部に障害が発生すると、システムは、ビジネスシステムの正常な利用に影響するいくらかのデータを失う。Ｓｉｎａ Ｎｅｔｗｏｒｋにより開発されたオープンソースのＭｅｍｃａｃｈｅｄデータベースは、データをメモリデータベースまたはローカルハードディスクに保存することにより、データの完全性を保証するが、しかしながら、要求の同時性が高い環境では、フォールトトレランスあるいは負荷分散を高度に実現することができない。

以下で説明する実施形態では、マスタ・キャッシュサービス・ノードがキャッシュデータ処理の実行に失敗した場合、キャッシュ・クライアントが、そのマスタ・キャッシュサービス・ノードに障害タグを付けて、バックアップ・キャッシュサービス・ノードを選択し、そのバックアップ・キャッシュサービス・ノードにオペレーション要求を送る。本願は、クラスタ内に複数のキャッシュサービス・ノードを含むネットワークにおいて適用されるキャッシュデータ処理の方法を提供し、キャッシュサービス・ノードの障害の結果としてキャッシュサービス・ノードが利用不可能になるという問題およびデータ損失の問題を解決する。

図１２は、データキャッシング・システムの一実施形態を示すブロック図である。このシステムは、キャッシュ・クライアント１２０１、マスタ・キャッシュサービス・ノード１２０２、および１つまたは複数のバックアップ・キャッシュサービス・ノード１２０３を含んでいる。キャッシュ・クライアントは、コンピュータ、スマートフォンなどのモバイル機器、あるいは、ネットワークを介してマスタ・キャッシュサービス・ノード１２０２にオペレーション要求を送信し、マスタ・キャッシュサービス・ノード１２０２からオペレーション要求の結果を受信するように構成された他の適当なデバイスとして実現することができる。その結果が、マスタ・キャッシュサービス・ノード１２０２から受信したオペレーション要求が失敗したことを示している場合、あるいは要求がタイムアウトした場合、キャッシュ・クライアントは、バックアップ・キャッシュサービス・ノード１２０３を選択して、そのバックアップ・キャッシュサービス・ノード１２０３にオペレーション要求をリダイレクトするように構成されている。マスタ・キャッシュサービス・ノード１２０２は、キャッシュ・クライアント１２０１により送信されるキャッシュデータ処理要求を受信して、オペレーション結果をキャッシュ・クライアント１２０１にリターンするように構成されている。バックアップ・キャッシュサービス・ノード１２０３は、マスタ・キャッシュサービス・ノード１２０２に障害が発生した場合に、キャッシュ・クライアント１２０１により送信されるキャッシュデータ処理要求を受信する。

マスタ・キャッシュサービス・ノードとバックアップ・キャッシュサービス・ノードは、アクティブ・クラスタ構成モードあるいはスタンバイ・クラスタ構成モードに構成することができる。アクティブ・クラスタ構成モードでは、クラスタ内の複数のキャッシュサービス・ノードが稼働状態にあり、要求の処理が必要となるたびにマスタ・キャッシュサービス・ノードが選択される。１つのキャッシュサービス・ノードに障害が発生すると、他のキャッシュサービス・ノードで要求を共有する。スタンバイ・クラスタ構成モードでは、クラスタ内の複数のキャッシュサービス・ノードのうち、１つのみがマスタ・キャッシュサービス・ノードとして機能し、稼働状態にあるキャッシュサービス・ノードである。他のキャッシュサービス・ノードは、バックアップ状態にある。マスタ・キャッシュサービス・ノードに障害が発生すると、他のキャッシュサービス・ノードの１つがマスタ・キャッシュサービス・ノードに代わって新しいマスタ・キャッシュサービス・ノードとなって、要求を処理する。また、キャッシュサービス・ノードは、クラスタ内のキャッシュサービス・ノードの容量が不足しているときに動的にノードの容量を拡張できるように、仮想化されている。

図３は、キャッシュ処理方法の一実施形態を示すフローチャートである。このプロセス３００は、図１２の１２００のようなキャッシュ処理システムにおいて実行することができる。ステップ３０２において、キャッシュ・クライアントが、マスタ・キャッシュサービス・ノードにキャッシュ処理要求を送信する。ステップ３０４において、キャッシュ・クライアントは、マスタ・キャッシュサービス・ノードからの応答（すなわち、キャッシュ処理要求の結果）を待つ。ステップ３０６において、マスタ・キャッシュサービス・ノードがキャッシュデータ処理の実行に失敗したか否か判断される。受信した応答がエラーコード、不正確なチェックサムなどを含んでいる場合、あるいは応答がタイムアウトになった場合は、マスタ・キャッシュサービス・ノードは障害が発生したと判断される。この場合、ステップ３０８において、キャッシュ・クライアントにより、バックアップ・キャッシュサービス・ノードが新しいマスタ・キャッシュサービス・ノードとして選択されて、その後のキャッシュ処理要求は、そのバックアップ・キャッシュサービス・ノードへ送信される。そうでない場合は、その後のキャッシュ処理要求は、引き続き同じマスタ・キャッシュサービス・ノード宛てに送られる。

一部の実施形態では、クラスタ構成モードに、アクティブ・クラスタ構成モードとスタンバイ・クラスタ構成モードとが含まれる。アクティブ・クラスタ構成モードでは、クラスタ内の複数のキャッシュサービス・ノードが稼働状態にあり、それらが共同で要求を処理し、マスタ・キャッシュサービス・ノードは必ずしも１つだけではない。１つのキャッシュサービス・ノードに障害が発生すると、その他のキャッシュサービス・ノードで、引き続き要求の処理を共有する。要求が処理されるときには、クラスタ内のノードのデータ同期化が実行される。スタンバイ・クラスタ構成モードでは、クラスタ内の複数のキャッシュサービス・ノードのうち１つのキャッシュサービス・ノードのみが稼働状態にあって、マスタ・キャッシュサービス・ノードとして機能しており、他のキャッシュサービス・ノードは、すべてバックアップ状態にある。マスタ・キャッシュサービス・ノードに障害が発生すると、バックアップ・キャッシュサービス・ノードの１つが、新しいマスタ・サービス・ノードとして選択されて、これが、キャッシュ処理要求を受信して処理し、クラスタ内のノードのデータ同期化を定期的に実行する。アクティブ・クラスタ構成モードおよびスタンバイ・クラスタ構成モードによって、ネットワーク全体の自動障害リカバリが可能となり、また、キャッシュ・クライアントによる無中断のデータアクセスが確保される。

図４は、クラスタ内の複数のキャッシュサービス・ノードがアクティブ・クラスタ構成モードにあるときのキャッシュ要求処理プロセスの一実施形態を示すフローチャートである。このプロセスは、キャッシュ・クライアントにおいて実行することができる。

ステップ４０２において、キャッシュ・クライアントは、アルゴリズムにより、あるいはクライアントの構成に応じて、クラスタ内の複数のキャッシュサービス・ノードからマスタ・キャッシュサービス・ノードを選択する。クラスタ内のキャッシュサービス・ノードに障害が発生した場合、その障害が発生したノードは、障害状態を保持する。この情報は、他のキャッシュサービス・ノードにブロードキャストされるか、あるいはネットワーク上の指定の記憶場所に保存されるものとすることができる。キャッシュ・クライアントは、キャッシュサービス・ノードに問合せすることにより、あるいは指定の場所から情報を取り出すことにより、障害状態のタグが付けられたキャッシュサービス・ノードを得る。一部の実施形態では、キャッシュ・クライアントは、さらに、ネットワーク上の利用可能なキャッシュサービス・ノードを得る。キャッシュ・クライアントは、利用可能なキャッシュサービス・ノードから１つのキャッシュサービス・ノードを、新しいマスタ・キャッシュサービス・ノードとして選択する。選択方法の例には、動的負荷分散選択、ハッシュ法、またはコンシステント・ハッシュ法が含まれる。

マスタ・キャッシュサービス・ノードを選択した後に、ステップ４０４で、キャッシュ・クライアントは、キャッシュデータ処理要求をマスタ・キャッシュサービス・ノードに送信する。

ステップ４０６において、キャッシュ・クライアントは、マスタ・キャッシュサービス・ノードからの応答を待つ。ステップ４０８において、マスタ・キャッシュサービス・ノードがキャッシュデータ処理の実行に失敗したか否か判断される。要求が正常に処理されたことを応答が示している場合、その後のキャッシュ処理要求は、ステップ４０４において、引き続き同じマスタ・キャッシュサービス・ノード宛てに送られる。

受信した応答がエラーコード、不正確なチェックサムなどを含んでいる場合、あるいは応答がタイムアウトした場合は、マスタ・キャッシュサービス・ノードは障害が発生したと判断される。一部の実施形態では、マスタ・キャッシュサービス・ノードがキャッシュデータ処理の実行に失敗すると、キャッシュ・クライアントは、マスタ・キャッシュサービス・ノードに関連する失敗オペレーション回数をインクリメントする。失敗オペレーション回数は所定の閾値と比較される。失敗オペレーション回数が閾値を超えている場合、マスタ・キャッシュサービス・ノードは、障害状態のマークが付けられる。一部の実施形態では、障害が発生したノードに対して障害期間が設定され、この間は、その障害ノードを利用できないが、リセットまたはリカバリにより再び利用可能になる機会があるとされる。

マスタ・キャッシュサービス・ノードに障害が発生した場合、ステップ４１０において、キャッシュ・クライアントは、アルゴリズムにより、あるいは構成に応じて、バックアップ・キャッシュサービス・ノードを新しいマスタ・キャッシュサービス・ノードとして選択し、その後のキャッシュ処理要求は、そのバックアップ・キャッシュサービス・ノードに送信する。

一部の実施形態では、キャッシュ・クライアントは、実行されるべきタスクを保持するクラスタ・オペレーション・タスク・キューと、クラスタのキャッシュサービス・ノードにオペレーションを実行させるために用いられるスレッドを管理するタスク実行スレッド・プールとを用いて、非同期処理を実現する。要求オペレーションに成功すると、キャッシュ・クライアントは、オペレーション結果をキャッシュし、そのオペレーションとオペレーション結果をクラスタ・オペレーション・タスク・キューに保存する。タスク実行スレッド・プールは、マスタ・キャッシュサービス・ノードへの要求の送信およびそこからの応答の受信に用いられるスレッドを管理し、また、他のキャッシュサービス・ノードによりオペレーションが処理されることがないようにしている。

アクティブ・クラスタ構成モードでは、マスタ・キャッシュサービス・ノードに障害が発生すると、その障害が発生したマスタ・キャッシュサービス・ノードの代わりとなるバックアップ・キャッシュサービス・ノードが選択される。障害が発生したマスタ・キャッシュサービス・ノードが回復すると、クラスタ・オペレーション・タスク・キューは、バックアップ・キャッシュサービス・ノードにより実行されたオペレーションおよびそのオペレーション結果を、マスタ・キャッシュサービス・ノードにリターンする、あるいはコピーする。一方、マスタ・キャッシュサービス・ノードは再び稼働状態となって、バックアップ・キャッシュサービス・ノードは、もはや代理のマスタ・キャッシュサービス・ノードとして機能しなくなる。この非同期処理は、さらに、マスタ・サービス・ノードに障害が発生していない場合に、マスタ・キャッシュサービス・ノードにより実行されたオペレーションを他のすべてのキャッシュサービス・ノードで更新するために用いられる。つまり、アクティブ・クラスタ構成モードでは、オペレーションが進行すると、マスタ・キャッシュサービス・ノードまたはバックアップ・キャッシュサービス・ノードのどちらかが、そのオペレーションおよびオペレーション結果をクラスタ・オペレーション・タスク・キューに保存し、クラスタ内の他のすべてのキャッシュサービス・ノードのデータ非同期処理の実行を待つ。これによって、クラスタ内のすべてのキャッシュサービス・ノードのデータ整合性が確保される。

オペレーション結果に基づきオペレーションが失敗したと判断される場合は、キャッシュ・クライアントは、そのバックアップ・キャッシュサービス・ノードを障害インジケータでマークして、バックアップ・キャッシュサービス・ノードを再選択する。

一部の実施形態では、ステップ４０２において、マスタ・キャッシュサービス・ノードは、動的負荷分散選択法を用いて選択される。図５は、マスタ・キャッシュサービス・ノードを選択するプロセスの一実施形態を示すフローチャートである。このプロセスは、キャッシュ・クライアントにより実行することができる。

ステップ５０２において、キャッシュ・クライアントは、キャッシュサービス・ノードに問合せすることにより、利用可能キャッシュサービス・ノードのパラメータを取得する。これらのパラメータには、キャッシュサービス・ノードの処理能力指標Ｗ［ｉ］、キャッシュサービス・ノードの現在の総キャッシュデータ量Ｃ［ｉ］、およびキャッシュサービス・ノードの要求応答時間Ｒ［ｉ］が含まれる。

ステップ５０４においては、取得した利用可能キャッシュサービス・ノードのパラメータが、昇順または降順にソートされる。例えば、Ｆ（Ｋ［ｉ］,｛Ｋ［１］ ．．．Ｋ［Ｎ］｝, ＡＳＣ）は、配列｛Ｋ［１］ ．．．Ｋ［Ｎ］｝が昇順にまずソートされて、その結果Ｋ［ｉ］の添字の位置に返されることを示している。同様に、Ｆ（Ｋ［ｉ］,｛Ｋ［１］ ．．．Ｋ［Ｎ］｝, ＤＥＳＣ）は、配列｛Ｋ［１］ ．．．Ｋ［Ｎ］｝が降順にまずソートされて、その結果Ｋ［ｉ］の添字の位置に返されることを示している。

ステップ５０６においてパラメータ式が計算される。一部の実施形態では、キャッシュサービス・ノードを選択するための加重計算式は次のようなものである。

Ｍａｘ（Ｆ（Ｗ［ｉ］,｛Ｗ［１］ ．．．Ｗ［Ｎ］｝, ＡＳＣ）＊２５％＋Ｆ（Ｃ［ｉ］,｛Ｃ［１］ ．．．Ｃ［Ｎ］｝， ＤＥＳＣ）＊２５％＋Ｆ（Ｒ［ｉ］,｛Ｒ［１］ ．．．Ｒ［Ｎ］｝，ＤＥＳＣ）＊５０％）。

上記の式によると、処理能力について、その処理能力ができる限り大きくあるべきであるということが２５％、総キャッシュコンテンツ量について、その総キャッシュコンテンツ量ができる限り少なくあるべきであるということが２５％、そして応答時間について、その応答時間ができる限り短くあるべきであるということが５０％を占める。

ステップ５０８において、計算結果に基づきマスタ・キャッシュサービス・ノードが選択される。ステップ５０６において示した式が用いられる例では、最大値をもつキャッシュサービス・ノードが選択される。

図６は、キャッシュサービス・ノードがスタンバイ・クラスタ構成モードに構成されているキャッシュクラスタにおけるキャッシュデータ処理プロセスの一実施形態を示すフローチャートである。このプロセス６００は、クライアントがマスタ・キャッシュサービスを選択する必要がないことを除けば、プロセス４００に類似している。代わりに、クラスタ内のマスタ・キャッシュサービス・ノードが既に指定されている。一部の実施形態では、クラスタ内のキャッシュサービス・ノードは、障害またはリカバリを経験すると、順序リストで削除または追加される。この場合、マスタ・キャッシュサービス・ノードは、順序リストでのノードの位置に基づき指定される。つまり、キャッシュサービス・ノードは、それらのキャッシュサービス・ノードが順序列に追加された順番で配列され、順序列で最初のものがマスタ・キャッシュサービス・ノードとして指定される。マスタ・キャッシュサービス・ノードに障害が発生すると、順序列で次のキャッシュサービス・ノードが、新しく指定されるマスタ・キャッシュサービス・ノードとなり、一方、障害が発生した旧マスタ・キャッシュサービス・ノードは、順序列から削除されて、回復したら順序列の最後尾に追加される。

一部の実施形態では、データセキュリティ要件が高く、かつ、読み出し／書き込み比の高いシステムにおいて、アクティブ・クラスタ構成モードが用いられる。図７は、アクティブ構成モードでのキャッシュデータ処理プロセスの一実施形態において用いられるメッセージおよびステップを示すフローチャートである。この例では、ネットワークは、アプリケーション（多くの場合、サードパーティ・アプリケーション）、キャッシュ・クライアント、キャッシュ・ノードＡおよびＢを含んでいる。他の実施形態において、追加のキャッシュ・ノードを用いることができる。サードパーティ・アプリケーションがキャッシュ処理を必要とする場合、すなわち、そのサードパーティ・アプリケーションがキャッシュデータ読み出しまたはキャッシュデータ処理の要求を送信する場合に、動的負荷分散法に従ってキャッシュ・クライアントによりキャッシュデータ処理実行用に選択されたキャッシュ・ノードＡに障害が発生したら、キャッシュ・クライアントは、キャッシュ・ノードＢをキャッシュデータ処理実行用に選択する。キャッシュ・ノードＢがキャッシュデータ処理を正常に実行すると、データ非同期処理が実行される。

図示の例では、ステップ７０１において、アプリケーションが、キャッシュデータ読み出しまたはキャッシュデータ処理の要求をキャッシュ・クライアントに送信する。

ステップ７０２において、キャッシュ・クライアントが、アプリケーションにより送信された要求を受信して、利用可能なキャッシュサービス・ノードを確認する。クラスタ内のキャッシュサービス・ノードに障害が発生した場合、その障害が発生したノードに障害タグが関連付けられて保存される。キャッシュ・クライアントは、すべてのキャッシュサービス・ノードの状態を調べて、そして、それらの障害タグに基づきキャッシュサービス・ノードが利用可能であるかどうか判断する。キャッシュ・クライアントは、障害タグ無しのキャッシュサービス・ノードが、利用可能なキャッシュサービス・ノードであることを確認する。キャッシュ・クライアントは、利用可能なキャッシュサービス・ノードが見つからないときは、サードパーティ・アプリケーションにエラー情報を送信する。キャッシュ・クライアントは、１つまたは複数の利用可能なキャッシュサービス・ノードを見つけると、図５の５００と同様のプロセスを用いてマスタ・キャッシュサービス・ノードを選択することによりステップ７０３を実行する。

この例では、キャッシュ・クライアントは、キャッシュ・ノードＡをマスタ・キャッシュサービス・ノードとして選択する。ステップ７０４で、キャッシュ・クライアントは、キャッシュ・ノードＡにキャッシュデータ処理要求を送信する。あるいは代わりに、キャッシュ・ノードＢをマスタ・キャッシュサービス・ノードとして選択することができ、以下で説明する処理ステップが同じように適用可能である。

ステップ７０５において、キャッシュ・ノードＡは、キャッシュ・クライアントにより送信されたオペレーション要求を受信して、キャッシュデータ処理を実行する。ステップ７０６において、キャッシュ・ノードＡは、オペレーション要求を完了すると、オペレーション結果をキャッシュ・クライアントにリターンする。

ステップ７０７において、キャッシュ・クライアントは、リターンされたオペレーション結果に基づき、マスタ・キャッシュサービス・ノードに障害が発生したかどうか判断する。

キャッシュ・ノード自体の障害の他に、オペレーションの失敗の原因となる他の多くの理由（たとえば、ネットワーク接続の不具合）があり得る。このため、キャッシュ・ノードＡは、障害が発生したとして直ちにタグが付けられるわけではない。その代わりに、障害カウンタがキャッシュ・ノードに関連付けられて、オペレーションに失敗したと見なされるたびにカウントがインクリメントされる。障害カウンタには閾値Ｎが設定されている。記録された障害回数が閾値Ｎを超えている場合に、キャッシュ・クライアントは、障害が発生したとしてキャッシュ・ノードＡの状態にタグを付ける。

ステップ７０９において、キャッシュ・クライアントは、アプリケーションにより送信された要求を受信し、利用可能なバックアップ・キャッシュサービス・ノードを確認する。

障害の発生したキャッシュサービス・ノードに関連付けられた障害タグは、キャッシュ・クライアントにより保持されるか、あるいはネットワーク上に保存される。キャッシュ・クライアントは、ネットワーク内で障害タグが付けられていない利用可能なキャッシュサービス・ノードを探す。キャッシュ・クライアントが利用可能なキャッシュサービス・ノードを見つけられなかった場合、キャッシュ・クライアントは、アプリケーションにエラー情報を送信する。そうではなくて、利用可能なキャッシュサービス・ノードを見つけた場合、ステップ７１０において、キャッシュ・クライアントは、動的負荷分散法、ハッシュ法、またはコンシステント・ハッシュ法などの適当な方法を用いて、利用可能なキャッシュサービス・ノードから１つのキャッシュサービス・ノードをバックアップ・キャッシュサービス・ノードとして選択する。

ステップ７１５において、マスタ・キャッシュサービス・ノードからの応答は、オペレーションが成功したことを示しており、キャッシュ・クライアントは、オペレーションおよびその結果をクラスタ・タスク・キューに保存する。そのオペレーションが取得オペレーションであって、新しいデータをキャッシュする必要がある場合には、そのデータがキャッシュされ、データに有効期間が関連付けられる。

ステップ７１６において、キャッシュ・クライアントは、そのオペレーションの結果をアプリケーションにリターンする。

キャッシュ・クライアントがオペレーションおよびオペレーション結果をクラスタ・オペレーション・タスク・キューに保存するステップ７１５の後で、非同期データリカバリおよび非同期データコピーを含む非同期処理を、タスク・キューとスレッド・プールの併用によって実現することができる。

図８は、非同期処理プロセスの一実施形態を示すフローチャートである。図示の例では、クラスタ・オペレーション・タスク・キュー、タスク・コンシューマ、およびタスク実行スレッド・プールを含むデータ構造を用いることで、キャッシュ・クライアントによる要求の処理を非同期的に進めやすくしている。

ステップ８０１において、キャッシュ・クライアントは、キャッシュサービス・ノードにより実行されるべきオペレーションをクラスタ・オペレーション・タスク・キューに記録する。そのオペレーションは、マスタとしてのキャッシュサービス・ノードを更新するための更新オペレーション、あるいはキャッシュデータの取得が必要である取得オペレーションとすることができる。

ステップ８０２において、タスク・コンシューマが、クラスタ・オペレーション・タスク・キューにメッセージを送信して、キューに新しいタスクがあるかどうか問い合わせする。もしある場合は、ステップ８０３において、タスク・コンシューマは、そのタスクをタスク実行スレッド・プールに送信する。タスクが送信されると、ステップ８０４において、クラスタ・オペレーション・タスク・キューは、そのタスクを削除する。

ステップ８０５において、タスク実行スレッド・プールは、タスクの順序、タスクの宛先、およびタスクの内容に基づきタスクを分析して、そのタスクを非同期的に処理するためのタスク実行スレッドを設定する。

ステップ８０６において、タスク実行スレッド・プールは、そのタスク実行スレッドを用いて非同期処理を実行する。そのオペレーションがキャッシュコンテンツを取得するための取得オペレーションである場合は、そのオペレーションおよび関連するデータがクラスタに送信される。そのオペレーションを指示されたキャッシュサービス・ノードのみがオペレーションを実行することができ、他のキャッシュサービス・ノードがオペレーションを実行することはできない。

そのオペレーションがキャッシュサービス・ノードの障害状態を更新するための更新オペレーションである場合、そのオペレーションおよび関連するデータがクラスタにコピーされる。そのオペレーションを指示されたキャッシュサービス・ノードのみがオペレーションを実行することができ、他のキャッシュサービス・ノードがオペレーションを実行することはできない。

ステップ８０７において、クラスタ・キャッシュサービス・ノードは、オペレーションの結果をタスク実行スレッド・プールに送る。

ステップ８０８において、タスク実行スレッド・プールは、オペレーション結果に基づいて、タスクが正常に実行されたか否か判断し、その判定結果に対処する。特に、タスクが失敗した場合には、その失敗に対処するため、いくつかの方法を実施することができる。例えば、そのタスクを単に破棄することができ、有限回の再試行をすることができ、あるいは、そのタスクを一時的に記憶して後に再試行することができる。

一部の実施形態では、データセキュリティ要件が低く、かつ信頼性の高いシステムにおいて、スタンバイ・クラスタ構成モードが適用される。このシステムは、アプリケーション、キャッシュ・クライアント、キャッシュ・ノードＡ、Ｂなどを含んでいる。マスタ・キャッシュサービス・ノードであるキャッシュ・ノードＡがオペレーションの実行に失敗すると、キャッシュ・クライアントは、バックアップ・キャッシュサービス・ノードであるキャッシュ・ノードＢに要求を送り、このノードがキャッシュデータ処理を実行し、それ自身でデータ同期を実行する。図９は、アクティブ構成モードでのキャッシュデータ処理プロセスの一実施形態において用いられるメッセージおよびステップを示すフローチャートである。

ステップ９０１において、アプリケーションが、キャッシュデータ読み出しまたはキャッシュデータ処理の要求をキャッシュ・クライアントに送信する。

ステップ９０２において、キャッシュ・クライアントが、アプリケーションにより送信された要求を受信して、マスタ・キャッシュサービス・ノードであるキャッシュ・ノードＡの状態をローカルキャッシュで調べる。障害状態が、有効期間制限を過ぎている場合は、障害タグが取り除かれる。

マスタ・キャッシュサービス・ノードに障害が発生していない場合は９０３が実行され、それ以外の場合はステップ９０４が実行される。ステップ９０３では、キャッシュ・クライアントが、キャッシュデータ処理要求をキャッシュ・ノードＡに送信する。ステップ９０４において、キャッシュ・ノードＡが、キャッシュ・クライアントにより送信されたキャッシュデータ処理要求を受信し、キャッシュ・ノードＡはキャッシュデータ処理を実行する。

キャッシュ・ノードＡがキャッシュデータ処理を実行した後に、ステップ９０５において、そのオペレーション結果がキャッシュ・クライアントに返される。ステップ９０６において、キャッシュ・クライアントは、返されたオペレーション結果に基づき、オペレーションが成功したかどうか判断する。ステップ９０７で、キャッシュ・クライアントは、オペレーションの成功または失敗に対処する。例えば、そのキャッシュ・ノードに関連付けられた障害カウンタにおいて、障害回数をインクリメントして、閾値Ｎと比較する。カウンタの障害回数が閾値Ｎを超えている場合は、キャッシュ・クライアントは、キャッシュ・ノードＡの状態に障害タグを付けて、その障害の有効期間を設定する。ステップ９０８において、キャッシュ・クライアントは、利用可能なキャッシュサービス・ノードから１つのバックアップ・キャッシュサービス・ノードを選択する。

クラスタ内のキャッシュサービス・ノードに障害が発生した場合、そのキャッシュサービス・ノードが自身の障害タグを保持する。キャッシュ・クライアントは、障害状態タグが付いていない利用可能なキャッシュサービス・ノードを識別し、１つの利用可能キャッシュサービス・ノードをバックアップ・キャッシュサービス・ノードとして選択する。キャッシュ・クライアントが、利用可能なキャッシュサービス・ノードを見つけられなかった場合、キャッシュ・クライアントは、アプリケーションにエラー情報を送信する。

この例では、Ａに障害が発生した場合に、マスタキャッシュ・ノードＡの代わりとしてバックアップ・キャッシュ・ノードＢが選択される状況についても、図に示している。その場合、ステップ９０９〜９１４が然るべく実行される。

以前のマスタ・キャッシュサービス・ノードＡが回復すると、それは、現在のマスタ・キャッシュサービス・ノードＢのバックアップ・キャッシュサービス・ノードとなる。このように、キャッシュ・ノードＡは、現在のバックアップ・キャッシュサービス・ノードとして機能して、非同期的データ同期処理のためのデータセット要求を現在のマスタ・キャッシュサービス・ノードＢへ送信する。具体的には、ステップ９１４（ａ）において、キャッシュ・ノードＡがキャッシュ・ノードＢにデータセット要求を送信し、ステップ９１４（ｂ）において、キャッシュ・ノードＢがキャッシュ・ノードＡにデータセット結果を返し、これによって、キャッシュ・ノードＡとキャッシュ・ノードＢの間のデータ同期化を実現することができる。

一部の実施形態では、スタンバイ・クラスタ構成モードにおいて、キャッシュ・クライアントが、クラスタ内のキャッシュサービス・ノードについて、定期的なハートビート検出を実行し、ハートビート検出の結果に基づいて、定期的にキャッシュサービス・ノードの状態を障害タグ付きまたは障害タグ無しに更新する。

キャッシュサービス・ノードに障害タグが付けられている場合、キャッシュ・クライアントは、そのキャッシュサービス・ノードについてハートビート検出を実行し、応答数が閾値を超えている場合、キャッシュ・クライアントは、そのキャッシュサービス・ノードの障害タグを取り除く。図１０は、障害タグが付けられたキャッシュサービス・ノードについてハートビート検出を実行するプロセスの一実施形態を示すフローチャートである。この例では、先の障害によって、キャッシュ・ノードＣに障害タグが付けられている。ステップ１００２において、キャッシュ・クライアントが、ハートビート検出データをキャッシュ・ノードＣに定期的に送信する。ステップ１００４において、キャッシュ、クライアントは、キャッシュ・ノードＣからの応答を待つ。ステップ１００６において、キャッシュ・クライアントは、キャッシュ・ノードＣがハートビート・データに正常に応答したかどうか判断する。不正確な応答コード、不正確なチェックサム、あるいは応答のタイムアウトは、失敗と解釈される。ステップ１００８において、キャッシュ・ノードＣがハートビート・データに正常に応答すると、キャッシュ・ノードＣに付けられている障害タグが取り除かれる。

キャッシュ・クライアントは、さらに、障害タグが付けられていないキャッシュサービス・ノードについてもハートビート検出を実行し、障害回数を追跡する。図１１は、障害タグが付けられていないキャッシュサービス・ノードについてハートビート検出を実行するプロセスの一実施形態を示すフローチャートである。この例では、キャッシュ・ノードＤには、現在のところ、障害タグが付けられてはいない。ステップ１１０２において、キャッシュ・クライアントは、ハートビート検出データをキャッシュ・ノードＤに定期的に送信する。ステップ１１０４において、キャッシュ、クライアントは、キャッシュ・ノードＤからの応答を待つ。ステップ１１０６において、キャッシュ・クライアントは、キャッシュ・ノードＤがハートビート・データに正常に応答したかどうか判断する。不正確な応答コード、不正確なチェックサム、あるいは応答のタイムアウトは、失敗と解釈される。応答が失敗であった場合は、ステップ１１０８において、キャッシュ・ノードＤに関連付けられた障害カウンタがインクリメントされる。ステップ１１１０において、障害カウンタの値が閾値Ｎを超えたかどうか判断される。もしそうである場合は、キャッシュ・ノードＤに障害タグが付けられる。

一部の実施形態では、１つの障害カウンタが、キャッシュサービス・ノードがハートビート検出への応答に失敗したときと、キャッシュサービス・ノードがキャッシュ要求の処理に失敗したときと、その両方に用いられる。

図１３は、キャッシュ・クライアントの一実施形態を示すブロック図である。この例では、キャッシュ・クライアントは、キャッシュデータの処理が必要であるときにオペレーション要求をマスタ・キャッシュサービス・ノードに送信するために用いられる要求送信ユニット１３０１を含んでいる。さらに、結果受信ユニット１３０２を含み、これは、マスタ・キャッシュサービス・ノードにより要求送信ユニット１３０１に送信されるオペレーション要求のオペレーション結果を受信するために用いられるものである。さらに、キャッシュサービス・ノード選択ユニット１３０３を含んでいる。上記の結果受信ユニットにより受信したオペレーション結果に基づいて、上記マスタ・キャッシュサービス・ノードがキャッシュデータ処理の実行に失敗したと判断されたら、キャッシュサービス・ノード選択ユニットが、１つのバックアップ・キャッシュサービス・ノードを選択し、要求送信ユニットは、その選択されたバックアップ・キャッシュサービス・ノードにオペレーション要求を送信する。

図１４は、アクティブ・クラスタ構成モードにあるキャッシュ・クライアントを示すブロック図である。この例に示すキャッシュ・クライアント１４００は、キャッシュデータの処理が必要であるときにオペレーション要求をマスタ・キャッシュサービス・ノードに送信するために用いられる要求送信ユニット１４０１と、さらに、結果受信ユニット１４０２を含み、これは、マスタ・キャッシュサービス・ノードにより要求送信ユニット１４０２に送信されるオペレーション要求のオペレーション結果を受信するために用いられる。

キャッシュ・クライアントは、さらに、障害タグ付けユニット１４０３を含んでおり、これは、結果受信ユニット１４０２により受信したオペレーション結果に基づき、マスタ・キャッシュサービス・ノードがキャッシュデータ処理の実行に失敗したと判断される場合に、マスタ・キャッシュサービス・ノードに障害タグを付けるために用いられる。この障害タグ付けユニット１４０３は、マスタ・サービス・ノードがキャッシュデータ処理の実行に失敗したときにキャッシュ・クライアントの障害回数をインクリメントするために用いられるカウンタ・サブユニット１４０３１と、カウンタ・サブユニット１４０３１により積算された障害回数を閾値と比較して、障害回数が閾値を超えている場合にマスタ・キャッシュサービス・ノードに障害タグを付けるために用いられる障害タグ付けサブユニット１４０３２と、障害タグ付けサブユニット１４０３２によりマスタ・キャッシュサービス・ノードに障害タグが付けられた後にマスタ・キャッシュサービス・ノードの障害有効期間を設定するために用いられる障害有効期間設定サブユニット１４０３３と、を含んでいる。

キャッシュ・クライアントは、さらに、バックアップ・キャッシュサービス・ノードを選択しバックアップ・キャッシュサービス・ノードにオペレーション要求を送信するために用いられるキャッシュサービス・ノード選択ユニット１４０４を含んでいる。キャッシュサービス・ノード選択ユニット１４０４は、障害タグ付けサブユニットにより障害タグが付けられたキャッシュサービス・ノードに基づきネットワークにおいて利用可能なキャッシュサービス・ノードを取得するために用いられる利用可能キャッシュサービス・ノード取得サブユニット１４０４１と、利用可能キャッシュサービス・ノード取得サブユニット１４０４１により取得された利用可能キャッシュサービス・ノードから、適当な方法により１つのキャッシュサービス・ノードをバックアップ・キャッシュサービス・ノードとして選択するために用いられるキャッシュサービス・ノード選択サブユニット１４０４２とを含んでいる。キャッシュサービス・ノード選択ユニット１４０４は、さらに、マスタ・キャッシュサービス・ノードを選択するためにも用いられ、その選択されたマスタ・キャッシュサービス・ノードに、要求送信ユニット１４０１がオペレーション要求を送信する。

要求送信ユニット１４０１は、また、キャッシュデータの処理が必要であるときにバックアップ・キャッシュサービス・ノードに対してオペレーション要求を送信するためにも用いられる。

結果受信ユニット１４０２は、さらに、要求送信ユニット１４０１によりバックアップ・キャッシュサービス・ノードに送信されるオペレーション要求のオペレーション結果を受信するためにも用いられる。

障害タグ付けユニット１４０３は、さらに、結果受信ユニット１４０２により受信されたオペレーション結果に基づきオペレーションが失敗したと判断される場合に、バックアップ・キャッシュサービス・ノードに障害タグを付けるためにも用いられる。

キャッシュ・クライアント１４００は、さらに、結果受信ユニット１４０２により受信したバックアップ・キャッシュサービス・ノードからのオペレーション要求のオペレーション結果に応じて処理を行うために用いられるオペレーション結果処理ユニット１４０５を含んでいる。オペレーション結果処理ユニット１４０５は、キャッシュ・クライアントの結果受信ユニット１４０２により受信したオペレーション結果に基づきオペレーションに成功したと判断される場合に、マスタ・キャッシュサービス・ノードについて非同期処理を実行するために用いられる非同期処理サブユニット１４０５１を含んでいる。この非同期処理サブユニット１４０５１は、オペレーションが成功し、そのオペレーションが取得オペレーションである場合に用いられ、オペレーション結果をキャッシュ・クライアントにキャッシュし、オペレーションおよびオペレーション結果をクラスタ・オペレーション・タスク・キューに保存する。タスク実行スレッド・プールが、オペレーションおよびオペレーション内容をクラスタに返して、そのオペレーションが他のキャッシュサービス・ノードにより実行されないようにする。さらに、非同期処理サブユニットは、オペレーションが成功し、そのオペレーションが更新オペレーションである場合に用いられ、オペレーションおよびオペレーション結果をクラスタ・オペレーション・タスク・キューに保存する。タスク実行スレッド・プールは、オペレーションおよびオペレーション内容をクラスタにコピーして、そのオペレーションが他のキャッシュサービス・ノードにより実行されないようにする。

図１５は、スタンバイ・クラスタ構成モードにあるキャッシュ・クライアントを示すブロック図である。この例に示すキャッシュ・クライアント１５００は、キャッシュデータの処理が必要であるときにオペレーション要求をマスタ・キャッシュサービス・ノードに送信するために用いられる要求送信ユニット１５０１と、さらに、結果受信ユニット１５０２を含み、これは、要求送信ユニット１５０２により送信されるマスタ・キャッシュサービス・ノードからのオペレーション要求のオペレーション結果を受信するために用いられる。

キャッシュ・クライアントは、さらに、障害タグ付けユニット１５０３を含んでおり、これは、結果受信ユニット１５０２により受信したオペレーション結果に基づき、マスタ・キャッシュサービス・ノードがキャッシュデータ処理の実行に失敗したと判断される場合に、マスタ・キャッシュサービス・ノードに障害タグを付けるために用いられる。この障害タグ付けユニット１５０３は、マスタ・サービス・ノードがキャッシュデータ処理の実行に失敗したときにキャッシュ・クライアントの障害回数を積算するために用いられるカウンタ・サブユニット１５０３１と、カウンタ・サブユニット１５０３１により積算された障害回数を閾値と比較して、障害回数が閾値を超えている場合にマスタ・キャッシュサービス・ノードに障害タグを付けるために用いられる障害タグ付けサブユニット１５０３２と、障害タグ付けサブユニット１５０３２によりマスタ・キャッシュサービス・ノードに障害タグが付けられた後にマスタ・キャッシュサービス・ノードの障害有効期間を設定するために用いられる障害有効期間設定サブユニット１５０３３と、を含んでいる。

キャッシュ・クライアントは、さらに、バックアップ・キャッシュサービス・ノードを選択するために用いられるキャッシュサービス・ノード選択ユニット１５０４と、その選択されたバックアップ・キャッシュサービス・ノードに対してオペレーション要求を送信する要求送信ユニット１５０１とを含む。

要求送信ユニット１５０１は、また、キャッシュデータの処理が必要であるときにバックアップ・キャッシュサービス・ノードに対してオペレーション要求を送信するためにも用いられる。

結果受信ユニット１５０２は、さらに、バックアップ・キャッシュサービス・ノードにより要求送信ユニット１５０１に送信されるオペレーション要求のオペレーション結果を受信するためにも用いられる。

障害タグ付けユニット１５０３は、さらに、結果受信ユニット１５０２により受信されたオペレーション結果に基づきオペレーションが失敗したと判断される場合に、バックアップ・キャッシュサービス・ノードに障害タグを付けるためにも用いられる。

キャッシュ・クライアント１５００は、さらに、結果受信ユニット１５０２により受信したバックアップ・キャッシュサービス・ノードからのオペレーション要求のオペレーション結果に応じて処理を行うために用いられるオペレーション結果処理ユニット１５０５を含んでいる。オペレーション結果処理ユニット１５０５は、バックアップ・キャッシュサービス・ノードについてデータ同期化を実行するために用いられるデータ同期化サブユニット１５０５１を含んでいる。

キャッシュ・クライアント１５００は、さらに、マスタ・キャッシュサービス・ノードおよびバックアップ・キャッシュサービス・ノードについてハートビート検出を実行するために用いられるハートビート検出ユニット１５０６を含んでおり、ハートビート検出の結果に基づいて、マスタ・キャッシュサービス・ノードおよび／またはバックアップ・キャッシュサービス・ノードの障害状態が更新される。

上記のユニットは、１つまたは複数の汎用プロセッサ上で実行されるソフトウェア・コンポーネントとして、プログラマブル・ロジック・デバイスおよび／または特定の機能を実行するように設計された特定用途向け集積回路などのハードウェアとして、あるいはそれらの組み合わせにより、実現することができる。一部の実施形態では、ユニットは、ソフトウェア・プロダクトの形態で実現することができ、これらは不揮発性記憶媒体（光ディスク、フラッシュ記憶装置、モバイル・ハードディスクなど）に記憶することが可能であって、本発明の実施形態に記載した方法をコンピュータ機器（パーソナルコンピュータ、サーバ、ネットワーク装置など）に実行させるための多くの命令を含むものである。ユニットは、単一の機器で、あるいは複数の機器に分散させて、実現することができる。ユニットの機能は、相互に融合させることができ、あるいは、さらに複数のサブユニットに分割することができる。

一部の実施形態では、クラスタ内のキャッシュサービス・ノードの容量が不足しているときに、ノードの容量拡張を動的に実施することができる。集中キャッシュにおいて、容量拡張を実現するため、キャッシュ・ノードは複数のキャッシュ・インスタンスからなる仮想キャッシュサービス・ノードとして構成されている。図１６は、容量拡張が可能なキャッシュ・ノードを示す図である。図示の例では、クラスタＡは、キャッシュ・ノードＡとキャッシュ・ノードＢを含んでいる。キャッシュ・ノードＡは、キャッシュ・インスタンス１、キャッシュ・インスタンス２、およびキャッシュ・インスタンス３を含んでおり、キャッシュ・ノードＢは、キャッシュ・インスタンス４、キャッシュ・インスタンス５、およびキャッシュ・インスタンス６を含んでいる。これらのキャッシュ・インスタンスは、１つのサーバに含むことができ、あるいはいくつかの異なるサーバに分散させることができる。キャッシュサービス・ノードの容量が不足しているときには、追加のキャッシュ・インスタンスを仮想サービスノードに加えることができ、これによって、処理能力が向上し、キャッシュ・クライアントの使用に支障をきたすことがない。

しかしながら、キャッシュ・インスタンスの数が変わると、キャッシュのヒット率に影響することがある。例えば、最初にキャッシュサービス・ノードが３つのみであるとして、ハッシュ法をキーによって実行し、ハッシュ結果を得る。ハッシュ結果に基づいてキャッシュサービス・ノード・モジュールの番号を取得し、そして最後的に、コンテンツを保存または取得するインスタンスを決定する。キャッシュ・インスタンスの数が変わると、最初に保存されたデータが正常に取得できないことがある。クラスタ構成において、データ転送は、いくつかの方法で実現することができる。一部の実施形態では、データ転送インタフェースがキャッシュ・クライアントにより提供され、クラスタ内のキャッシュサービス・ノードのデータが他のキャッシュサービス・ノードに転送される。例えば、キャッシュ・ノードＡに対して容量拡張を実施した後に、データをキャッシュ・ノードＢからキャッシュ・ノードＡに直ぐに転送することができる。具体的には、キャッシュ・クライアントが、キャッシュ・ノードＢ内のすべてのデータを取得し、そして、そのデータをキャッシュ・ノードＡに保存する。一部の実施形態では、自動で段階的データ転送が行われる。アクティブ・クラスタ構成では、キャッシュ・ノードＡに対して容量拡張を実施した後に、キャッシュ・クライアントがデータをもっていなければ、他のキャッシュサービス・ノードから直ちにデータを取得する。キャッシュ・クライアントは、取得したデータを、新しい方法に従ってキャッシュ・ノードＡに保存する。このようにして、キャッシュ・クライアントは、保存されたすべてのデータを段階的にキャッシュ・ノードＡにコピーする。

クラスタ構成モードを導入することで、マスタ・キャッシュサービス・ノードに障害が発生した場合には、バックアップ・キャッシュサービス・ノードが、キャッシュデータ処理の実行のために選択される。こうして、キャッシュサービス・ノードの障害の結果としてキャッシュサービス・ノードが利用不可能になるという問題およびデータ損失の問題が解決され、システムの信頼性および可用性が向上する。当然のことながら、本願を実現するプロダクトは、上記の利点をすべて同時に備えている必要はない。

上記の実施形態は、明確な理解を目的として、ある程度詳細に記載したが、本発明は、提示した詳細に限定されるものではない。本発明を実施する多くの代替の方法がある。開示された実施形態は、例示であって、限定するものではない。

Claims (18)

1. キャッシュデータを処理する方法であって、
   複数のキャッシュサービス・ノードを含むキャッシュクラスタ内のマスタ・キャッシュサービス・ノードに対してキャッシュ処理要求を送信し、前記キャッシュクラスタは、前記複数のキャッシュサービス・ノードのすべてが稼働状態にあって、マスタ・キャッシュサービス・ノードが前記複数のキャッシュサービス・ノードの中から選択されるアクティブ・クラスタ構成モード、あるいは、前記複数のキャッシュサービス・ノードの中で唯一稼働状態にあるノードがマスタ・キャッシュサービス・ノードであるスタンバイ・クラスタ構成モードのいずれかに構成可能であり、
   前記マスタ・キャッシュサービス・ノードからの応答を待機し、
   前記マスタ・キャッシュサービス・ノードに障害が発生したか否かを判断し、
   前記マスタ・キャッシュサービス・ノードに障害が発生した場合に、バックアップ・キャッシュサービス・ノードを選択すること、を備える方法。
2. 前記マスタ・キャッシュサービス・ノードに障害が発生したか否かの判断は、障害回数を閾値と比較することを含む、請求項１に記載の方法。
3. 前記マスタ・キャッシュサービス・ノードに障害が発生した場合に、前記マスタ・キャッシュサービス・ノードに障害タグを関連付けることをさらに備える、請求項１に記載の方法。
4. 前記マスタ・キャッシュサービス・ノードに障害が発生した場合に、前記マスタ・キャッシュサービス・ノードに障害タグを関連付け、前記マスタ・キャッシュサービス・ノードの障害有効期間を設定すること、をさらに備える、請求項１に記載の方法。
5. 前記バックアップ・キャッシュサービス・ノードの選択は、
   前記クラスタ内の障害タグが付けられていない利用可能なキャッシュサービス・ノードを識別し、
   前記利用可能なキャッシュサービス・ノードの中から前記バックアップ・キャッシュサービス・ノードを選択すること、を含む、請求項１に記載の方法。
6. 前記バックアップ・キャッシュサービス・ノードからの応答を待つことをさらに備える、請求項１に記載の方法。
7. 前記マスタ・キャッシュサービス・ノードにキャッシュ処理要求を送信に先立って、前記方法は、
   障害タグが付けられていない利用可能なキャッシュサービス・ノードを識別し、
   前記利用可能なキャッシュサービス・ノードの中から前記マスタ・キャッシュサービス・ノードを選択すること、をさらに備える請求項１に記載の方法。
8. 前記キャッシュ処理要求の送信、および前記応答の待機は、非同期的に実行される、請求項１に記載の方法。
9. 前記マスタ・キャッシュサービス・ノードについてハートビート検出を実行し、
   前記マスタ・キャッシュサービス・ノードに継続して障害が発生している場合に、前記マスタ・キャッシュサービス・ノードの障害状態を更新すること、をさらに備える、請求項１に記載の方法。
10. キャッシング・システムであって、
    複数のキャッシュサービス・ノードを含むキャッシュクラスタであって、前記キャッシュクラスタは、前記複数のキャッシュサービス・ノードのすべてが稼働状態にあって、マスタ・キャッシュサービス・ノードが前記複数のキャッシュサービス・ノードの中から選択されるアクティブ・クラスタ構成モード、あるいは、前記複数のキャッシュサービス・ノードの中で唯一稼働状態にあるノードがマスタ・キャッシュサービス・ノードであるスタンバイ・クラスタ構成モードのいずれかに構成可能であり、
    キャッシュ・クライアントであって、
    前記マスタ・キャッシュサービス・ノードにキャッシュ処理要求を送信し、
    前記マスタ・キャッシュサービス・ノードからの応答を待機し、
    前記マスタ・キャッシュサービス・ノードに障害が発生したか否かを判断し、
    前記マスタ・キャッシュサービス・ノードに障害が発生した場合に、バックアップ・キャッシュサービス・ノードを選択する、ように構成されているキャッシュ・クライアントと、を備えるシステム。
11. 前記マスタ・キャッシュサービス・ノードに障害が発生したか否かの判断は、障害回数を閾値と比較することを含む、請求項１０に記載の方法。
12. 前記マスタ・キャッシュサービス・ノードに障害が発生した場合に、前記キャッシュ・クライアントは、さらに、前記マスタ・キャッシュサービス・ノードに障害タグを関連付けるように構成されている、請求項１０に記載のシステム。
13. 前記マスタ・キャッシュサービス・ノードに障害が発生した場合に、前記キャッシュ・クライアントは、さらに、前記マスタ・キャッシュサービス・ノードに障害タグおよび障害有効期間を関連付けるように構成されている、請求項１０に記載のシステム。
14. 前記バックアップ・キャッシュサービス・ノードのは、
    前記クラスタ内の障害タグが付けられていない利用可能なキャッシュサービス・ノードを識別し、
    前記利用可能なキャッシュサービス・ノードの中から前記バックアップ・キャッシュサービス・ノードを選択すること、を含む、請求項１０に記載のシステム。
15. 前記キャッシュ・クライアントは、さらに、前記バックアップ・キャッシュサービス・ノードからの応答を待つように構成されている、請求項１０に記載のシステム。
16. 前記マスタ・キャッシュサービス・ノードにキャッシュ処理要求の送信に先立って、前記キャッシュ・クライアントは、さらに、
    障害タグが付けられていない利用可能なキャッシュサービス・ノードを識別し、
    前記利用可能なキャッシュサービス・ノードの中から前記マスタ・キャッシュサービス・ノードを選択するように構成されている、請求項１０に記載のシステム。
17. 前記キャッシュ処理要求の送信、および前記応答の待機は、非同期的に実行される、請求項１０に記載のシステム。
18. 前記キャッシュ・クライアントは、さらに、
    前記マスタ・キャッシュサービス・ノードについてハートビート検出を実行し、
    前記マスタ・キャッシュサービス・ノードに継続して障害が発生している場合に、前記マスタ・キャッシュサービス・ノードの障害状態を更新するように構成されている、請求項１０に記載のシステム。

Images