分散キャッシュhazelcastのいくつかの原理分析

1.以下では、クライアントが要求を作成および送信するプロセスで説明を分解する.

public static void main(String[] args) {
	ClientConfig clientConfig = new ClientConfig();
   		clientConfig.addAddress("10.10.4.40:5701");
	// client          service（      、       、      、       ），   ClientClusterServiceImpl，           （   clientConfig       connection，        ，            ），    ClientPartitionServiceImpl，                      ，     ConcurrentHashMap 。
    	HazelcastInstance instance = HazelcastClient.newHazelcastClient(clientConfig);
	//    map     map，    mapProxy
	//        key value   
    	Map<Integer, String> mapCustomers = instance.getMap("customers");
	// put ，   mapProxy  key value     byte[]
	//    key hash        :key.getHash()%271,  partitionId
	//   ClientPartitionServiceImpl  ConcurrentHashMap                 ,    key       。    BufferedOutputStream             。
    	mapCustomers.put(1, "Joe");
	//  put  ，    ，     。          。
    	System.out.println("Customer with key 1: "+ mapCustomers.get(1));
   	System.out.println("Map Size:" + mapCustomers.size());
}

 
2.単一の問題:
hazelcastが単一の問題がないのは,masterノードがないからではなく,クラスタの中で最も早いノードを直接masterノードとし,いったん最初のノードが掛けられると,2番目が自然に1番目となり,masterとなる.masterの役割は、各メンバーと接続と心拍数を維持し、メンバーリストと仮想ノードリストを維持し、各ノードとクライアントが取得するときに提供することです.この2つのリストを管理するサービスは、それぞれClusterServicesとPartitionServicesです.
 
3.フェイルオーバ:
mapCustomersを実行するとする.put(1, "Joe");操作時に、仮想ノードが存在する実際のノードが停止していることを要求すると、クライアントはIOExceptionを受信し、ここでクライアントコードでIO異常が発生した場合、masterノードに非同期で仮想ノードリストを更新する要求を開始し、さっきIO異常を報告した操作を再試行し、再試行時にノードリストの次のメンバーアドレスに要求する.ここではwhileループが使用されており、クライアントstop以外は再試行されます.マウントされたノードがmasterノードである場合、さっきmasterに送信した仮想ノードリストの取得要求もIO異常を報告するので、次のノードを探して再試行します.実は2番目のノードは自動的にマスターになるので、再試行回数は多くありません.
 
4.動的拡張:
新しいノードを起動すると、すべてのノードにマルチキャストサービスでリクエストが開始され、masterノードに接続できます.参加に成功すると、masterは新しいメンバーリストを各ノードに送信します.次にrebalanceを実行します.まず、新しいメンバーリストに基づいて新しい仮想ノードリストを作成し、元の仮想ノードリストを新しいリストと比較して、移動が必要な仮想ノードごとにtaskを作成し、taskキューに配置して順次実行します.
 
5.データ整合性:
クライアントがHazelcastにデータ本体のあるノードを書き込むには同期が必要である.バックアップ・プロシージャのデフォルトは非同期であり、同期に構成を変更することもできます.コンシステンシを保証するために、デフォルトでは、読み取りデータは常にデータのownerノードから読み取ります.これは、バックアップノードからデータを読み取るように構成することもできます.これにより、より良い読み取り性能をもたらすことができます.
例えば、keyが1のデータを更新する場合、コンシステンシhashアルゴリズムによってノードA上に存在することが分かった場合、ノードAに対してupdate要求が開始され、この場合、他のクライアントでもノードA上のkey 1を更新する場合、この操作は同期制御に違いない.一方、ノードAがkey 1をノードBにバックアップするプロセスでは、同期化してバックアップノードから読み取ることができ、一貫性と高読み取りが保証されます.バックアップ・プロシージャが非同期に構成され、バックアップ・ノードからの読み取りが許可されないように構成されている場合、書き込み可能性が高く、一貫性も基本的にokです.ただし、非同期バックアップが完了していない場合、データ本体のあるノードが削除されると、データが汚れてしまう可能性があります.