Hazelcast v3.7-EA 發布，一個數據分發和集群平臺

Hazelcast是一個高度可擴展的數據分發和集群平臺。 可用于實現分布式數據存儲、數據緩存。特性包括：

• 提供java.util.{Queue, Set, List, Map} 分布式實現。
• 提供java.util.concurrent.ExecutorService 分布式實現。
• 提供java.util.concurrency.locks.Lock 分布式實現。
• 提供分布式主題的發布/ 訂閱消息傳遞
• 提供用于一對多關系的分布式MultiMap
• 提供用于安全集群的Socket 層加密
• 支持同步和異步持久化 
• 通過JCA 與J2EE 容器集成和事務支持
• 為Hibernate 提供二級緩存Provider
• 提供分布式監聽器和事件
• 支持集群信息和成員節點事件
• 通過JMX 監控和管理集群
• 支持動態HTTP 會話集群
• 實現動態集群
• 支持動態擴展到幾百個服務器
• 利用備份實現動態分割
• 支持動態故障恢復
• 超簡單易用，只需要一個jar 包
• 超快，每秒達到成千上萬操作
• 超小，不到2MB
• 超有效， CPU 和RAM 非常低耗

Hazelcast拓撲

更新日志

新特性

• First Modularized Release: 3.7 is the first fully modularized version of Hazelcast. We have separate repos, maven modules and release cycles for many aspects of Hazelcast now. Each client/language and plugin is now a module. When you download a 3.7 distribution, it contains the latest released version. But we can release updates, new features and bug fixes much faster than the Hazelcast core. When we say in this blog we will release something parallel to 3.7, we mean we are releasing a module. And it speeds up development. And of course it is easier to contribute to as an open source contributor. A win-win all round.
• Custom eviction policies: In Hazelcast you could always set an eviction policy from one of LRU or LFU. But what if you want more flexibility to suit custom requirements of your app. Custom eviction policy exactly helps on that. We implemented a custom eviction both for our Map and JCache implementations. Here you can see an example of an odd-based evictor. It works with our O(1) probabilistic evictors. You simply provide a comparator and we choose the best eviction candidate.Fault-Tolerant ExecutorService: Imagine you send executables to hazelcast nodes and they take hours to complete. What if one the nodes crashes and you do not know whether the task completed or not? In 3.7, we introduce DurableExecutorService. It guarantees ‘execute at least once’ semantics. Its API is a narrowing ofIExecutorService. Unlike IExecutorService, users will not be able to submit/execute tasks to selected member/members. (Note: This module has not been released with EA1. It will be available in EA2 in a few weeks.
• New Cloud Integrations: We are releasing the CloudFoundry and OpenShift plugins parallel to the 3.7 release. The Hazelcast members deployed to CloudFoundry and OpenShift will discover each other automatically. Also you will have an option to connect and use Hazelcast as a service inside CloudFoundry and OpenShift. You also have the option of using this with Docker – https://hub.docker.com/r/hazelcast/openshift/. See Rahul’s following blog to learn more about using the CloudFoundry Integration.
  We also released our Azure Cloud Discovery Plugin for running Hazelcast on Azure. Hazelcast will also be up inMicrosoft Azure Marketplace before the end of June. Look out for the forthcoming blog on that.
• Apache Spark Connector: Parallel to the 3.7 release we are releasing our new plugin Hazelcast-Spark connector. It allows Hazelcast Maps and Caches to be used as shared RDD caches by Spark using the Spark RDD API as per the following cache example.
  Both Java and Scala Spark APIs are supported. See the module repo for details.
• Reactive – We did the hard work of adding back pressure to Hazelcast over the 3.5 and 3.6 releases. Hazlecast internally is fully asynchronous. Now we are beginning to expose reactive methods. In 3.7 most of the IMAP async methods plus AsyncAtomicLong have been added. Vert.x-Hazlecast is a very popular combination. Vert.x 3.3.0-CR2 has the new reactive Hazelcast integration for much higher performance. The reactive methods return
• Hazelcast CLI: Also new in 3.7 is a command line interface (“CLI”) to manage the lifecycle of Hazelcast members. The CLI makes hazelcast more dev-ops friendly as well as making testing easier for developers. Here how to install and use CLI: https://github.com/hazelcast/hazelcast-cli/
• WAN Replication Enhancements (Enterprise Only): With 3.7; we implemented the ability to resynchronize a remote WAN cluster. This was implemented for IMap (Cache implementation is left for 3.8). This is very useful when you initiate a WAN connection or need to reinitiate after maintenance to a remote cluster.
• WAN Replication via Solace (Enterprise Only): We also added WAN replication with Solace, a high performance enterprise grade messaging solution.

Hazelcast內部的顯著改進

• Improvements on partitioning system: Our community had detected the following issue: During a migration process, there can happen a moment that data is kept by number of nodes which is less than the configured backup count even there is enough number of nodes in the cluster. If any node crashes at this unfortunate moment, we were losing data. Although, some may claim this is an edge case scenario; still it was conflict with our guarantee that we give to our users. So we designed and implemented major improvements in our partitioning and migration system. You can find a detailed explanation of the solution here:https://hazelcast.atlassian.net/wiki/display/COM/Avoid+Data+Loss+on+Migration+-+Solution+Design

• Graceful shutdown improvements: We need to ensure data safety while shutting down multiple nodes concurrently. But there was a counter example: When a node shuts down, it checks if all 1st backups of its partitions are synced without checking if the backup node is also shutting down or not. There is a race situation here. If both owner and backup nodes shutdown at the same time, we lose data since owner is not aware that 1st backup is also shutting down. See the following PR to get an idea about the solution:https://github.com/hazelcast/hazelcast/pull/7989

• Improvement to the threading model: In 3.7, there is now at least 1 generic priority thread that will only process generic priority operations like member/client heartbeats. This means that under load the cluster remains more stable since these important operations get processed. See following PR for details of the problem and solution: https://github.com/hazelcast/hazelcast/pull/7857

• Improvements to the invocation system: Invocation service is one of the parts that we were wanting to improve and simplify. Because it is complex, it was hard to fix bugs, even minor changes were prone to regressions. We simplified the invocation logic and fixed some ambiguities. Although it is a completely internal development, it has made Hazelcast more stable preventing many problems regarding invocation system. Relatedly various enhancements (e.g. moving IsExecutingOperation into its own thread) fixed several issues like the following: https://github.com/hazelcast/hazelcast/issues/6248

• Performance improvement on map.putAll(): We introduced grouping and batching of remote invocations but also reduced some internal litter for higher performance. Our efforts resulted in a performance gain up to 15% especially when the argument size is bigger. If you want to read some code, here it is:https://github.com/hazelcast/hazelcast/pull/8023

• Prevent blocking reads in transactions: To provide atomicity for transactions, we were blocking the reads on entries which are locked transactionally. This is not an optimized solution. We changed the architecture so that we block reads just before the commit.

• Improvements on Hot Restart and HD (Enterprise HD Only): We introduced batching of hot restart operations (when fsync is enabled) that will improve performance notably. Moreover, we optimized memory usage of Hot Restart by persisting values to disk, reducing metadata. In high density memory, we created an abstraction layer for safer memory access which also handled unaligned memory access to enable HD on Oracle Sparc CPUs commonly found in Solaris systems.

• .NET Client Enhancements: Besides working on new clients, our team is enhancing existing clients. We added predicate and SSL support for our .Net client.

下載

• ZIP 
• Source code (zip)
• Source code (tar.gz)