Introduction to In-Memory Data Grids

In-memory data grids are gaining a lot of attention in the developer community because of high performance and dynamic scalability. Let us see more details about In-Memory Data Grids(IMDG) in this article.

In one of the article, we have seen Memcached as the cache to increase the performance of the application. The In-Memory Data Grids(IMDG) are also doing the same thing. Then, why we need IMDG? The Memcached is very well suited for read-mostly data. The IMDG’s are suitable for read-write data. The servers in the Memcached cluster are independent(don’t know each other) and if one server goes down from the cluster, there is a loss to the data. But, in the case of IMDG cluster, the servers know each other and the data is partitioned across the servers. In the cluster, each node will carry some data and the backup of the data. If one server goes down from the IMDG cluster, the same data from the backup will get redistributed to the other live servers. So, there is no loss to the data. The data can be persisted with Memcached and IMDG’s. We can persist the data asynchronously when we are using IMDG. But, in the case of Memcached, first, we need to persist the data and then need to warm up the cache(it is synchronous).

Now, we will see one of the IMDG solution called Hazelcast and how it fits in our application architecture?

To use the Hazelcast, first, download the Hazelcast distribution from here. The present available Hazelcast version is 3.1.2. Keep the hazelcast-3.1.2.jar, hazelcast-client-3.1.2.jar files in the classpath. The below sample code will start the Hazelcast server. If we run the same code multiple times, the Hazelcast cluster will get form.

Now, we will bring down one of the server nodes from the cluster. In this case, the data which is there on that server node from the backup will get redistribute to the live server node. The log of the live server node is given below.