分区和复制
1 | //backup |
默认情况是同步复制一份,以上为异步复制1份,也可同步+异步。
- 分区采用一致性Hash算法,便于节点变更复制
- 计算分区,MOD(hash result, partition count) ,其中将key取byte数组,再取hash值,然后对分区默认271数取模,则为分区位置
- 如果不指定备份数,则没有复制,节点下线后会丢失数据
- 若有备份,则节点数据对等,单节点宕机,备份会成为查询节点
- 若有备份,新增节点时,分区数据因一致性算法则最小化复制扩容
- 读写操作时,会根据key将请求分发至该分区
- 区分表由最早启动的节点告知其他节点,包括后续的变更通知以便重新分区,通知周期默认15s
- 同步复制可防止脏数据,性能不如异步
- 备份数据也可提供读,节省查询其他节点的分区的网络开销,但可能存在脏数据,且不计入主分区的命中次数,也不影响空闲过期时间
持久化
- 通过MapStore实现单个、批量的读写持久化数据,MapStore继承了LoadStore。
- 持久化应是中心化数据库,因为多个节点情况下,查询执行在主分区上,导致不同节点的数据可能不一致;在节点变化时,主分区变更至其他节点,则单点持久化数据失效。
读时持久化
如果配置和开启MapStore, IMap.get分区查询内存数据不存在时,调用MapStore.load查询并加载到内存;但不会新增备份。写时持久化
write-delay-seconds为0时,map.put则MapStore.store同步写入数据至持久化,且可同步备份。写后持久化
- write-delay-seconds大于0,map.put异步延迟持久化数据。
- 该数据会标记为脏数据,存入队列中,直至被持久化。
- 当write-coalescing即保留所有变更时,需要设置
hazelcast.map.write.behind.queue.capacity
以防脏数据在内存中过多,导致OOM。
Map及NearCache配置
1 | Config config = new Config(); |
Eureka注册中心
1 | config.setNetworkConfig(new NetworkConfig() |
eureka-client.properties,默认配置名称,路径在classpath下。1
2
3hazelcast.shouldUseDns=false
hazelcast.name=hz-instance
hazelcast.serviceUrl.default=,http://192.168.1.100:8000/eureka/
以上可实现复用eureka配置中心,实现各hazelcast节点同步,无需广播。