{"id":45366,"date":"2017-01-25T16:31:33","date_gmt":"2017-01-25T11:01:33","guid":{"rendered":"http:\/\/www.tothenew.com\/blog\/?p=45366"},"modified":"2017-01-28T14:00:42","modified_gmt":"2017-01-28T08:30:42","slug":"sharing-the-load-cache-clustering-with-hazelcast","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/sharing-the-load-cache-clustering-with-hazelcast\/","title":{"rendered":"Sharing the Load: Cache Clustering with Hazelcast"},"content":{"rendered":"

In my earlier blog on\u00a0Caching: What, Why and How with Hazelcast<\/a>\u00a0we have discussed about the importance of software caching and how to implement it with\u00a0Hazelcast<\/a>.<\/p>\n

In this blog, we are going to discuss the importance of distributed caching and how to configure\u00a0Hazelcast<\/a>\u00a0to be a full TCP\/IP cluster.<\/p>\n

What is Cache clustering?<\/strong><\/p>\n

\"Cache<\/p>\n

A cache cluster is a network of cluster members to be a Replicated<\/a> \/ Distributed<\/a> cache server to achieve data high availability and fault tolerance. \u00a0Cluster members (also called nodes) can automatically join together to form a cluster. This automatic joining can take place with various discovery mechanisms that the cluster members use to find each other. After a cluster is formed, communication between cluster members is done always via TCP\/ IP regardless of the discovery mechanism used.<\/p>\n

Why is cache clustering required?\u00a0<\/strong><\/p>\n

Recently at TO THE NEW<\/a>, we came across a product<\/a>, which as a platform allows its users to broadcast LIVE. It was a real-time application (RTA) where data was changing in very small time frames and it had to be reflected in the application in real time. Users can view personalized content based on their coordinates, geo-location etc. The application was highly performant and had\u00a0relation and NoSQL databases used in its core as the primary data storage with\u00a0Hazelcast<\/a>\u00a0as a cache server to caching data.<\/p>\n

\"cache<\/p>\n

As above diagram states back-end is distributed into several small applications, each application serving a specific purpose. All user interaction and authentication done through application named API<\/b><\/span><\/span> and a user can broadcast their content through application named\u00a0Stream<\/span><\/strong>. The personalized content was\u00a0served through\u00a0Homescreen<\/span><\/strong>\u00a0and\u00a0Location<\/span><\/strong>\u00a0applications and accessed data from the cache server, also it was precomputed in real time by few worker modules like\u00a0Job<\/span><\/strong>\u00a0, Worker<\/span><\/strong>\u00a0. Users would\u00a0communicate to each other on any Live content through\u00a0Chat<\/span><\/strong>\u00a0module, and\u00a0all chat messages were\u00a0checked for profanity before sending it to the user in real time.<\/p>\n

Since different applications like Homescreen, Job, API, admin, vod, stream, beam detail, monetization modules accessing different cache server, it leads to some major issues,<\/p>\n