hazelcast高可用性详解

1. Elastic Memory（弹性内存）

Hazelcast 默认存储分布式数据（map entries, queue items）在能够进行GC的java heep中。因为你的heep愈来愈大，进行GC时可能致使你的应用暂停服务10秒，所以影响了你的应用的体验性和响应时间。弹性内存是hazelcast使用off-heap进行存储以免GC时形成的暂停服务。即便你有频繁更新TB级别的内存数据，GC时几乎不会形成影响；从而使你的应用有可预见的延时和吞吐量。

每一个map能够配置为off-heap或者on-heap这两种存储类型。若是map的存储类型是off-heap,那么primary，backup和可用的near-cacheed entries 被存储在离线堆里面，而且off-heap的存储空间会随着你节点数的增长而动态扩展。

弹性内存的实现不须要任何碎片整理。它的工做原理是这样:用户分配每一个JVM几GB的离线储存堆，假设是40GB。Hazelcast 将建立40个DirectBuffers，每一个有1GB的容量。假设有50个节点，而且要存储2TB的数据。每一个buffer被分红可配置的chunck（blocks）（一个chunck大小默认是1KB）。Hazelcast 使用可写的blocks。例如3KB将被存储为3个blocks。当存储的值被移除，这些blocks被归还到可用的blocks队列中以便存储其余值的时候使用。

2.Distributed Backups(分布式备份)

在可扩展的动态分区存储系统中，不管是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 会很温柔地迁移一些数据到这些新的节点，最终数据均匀存储。

三、只有一份备份数据初始状态图