జావాలో Hazelcast: Spring Boot Applications కోసం Distributed In-Memory Grid

చాలా caches network మీద మీరు మాట్లాడే ఒక box. Hazelcast అనేది network. ఆ తేడానే మొత్తం point — ఈ post యొక్క మొత్తం pitch కూడా అదే.

Hazelcast నిజంగా ఏమిటి

చాలా teams cache కోసం ఎందుకు చేరువ అవుతారంటే read traffic కి database చాలా slow గా ఉంటుంది. వారు Redis install చేస్తారు, కొన్ని methods పై @Cacheable mark చేస్తారు, dashboard green అవుతుంది. caching కంటే ఎక్కువ అవసరం వచ్చేంత వరకు అది బాగానే పనిచేస్తుంది. రెండు services agree అవ్వాల్సిన counter అవసరం వచ్చినప్పుడు. node restart అయితే కోల్పోకూడని queue అవసరం వచ్చినప్పుడు. ఒక long-running job ఒక record ను touch చేస్తున్నప్పుడు cluster అంతటా దాన్ని lock చేయాల్సిన అవసరం. ఆ ఏదైనా అవసరం వచ్చిన క్షణం, simple cache సరిపోదు.

"cache" తీసుకొని "cache అనేది cluster అయితే ఏమవుతుంది?" అని అడిగితే మీకు Hazelcast వస్తుంది. ఇది in-memory data grid (IMDG) — JVMs యొక్క peer-to-peer network, data share చేస్తాయి, code కలిసి run చేస్తాయి, మరియు partitioning, replication, failover ను నిశ్శబ్దంగా handle చేస్తాయి. మీకు distributed Map, distributed Queue, distributed Lock, data ఇప్పటికే ఉన్న node మీద tasks run చేసే ExecutorService, మరియు దీన్ని ordinary caching లాగా చూపించే Spring Boot integration లభిస్తుంది.

ఇది ఒక tour. "మీ Spring Boot app లో embed చేసి cache గా వాడండి" నుండి "distributed system కోసం coordination layer గా వాడండి" వరకు వెళతాం. మొదట code, తరువాత తమ స్థానాన్ని సంపాదించుకునే opinions.

Embedded vs Client-Server — ఒకటి త్వరగానే ఎంచుకోండి

Hazelcast రెండు shapes లో run అవుతుంది, మరియు ఆ ఎంపిక మిగతావన్నీ రంగు వేస్తుంది.

Embedded mode. Hazelcast మీ application JVM లోపల ఉంటుంది. మీ service యొక్క ప్రతి instance కూడా ఒక Hazelcast member, మరియు అవి network మీద automatically cluster ఏర్పరుస్తాయి. Co-location అంటే data lookups తరచుగా local memory access — network hop లేదు. trade-off: మీ data grid ను application నుండి స్వతంత్రంగా scale చేయలేరు. మీ service 3 నుండి 30 nodes కు scale అయితే, మీ grid కూడా అలాగే.

Client-server mode. Hazelcast తనదైన dedicated JVMs cluster గా run అవుతుంది. మీ application thin client ద్వారా దానితో మాట్లాడుతుంది. ఇది teams Redis ఎలా వాడతారో దానికి దగ్గరగా ఉంటుంది. data tier ను separately size చేయవచ్చు, data కోల్పోకుండా application nodes ను restart చేయవచ్చు, ఒకే grid పై polyglot stack run చేయవచ్చు.

ఒకే Java service ship చేస్తున్న చాలా Spring Boot teams కు embedded mode సరళమైన entry. Multi-language stacks కు లేదా ops cache ను separate tier గా కావాలనుకున్నప్పుడు client-server సరైనది.

Spring Boot లో Hazelcast Setup చేయడం

Spring Boot కు built-in support ఉంది — classpath పై embedded cluster కు dependency జోడించడం సరిపోతుంది.

<!-- pom.xml -->
<dependency>
    <groupId>com.hazelcast</groupId>
    <artifactId>hazelcast-spring</artifactId>
    <version>5.4.0</version>
</dependency>

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-cache</artifactId>
</dependency>

ఒక minimal config — classpath పై hazelcast.yaml drop చేయవచ్చు, లేదా Java నుండి config build చేయవచ్చు.

// src/main/resources/hazelcast.yaml
hazelcast:
  cluster-name: orders-cluster
  network:
    port:
      auto-increment: true
      port: 5701
    join:
      multicast:
        enabled: false
      tcp-ip:
        enabled: true
        member-list:
          - 10.0.0.10
          - 10.0.0.11
          - 10.0.0.12
  map:
    products:
      time-to-live-seconds: 300
      max-size:
        policy: PER_NODE
        max-size: 10000
      eviction:
        eviction-policy: LRU

లేదా Java లో, మీరు ఇష్టపడితే:

@Configuration
public class HazelcastConfig {

    @Bean
    public Config hazelcastConfig() {
        Config config = new Config();
        config.setClusterName("orders-cluster");

        MapConfig productsMap = new MapConfig("products")
            .setTimeToLiveSeconds(300)
            .setEvictionConfig(new EvictionConfig()
                .setEvictionPolicy(EvictionPolicy.LRU)
                .setMaxSizePolicy(MaxSizePolicy.PER_NODE)
                .setSize(10_000));

        config.addMapConfig(productsMap);
        return config;
    }
}

మీ application class కు @EnableCaching జోడిస్తే, @Cacheable కోసం Spring automatically Hazelcast ను వాడుతుంది.

@SpringBootApplication
@EnableCaching
public class OrdersApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrdersApplication.class, args);
    }
}

మీకు లభించే Distributed Data Structures

Hazelcast విలువ building blocks నుండి వస్తుంది. అవి familiar Java APIs లాగా కనిపిస్తాయి, కానీ వాటి state cluster అంతటా share అవుతుంది, scale కోసం partitioned, failover కోసం replicated. మీరు తరచుగా చేరువయ్యేవి ఇవి.

IMap — Distributed HashMap

IMap ప్రధాన workhorse. ఇది ConcurrentHashMap లాగా కనిపిస్తుంది, కానీ దాని keys cluster అంతటా partitioned, ప్రతి partition ఒకటి లేదా ఎక్కువ backup nodes కు replicate అవుతుంది.

@Service
public class ProductCatalog {

    private final HazelcastInstance hazelcast;

    public ProductCatalog(HazelcastInstance hazelcast) {
        this.hazelcast = hazelcast;
    }

    public Product get(String productId) {
        IMap<String, Product> map = hazelcast.getMap("products");
        return map.get(productId);
    }

    public void put(String productId, Product product) {
        IMap<String, Product> map = hazelcast.getMap("products");
        map.put(productId, product);
    }

    public Product getOrLoad(String productId) {
        IMap<String, Product> map = hazelcast.getMap("products");
        return map.computeIfAbsent(productId, this::loadFromDatabase);
    }

    private Product loadFromDatabase(String productId) {
        // hits the DB
        return null;
    }
}

IMap మీకు predicates, indexes, మరియు entry listeners ఉచితంగా ఇస్తుంది. మీరు map.values(Predicates.equal("category", "books")) చేయవచ్చు, Hazelcast predicate ను ప్రతి partition కు parallel గా push చేస్తుంది.

IQueue, ITopic — Cluster-Wide Messaging

node restart ను తట్టుకుని, బ్రతికిన ఏ member అయినా consume చేసే queue కావాలా? IQueue ఒక distributed BlockingQueue.

IQueue<OrderEvent> queue = hazelcast.getQueue("order-events");
queue.put(new OrderEvent(orderId, "PLACED"));   // producer

OrderEvent next = queue.take();                  // consumer (any node)

broadcast కోసం — ప్రతి node ప్రతి message వింటుంది — ITopic వాడండి:

ITopic<CacheInvalidate> topic = hazelcast.getTopic("cache-invalidations");

topic.addMessageListener(message -> {
    String key = message.getMessageObject().getKey();
    localCache.remove(key);
});

topic.publish(new CacheInvalidate("product:123"));

IAtomicLong, FencedLock — Coordination Primitives

రెండు services తదుపరి sequence number గురించి agree అవ్వాలి. లేదా long-running operation చేస్తున్నప్పుడు record పై exclusive lock అవసరం. Hazelcast మీకు single JVM లో వాడే అదే primitives ను cluster-wide ఇస్తుంది.

// Cluster-wide counter
IAtomicLong sequence = hazelcast.getCPSubsystem().getAtomicLong("invoice-seq");
long next = sequence.incrementAndGet();

// Cluster-wide lock (with timeout — never use the unbounded version in production)
FencedLock lock = hazelcast.getCPSubsystem().getLock("order:" + orderId);
if (lock.tryLock(2, TimeUnit.SECONDS)) {
    try {
        // do the thing only one cluster member should be doing
    } finally {
        lock.unlock();
    }
}

CPSubsystem Raft consensus algorithm ను వాడుతుంది — ఈ primitives network partitions అంతటా correct, quorum అవసరం ఉండే cost తో. correctness ముఖ్యమైన చోట వాటిని వాడండి; అదే APIs యొక్క AP versions వేగంగా ఉంటాయి కానీ eventually consistent.

MultiMap మరియు ReplicatedMap

MultiMap key కి అనేక values store చేస్తుంది — tag indexes లేదా one-to-many lookups కోసం ఉపయోగపడుతుంది. ReplicatedMap మొత్తం dataset ను ప్రతి node మీద store చేస్తుంది — చాలా చిన్న, చాలా-తరచుగా-చదివే reference data కు perfect, ఎందుకంటే ప్రతి read ఒక local memory hit.

MultiMap<String, String> tagsByPost = hazelcast.getMultiMap("post-tags");
tagsByPost.put("post-1", "java");
tagsByPost.put("post-1", "hazelcast");
Collection<String> tags = tagsByPost.get("post-1");  // [java, hazelcast]

ReplicatedMap<String, String> countryByCode = hazelcast.getReplicatedMap("countries");
countryByCode.put("US", "United States");           // copied to every node

Hazelcast తో Spring @Cacheable

చాలా teams మొదట వాడేది అన్నిటికంటే simple ది: methods కు annotate చేయండి, work ను Spring చేయనివ్వండి, Hazelcast ను drop-in cache గా treat చేయండి.

@Service
public class ProductService {

    private final ProductRepository repository;

    public ProductService(ProductRepository repository) {
        this.repository = repository;
    }

    @Cacheable(value = "products", key = "#productId")
    public Product getProduct(String productId) {
        log.info("Loading product {} from DB", productId);
        return repository.findById(productId)
            .orElseThrow(() -> new ProductNotFoundException(productId));
    }

    @CachePut(value = "products", key = "#product.id")
    public Product updateProduct(Product product) {
        return repository.save(product);
    }

    @CacheEvict(value = "products", key = "#productId")
    public void deleteProduct(String productId) {
        repository.deleteById(productId);
    }

    @CacheEvict(value = "products", allEntries = true)
    public void clearAll() {
        // wipes the products cache cluster-wide
    }
}

Redis-backed cache తో ఏది వేరు: ఒక node product ను update చేసినప్పుడు, ప్రతి ఇతర node దాన్ని వెంటనే చూస్తుంది — ఎందుకంటే underlying IMap ఒకే distributed object. "services అంతటా cache invalidation" సమస్య పరిష్కరించాల్సిన అవసరం లేదు — cache నేరుగా shared.

Near Cache — Reads ఎక్కువ traffic అయినప్పుడు

Even an in-memory grid pays a small cost when data lives on a different partition. చాలా hot keys కు — config table, feature-flag map — network hop add అవుతుంది. Near Cache దీన్ని పరిష్కరిస్తుంది, recently accessed entries యొక్క local copy ను keep చేస్తూ, source మారినప్పుడు grid invalidations push చేస్తుంది.

NearCacheConfig nearCacheConfig = new NearCacheConfig()
    .setName("default")
    .setInMemoryFormat(InMemoryFormat.OBJECT)
    .setMaxIdleSeconds(60)
    .setEvictionConfig(new EvictionConfig()
        .setSize(1000)
        .setEvictionPolicy(EvictionPolicy.LRU));

MapConfig featureFlags = new MapConfig("feature-flags")
    .setNearCacheConfig(nearCacheConfig);

Reads ఇప్పుడు మొదటి hit తరువాత నేరుగా local memory నుండి వస్తాయి. Stale-data risk invalidation push మరియు max-idle ద్వారా bounded. "ఎంత stale చాలా stale" కు సరైన setting ఒక product question, technology question కాదు — framework default పై కాదు, data ఎలా behave అవుతుందో దాని ఆధారంగా ఎంచుకోండి.

MapStore — Database కు Read-Through మరియు Write-Through

కొన్నిసార్లు మీరు grid ను access layer గా కావాలనుకుంటారు. application map.get(id) call చేస్తుంది, entry memory లో లేకపోతే, Hazelcast database నుండి fetch చేసి, return చేసి, cache చేస్తుంది. map.put(id, value) పై Hazelcast మీ కోసం database కు persist చేస్తుంది. అదే MapStore.

public class ProductMapStore implements MapStore<String, Product> {

    private final JdbcTemplate jdbc;

    public ProductMapStore(JdbcTemplate jdbc) {
        this.jdbc = jdbc;
    }

    @Override
    public Product load(String key) {
        return jdbc.queryForObject(
            "SELECT id, name, price FROM products WHERE id = ?",
            new ProductRowMapper(),
            key);
    }

    @Override
    public Map<String, Product> loadAll(Collection<String> keys) {
        // batch load
        return jdbc.query(
            "SELECT id, name, price FROM products WHERE id IN (...)",
            new ProductRowMapper())
            .stream()
            .collect(Collectors.toMap(Product::getId, p -> p));
    }

    @Override
    public void store(String key, Product value) {
        jdbc.update(
            "INSERT INTO products(id, name, price) VALUES(?, ?, ?) " +
            "ON CONFLICT (id) DO UPDATE SET name = ?, price = ?",
            value.getId(), value.getName(), value.getPrice(),
            value.getName(), value.getPrice());
    }

    @Override
    public void delete(String key) {
        jdbc.update("DELETE FROM products WHERE id = ?", key);
    }
}

Config లో wired up:

MapStoreConfig mapStoreConfig = new MapStoreConfig()
    .setEnabled(true)
    .setImplementation(productMapStore)
    .setWriteDelaySeconds(0);   // 0 = synchronous write-through; >0 = write-behind batched

config.getMapConfig("products").setMapStoreConfig(mapStoreConfig);

Write-behind (writeDelaySeconds > 0) throughput కోసం writes ను batch చేస్తుంది. ఇది అంటే ఇంకా flush కాని writes ను node crash కోల్పోగలదు — explicit trade-off, team చూసే చోట document చేయండి.

EntryProcessor — Data మీదనే ఉండే Updates

entry update చేయడానికి natural way "get, modify, put". Distributed system లో ఇది రెండు network round-trips మరియు ఇద్దరు clients ఒకరి మార్పులను మరొకరు clobber చేయగల window. EntryProcessor data own చేసే partition కు code పంపుతుంది మరియు అక్కడ atomically run చేస్తుంది.

public class IncrementStockProcessor implements EntryProcessor<String, Product, Integer> {

    private final int delta;

    public IncrementStockProcessor(int delta) { this.delta = delta; }

    @Override
    public Integer process(Map.Entry<String, Product> entry) {
        Product product = entry.getValue();
        if (product == null) return 0;

        product.setStock(product.getStock() + delta);
        entry.setValue(product);
        return product.getStock();
    }
}

// Usage
IMap<String, Product> products = hazelcast.getMap("products");
Integer newStock = (Integer) products.executeOnKey("sku-42", new IncrementStockProcessor(-1));

ఒక round-trip, race లేదు, manual lock లేదు. aggregations కోసం — "ఈ predicate match చేసే ప్రతి entry పై ఈ counter increment చేయండి" — మీరు executeOnEntries(processor, predicate) వాడతారు మరియు Hazelcast అన్ని partitions అంతటా processor ను parallel గా run చేస్తుంది.

IExecutorService తో Distributed Compute

Grid data store చేయడమే కాదు — code కూడా run చేస్తుంది. IExecutorService cluster-aware ExecutorService, ఇది specific member కు, all members కు, లేదా అత్యంత ఉపయోగకరంగా, "ఈ key own చేసే member కు" task submit చేయగలదు, అలా task data పై run అవుతుంది, network మీద కాదు.

IExecutorService executor = hazelcast.getExecutorService("default");

// Run on a specific key's owner — task arrives where the data already lives
Future<Integer> future = executor.submitToKeyOwner(new InventoryCheck("sku-42"), "sku-42");

// Or run on every member and aggregate
Map<Member, Future<Long>> results = executor.submitToAllMembers(new RowCountTask());
long total = results.values().stream()
    .mapToLong(this::getQuietly)
    .sum();

task class ప్రతి member యొక్క classpath పై ఉండాలి. చాలా data scan చేయాల్సిన ad-hoc analytics లేదా scheduled work కు, ఈ pattern ఒక node కు అన్నీ తిరిగి pull చేసి centrally process చేయడం కంటే మెరుగు.

Production Considerations

Cluster discovery. Multicast laptop మీద పనిచేస్తుంది, production లో దాదాపు ఎక్కడా పనిచేయదు. explicit member list తో TCP/IP వాడండి, లేదా cloud deployments కు Kubernetes / AWS / Azure discovery plugins వాడండి, ఇవి members ను platform యొక్క service discovery ద్వారా ఒకరినొకరు find చేయనిస్తాయి.

Backups. Default గా IMap ప్రతి partition యొక్క ఒక synchronous backup ను వేరే member పై keep చేస్తుంది. మీరు కోల్పోలేని data కు, backup-count ను 2 కు raise చేయండి — అప్పుడు ప్రతి partition మూడు nodes మీద ఉంటుంది, మరియు మీరు data loss లేకుండా రెండు కోల్పోవచ్చు. cost: ఎక్కువ memory మరియు కొంచెం slower writes.

Split-brain. Network partition అయి cluster split అయితే, రెండు halves writes accept చేస్తూ ఉంటాయి. connectivity తిరిగి వచ్చినప్పుడు Hazelcast split ను detect చేస్తుంది మరియు reconcile చేయడానికి merge policy run చేస్తుంది — default ను rely అయ్యే బదులు ఒకటి explicitly ఎంచుకోండి (LATEST_UPDATE, HIGHER_HITS, లేదా custom policy). partitions అంతటా consistent గా ఉండవలసిన data కు, CP subsystem వాడండి.

Memory management. Off-heap (HD-Memory) Java heap బయట data store చేయనిస్తుంది, అలా GC కు scan చేయడానికి ఏమీ ఉండదు. multi-gigabyte caches కు ఇది snappy cluster మరియు ప్రతి నిమిషం ఒక second pause అయ్యే cluster మధ్య తేడా.

Observability. Hazelcast box లోంచే JMX metrics publish చేస్తుంది, మరియు Management Center cluster health కు UI ఇస్తుంది. రెండింటినీ మీ monitoring కు wire చేయండి; slow partition గురించి customer నుండి తెలుసుకోకండి.

Hazelcast కు ఎప్పుడు చేరువ అవ్వాలి

సమస్య కేవలం "database వేగంగా చేయడం" కాదు అయినప్పుడు Hazelcast toolbox లో తన స్థానం సంపాదిస్తుంది. మీకు ఇవి అవసరమైనప్పుడు దాన్ని వాడండి:

• ephemeral state (sessions, leader election state, in-flight workflow state) కు source of truth కూడా అయ్యే cache.
• Cluster-wide coordination — distributed locks, atomic counters, message broadcast — separate ZooKeeper లేదా etcd standup చేయకుండా.
• చుట్టూ ship చేయలేనంత పెద్ద data పై compute — data ను function కు కాదు, function ను data కు పంపడం.
• ప్రతి application instance కూడా grid member అయిన embedded grid, మరియు operate చేయడానికి separate cache tier లేకుండా sub-millisecond reads కావాలి.

మీకు key-value cache మాత్రమే అవసరమైతే మరియు మీ team ఇప్పటికే Redis run చేస్తుంటే, problem deserve చేసే దానికంటే Hazelcast ఎక్కువ grid కావచ్చు. వ్యతిరేకం కూడా నిజమే: ఏళ్ళ క్రితం Redis pick చేసిన team ఇప్పుడు Redis ఏది కాదో దానికి భర్తీగా distributed locks, queues, మరియు Lua scripts sprinkle చేస్తుంటే — ఆ team కు తరచుగా Hazelcast-shaped problem ఉంటుంది, వారు hard way లో solve చేస్తున్నారు.

ఒక చివరి మాట

Problem ఆకారానికి match అయ్యే tool ఎంచుకోండి. మొదటిసారి Hazelcast వాడినప్పుడు, official tutorial friendly గా ఉంది మరియు embedded mode operate చేయడానికి ఒక తక్కువ thing అని అది pick చేశాను. రెండవసారి వాడినప్పుడు, మూడు services shared workflow పై coordinate చేయడానికి ప్రయత్నిస్తున్నాయి మరియు HTTP పై protocols invent చేయడంతో అలసిపోయాను అని pick చేశాను. honest pattern: coordination layer గా పెరిగే cache అనేది IMDG దేని కోసం design చేయబడిందో అదే.

తరచుగా అడిగే ప్రశ్నలు

Hazelcast కేవలం Redis competitor నా?

Caching లో overlap అవుతుంది, కానీ ఇది వేరే category tool. Redis rich data types మరియు single-threaded core తో remote key-value server. Hazelcast distributed in-memory grid — మీ JVMs లో భాగంగా run అవుతుంది (లేదా dedicated cluster గా), parallel compute support చేస్తుంది, మరియు cluster అంతటా Java-shaped concurrency primitives ఇస్తుంది. Pure caching కు అవి similar గా కనిపిస్తాయి; distributed coordination, compute-with-data, embedded scenarios కు, అవి equivalent కావు.

Hazelcast embedded లేదా client-server mode లో run చేయాలా?

Embedded operationally simpler — మీ service మరియు grid కలిసి scale, కలిసి deploy, కలిసి fail అవుతాయి. Ops data tier ను separately size చేయాలనుకున్నప్పుడు, application restarts cache restarts కూడా అవ్వకూడదనుకున్నప్పుడు, లేదా grid multiple polyglot services అంతటా shared అయినప్పుడు client-server సరైనది. చాలా single-Java-service teams embedded తో మొదలెడతారు మరియు ఆ constraints చూపించబడితేనే client-server కు మారతారు.

Hazelcast JCache లేదా Caffeine కంటే ఎలా వేరు?

Caffeine fast local cache — ఒక JVM, replication లేదు, cluster awareness లేదు. JCache (JSR 107) standard cache API, దీన్ని అనేక products (Hazelcast మరియు Caffeine తో సహా) implement చేస్తాయి. Hazelcast కింద ఉన్న distributed system, cluster membership, partitioning, replication, మరియు మిగతావాటితో. మీ సమస్య ఒక JVM లో సరిపోతే, Caffeine వేగంగా మరియు సరళంగా ఉంటుంది. instances అంతటా data shared కావాలంటే, Hazelcast పెద్ద సమస్యకు పెద్ద జవాబు.

Stream processing కోసం Hazelcast Jet ఏంటి?

Jet core product లో folded అయింది. మీ IMap hold చేసే అదే nodes Kafka topic నుండి read చేసి, map పై join చేసి, మరో IMap కు write చేసే streaming pipeline run చేయగలవు — grid వదిలి వెళ్ళకుండా. low-latency state lookups తో event-driven enrichment కు, JVM ecosystem లో Jet మరింత elegant answers లో ఒకటి.

నా మొత్తం cluster restart అయితే Hazelcast survive అవుతుందా?

Box లోంచే, data memory లో ఉంటుంది మరియు full cluster restart దాన్ని కోల్పోతుంది. Full restart తట్టుకోవడానికి, Persistence (గతంలో Hot Restart Store) configure చేయండి — entries ప్రతి member పై local disk కు mirror అవుతాయి, అలా cluster తిరిగి వచ్చినప్పుడు, members తమ partitions reload చేసి తమ data intact తో join అవుతారు. ఎలాంటి data loss తట్టుకోలేని workloads కు, దాన్ని database కు write through చేసే MapStore తో combine చేయండి — fast recovery కోసం local persistence, durable record of truth కోసం database.