1. Overview
In this article, we will learn the use of Hazelcast cache in Spring boot application.
2. Hazelcast
Caching puts actively used data in memory, where applications can access those data significantly more quickly.
Hazelcast provides a robust distributed in-memory cache where high-speed, high-volume systems need it most.
3. Hazelcast cache in Spring boot
It is enough to provide Hazelcast configuration on the classpath, and Spring boot automatically configures Hazelcast.
We can build a Hazelcast cluster by starting several Hazelcast nodes in a distributed manner. These nodes are called the Hazelcast member.
Now raises the question of how these members distributed across several machines can discover each other and replicate data.
For example, you can enable the multicast auto-discovery mechanism, Hazelcast allows cluster members to find each other using multicast communication. The cluster members do not need to know the concrete addresses of the other members, as they just multicast to all the other members for listening.
Hazelcast automatically takes care of the replication of data across other members (write-through).
3.1. Add Hazelcast dependency
First, let’s add the dependency in pom.xml for maven projects.
<dependency>
<groupId>com.hazelcast</groupId>
<artifactId>hazelcast-all</artifactId>
<version>4.2.5</version>
</dependency>
3.2. Configure Hazelcast cache in Spring boot
You can add Hazelcast configuration in one of the following manners:
- Add
hazelcast.yamlconfiguration (Note that the suffix of the filename should beyamlandhazelcast.ymlwon’t work.) - Add
hazelcast.xmlconfiguration - Define
@Beanwith Hazelcast configuration in the source code
3.3. Execute app
If you execute the application now, thus you would notice logs similar to those below:
2022-09-20 20:37:12.792 INFO 16904 --- [ main] c.h.i.config.AbstractConfigLocator : Loading 'hazelcast.yaml' from the classpath.
2022-09-20 20:37:12.980 INFO 16904 --- [ main] com.hazelcast.system : [192.168.11.201]:5701 [dev] [4.2.5] Hazelcast 4.2.5 (20220427 - 1dbec0d) starting at [192.168.11.201]:5701
2022-09-20 20:37:13.434 INFO 16904 --- [ main] com.hazelcast.instance.impl.Node : [192.168.11.201]:5701 [dev] [4.2.5] Using Multicast discovery
2022-09-20 20:37:13.434 WARN 16904 --- [ main] com.hazelcast.cp.CPSubsystem : [192.168.11.201]:5701 [dev] [4.2.5] CP Subsystem is not enabled. CP data structures will operate in UNSAFE mode! Please note that UNSAFE mode will not provide strong consistency guarantees.
2022-09-20 20:37:13.740 INFO 16904 --- [ main] c.h.internal.diagnostics.Diagnostics : [192.168.11.201]:5701 [dev] [4.2.5] Diagnostics disabled. To enable add -Dhazelcast.diagnostics.enabled=true to the JVM arguments.
2022-09-20 20:37:13.740 INFO 16904 --- [ main] com.hazelcast.core.LifecycleService : [192.168.11.201]:5701 [dev] [4.2.5] [192.168.11.201]:5701 is STARTING
2022-09-20 20:37:15.902 INFO 16904 --- [ main] c.h.internal.cluster.ClusterService : [192.168.11.201]:5701 [dev] [4.2.5]
Members {size:1, ver:1} [
Member [192.168.11.201]:5701 - 056cd431-659e-43e8-a6d5-0cb625ef716a this
]
2022-09-20 20:37:15.912 INFO 16904 --- [ main] com.hazelcast.core.LifecycleService : [192.168.11.201]:5701 [dev] [4.2.5] [192.168.11.201]:5701 is STARTED
Now, let’s execute another instance of the application with a different port number. Post execution, you can see that the Hazelcast discovered the existing member [192.168.11.201]:5701 by using multicast discovery:
2022-09-20 21:18:49.006 INFO 17212 --- [ main] c.h.i.config.AbstractConfigLocator : Loading 'hazelcast.yaml' from the classpath.
2022-09-20 21:18:49.193 INFO 17212 --- [ main] com.hazelcast.system : [192.168.11.201]:5702 [dev] [4.2.5] Hazelcast 4.2.5 (20220427 - 1dbec0d) starting at [192.168.11.201]:5702
2022-09-20 21:18:49.662 INFO 17212 --- [ main] com.hazelcast.instance.impl.Node : [192.168.11.201]:5702 [dev] [4.2.5] Using Multicast discovery
2022-09-20 21:18:49.662 WARN 17212 --- [ main] com.hazelcast.cp.CPSubsystem : [192.168.11.201]:5702 [dev] [4.2.5] CP Subsystem is not enabled. CP data structures will operate in UNSAFE mode! Please note that UNSAFE mode will not provide strong consistency guarantees.
2022-09-20 21:18:49.899 INFO 17212 --- [ main] c.h.internal.diagnostics.Diagnostics : [192.168.11.201]:5702 [dev] [4.2.5] Diagnostics disabled. To enable add -Dhazelcast.diagnostics.enabled=true to the JVM arguments.
2022-09-20 21:18:49.915 INFO 17212 --- [ main] com.hazelcast.core.LifecycleService : [192.168.11.201]:5702 [dev] [4.2.5] [192.168.11.201]:5702 is STARTING
2022-09-20 21:18:50.164 INFO 17212 --- [ main] c.h.i.cluster.impl.MulticastJoiner : [192.168.11.201]:5702 [dev] [4.2.5] Trying to join to discovered node: [192.168.11.201]:5701
2022-09-20 21:18:50.194 INFO 17212 --- [.IO.thread-in-0] c.h.i.server.tcp.TcpServerConnection : [192.168.11.201]:5702 [dev] [4.2.5] Initialized new cluster connection between /192.168.11.201:51421 and /192.168.11.201:5701
2022-09-20 21:18:56.188 INFO 17212 --- [ration.thread-0] c.h.internal.cluster.ClusterService : [192.168.11.201]:5702 [dev] [4.2.5]
Members {size:2, ver:2} [
Member [192.168.11.201]:5701 - 03c36725-98a9-4a54-b7c0-9cb1d1c649f8
Member [192.168.11.201]:5702 - 30a88b33-85ce-4f2f-8487-8a7e791fea3e this
]
2022-09-20 21:18:57.198 INFO 17212 --- [ main] com.hazelcast.core.LifecycleService : [192.168.11.201]:5702 [dev] [4.2.5] [192.168.11.201]:5702 is STARTED
4. Conclusion
To sum up, we have used the Embedded Hazelcast topology where every instance of the application has an integrated member.
Thus cache and application run on the same node, Hazelcast replicates the write across other members and the application can read data from the cache in the same node.