简介

hazelcast其中一个很重要的应用就是可以将多个应用服务器组成一个分布式环境的应用，形成一个cluster。这个cluster可以选举出一个master来对外工作。而cluster中的各台服务器之间有数据同步机制和数据备份机制，来避免因为单个节点挂掉而导致数据丢失和cluster的失效。数据存储在分布式内存中，hazelcast可以保证数据在各个节点的均匀分布，可以增加节点和减少节点，而这个过程中，hazelcast会自动迁移数据，来保证数据的高可用。

选择Master

在hazelcast中，master是指集群里面的主节点。这个主节点负责的是向其他成员节点更新最新的成员列表。

一开始还没有节点，第一个启动的节点会先寻找其他节点，这里会根据配置的寻找机制，如果是multicast，就用multicast的方式寻找。如果是TCP/IP,就用TCP/IP的方式寻找。 找不到，就选举自己为master。

后面加入的节点，会向已存在cluster的master发出join请求，master检测是否符合集群的加入要求，如果符合，就会发送最新的成员列表给新加入的成员。同时更新集群中的数据，保证数据的均匀分布和冗余。

集群中的每个成员都有相同的成员列表。成员列表是按加入的顺序排好的。如果master 挂掉了，那么剩下的成员会收到通知，然后从成员列表中选举下一个作为master。

分布式备份

在可扩展的动态分区存储系统中，无论是NoSQL数据库、文件系统或者是内存数据网格，在集群更改时（添加或者删除节点），在集 群重新均衡时可能导致网络大数据传输。需要重新均衡这些节点中的主从数据。例如一个节点挂了，挂掉的节点的主备数据必须重新分配给其他在线的节点。以MB 数据传输会对集群造成消极的影响，因为要消耗机器的宝贵资源（例如网络流量、CPU和RAM）。在此期间可能导致严重的操作延时。

假设集群中有50个节点，每个存储40GB数据（20GB主数据和20GB备份数据）；假设节点5挂了，我们必须保证节点5的存 储在集群中的临近节点中。那么节点5到的主备数据将被分配到临近节点7。这意味着节点7的数据量是其他节点的2倍。也意味着节点7消耗更多的CPU来处理 这两倍请求。另外节点7必须备份这个20GB的数据到其他节点9。这对这两个节点的负载造成极坏的影响。节点9也需要更多的内存去存储这20GB的备份数 据。造成大量的内存浪费。

Hazelcast 解决了以上问题。一个节点的主数据均匀地被分到其他节点。也就是说每个 节点都负责备份其他节点主数据。这样会有更好地使用内存和在减小添加或者删除结点时对集群的影响。假设集群中有50个节点要存储2TB的数据；每个节点存 储20G主数据和20G备数据。假设节点3的20GB的主数据被备份到其他49个节点，每个节点有20GB/49节点3的主数据。如果节点3挂了，每个节 点有1/49它的数据；注意没有任何数据迁移并且集群依然是均衡的！这样的备份机制在节点挂了之后是不需要立刻重新均衡的。假设你添加了5个节点。集群中也没有立马均衡；因为存在的节点已经在最佳状态。Hazelcast 会很温柔地迁移一些数据到这些新的节点，最终数据均匀存储。

Operation

Operation是hazelcast里面操作逻辑的封装。操作的逻辑要放在run方法里面，类似于runnable。

客户端创建和发送请求分析

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());
}

故障转移

首先当 ClientClusterServiceImpl启动之后就产生一个一直监听节点存活情况的线程[cluster-listener]。

那么假设在执行 mapCustomers.put(1, “Joe”);操作前，其要操作的实际节点挂了，这时[cluster-listener]线程会立即感知并更新虚拟节点表。 如果在更新完毕后操作才发出请求，则操作可以成功，如果在更新未完成时发出了请求，则会抛出异常。而这个更新虚拟节点表的过程需要几秒钟。在这几秒钟里对失效节点的操作就真的失败了。

数据一致性

客户端向 Hazelcast写入数据本体所在节点是必须同步的；而备份过程默认是同步的，也可以修改配置成异步。 为了保证一致性，默认情况下，读取数据总是从数据的owner节点读取，这个也可以修改配置成允许从备份节点读数据，这样能带来更好的读性能。

举例来说， 要更新key为1的数据时，由一致性hash算法得知其存在节点A上，则对节点A发起update请求，这时如果你用另一个客户端也要更新节点A上的key1时，这两个操作肯定是同步控制的。而节点A把key1备份到节点B的过程也可以配成同步，然后再配成允许从备份节点读取，这样保证了一致性和高可读。如果备份过程配成异步，再配成不允许从备份节点读取，则保证了高可写，而一致性也基本ok，只是万一异步备份未完成时，数据本体所在节点挂掉，那就可能产生脏数据。