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节点，一旦第一个节点挂了，第二个自然就成为了第一个，也就成为了master。而master的作用是与各成员保持连接和心跳，维护成员列表和虚拟节点列表，并在各节点和客户端要获取时提供。管理这两个列表的服务分别是ClusterService和PartitionService。
3.故障转移：
假设在执行mapCustomers.put(1, "Joe");操作时，要请求虚拟节点所在的实际节点挂了，则客户端会接收到IOException，此处客户端代码中判断如果出现IO异常，则向master节点发起一个异步的更新虚拟节点列表的请求，并重试刚才报IO异常的操作，重试时是向节点列表的下一个成员地址发请求。此处使用了while循环，除非客户端stop，否则会一直重试。如果挂掉的是master节点，则刚才向master发的获取虚拟节点列表的请求也会报IO异常，所以它也会找下一个节点重试。其实由于排在第二的节点自动就成为master，所以重试次数不会很多。
4.动态扩容：
当启动一个新节点时，它会先用组播服务向所有节点发起请求，从而能够与master节点连接上，加入成功则master会把新的成员列表发给各节点。然后执行rebalance：首先根据新成员列表创建出新的虚拟节点列表，然后把原虚拟节点列表与新列表做比较从而针对每个需要移动的虚拟节点创建一个task，放到一个task队列中去依次执行。
5.数据一致性：
客户端向 Hazelcast写入数据本体所在节点是必须同步的；而备份过程默认是异步的，也可以修改配置成同步。为了保证一致性，默认情况下，读取数据总是从数据的owner节点读取，这个也可以修改配置成允许从备份节点读数据，这样能给你带来更好的读性能。
举例来说，要更新key为1的数据时，由一致性hash算法得知其存在节点A上，则对节点A发起update请求，这时如果你用另一个客户端也要更新节点A上的key1时，咱俩这个操作肯定是同步控制的。而节点A把key1备份到节点B的过程你可以配成同步，然后再配成允许从备份节点读取，这样保证了一致性和高可读。如果备份过程配成异步，再配成不允许从备份节点读取，则保证了高可写，而一致性也基本ok，只是万一异步备份未完成时，数据本体所在节点挂掉，那数据就可能脏了。
评论