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 会很温柔地迁移一些数据到这些新的节点，最终数据均匀存储。

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