Hey there, let's walk through each of your questions with clear, practical explanations tailored to your use case:

1. Automatic Data Redistribution When a Node Hits Memory Threshold (15GB Partitioned Cache) #

Redis Cluster #

Redis Cluster doesn’t automatically redistribute data across nodes when a single node hits its memory limit. The cluster uses fixed hash slots assigned to each node—once slots are mapped, they don’t move unless you manually trigger a reshard (via redis-cli --cluster reshard or automation scripts). When a node reaches its maxmemory threshold, it’ll just kick off its configured eviction policy to free up space on that specific node, not shift data to other nodes with available memory.

Apache Ignite #

Yes, Ignite supports automatic data redistribution out of the box. When a node hits its memory threshold (configured via memoryPolicy settings like maxSize), Ignite will automatically migrate excess data partitions to other cluster nodes that have free memory. This dynamic rebalancing is part of Ignite’s core distributed cache functionality, so you don’t need manual intervention here.

2. Cache Eviction Policy Trigger Timing & Node Requirements #

Redis Cluster #

Eviction policies in Redis are per-node, independent triggers. Each node checks its own maxmemory usage—when that single node hits the limit, it executes its eviction strategy (e.g., allkeys-lru, volatile-ttl) on its local data. There’s no requirement for all nodes to reach their memory caps; eviction happens node-by-node as needed.

Apache Ignite #

Similar to Redis, eviction (or data overflow, when using persistent storage) is triggered per node when it reaches its memory threshold. You don’t need every node to be full for eviction to kick off on a single node. Additionally, if you have rebalancing enabled, Ignite might first try to move data to other nodes before evicting/overflowing to disk, depending on your configuration.

3. Node Failure/Addition Handling & Backup Mechanisms #

Redis Cluster #

• Node Addition: You need to manually reshard hash slots from existing nodes to the new node (or use automation tools). Redis Cluster won’t automatically rebalance slots when a new node joins—this is a deliberate design choice to avoid unexpected data movement.
• Node Failure:
  • If a master node fails, the cluster automatically elects one of its attached slave nodes as the new master (provided there’s enough quorum).
  • If a slave node fails, it just drops out of the cluster; you’ll need to manually add a new slave or configure auto-provisioning if using external tools like Sentinel (though Sentinel is more commonly used with standalone master-slave setups, not Cluster).
• Backup Mechanism: Redis Cluster relies on slave replication (asynchronous) for redundancy. Each master can have multiple slaves that replicate its data. Persistence is per-node: you can enable RDB or AOF on each node to save data to disk for recovery, but there’s no shared distributed persistence layer.

Apache Ignite #

• Node Addition: Ignite automatically detects new nodes and triggers data rebalancing—existing partitions are split and migrated to the new node to evenly distribute load, no manual steps required (as long as rebalanceEnabled=true, which is default).
• Node Failure:
  • If a node goes down, Ignite automatically fails over to backup partitions (you configure the number of backups per partition via backups=N). Backup partitions are stored on separate nodes, so the cluster remains available immediately.
  • Once a replacement node joins or the failed node comes back online, Ignite rebalances data to restore the required number of backups.
• Backup Mechanism: Ignite uses distributed, partition-level backups. Each data partition has N copies spread across different nodes. Combined with its distributed persistent store, Ignite ensures data durability across the cluster—each node stores its assigned partitions (and backups) to disk, so data isn’t lost if multiple nodes fail (as long as at least one backup copy exists).

4. Implementing Hybrid Memory-Disk Cache with Full Disk Retention #

Can Redis Do This? #

Not natively. Redis’s RDB/AOF persistence is for data recovery, not active querying. When Redis runs, all data lives in memory—disk files are just snapshots/logs that get loaded into memory on startup. There’s no built-in way to query the disk directly when a key isn’t in memory, then automatically load it into memory while evicting other keys to disk (and keeping all 100 records on disk permanently).

To mimic this behavior, you’d need to build a custom layer on top of Redis: manage your own disk storage (e.g., local file system, object storage), check Redis first, then your disk store, then Sybase. You’d also have to handle evicting keys from Redis and writing them back to disk manually—this adds a lot of custom code complexity.

Apache Ignite’s Native Support #

This is exactly what Ignite’s distributed persistent store was designed for. With Ignite, you can configure:

• A memory tier that holds only the 40 most frequently accessed records (via LRU eviction policies)
• A disk tier that stores all 100 records permanently
• Automatic load-on-demand: when a request misses memory but hits disk, Ignite loads the record into memory and evicts a less frequent record to disk (while keeping the disk copy intact)
• Built-in integration with Sybase as the underlying data source (you can configure Ignite to pull data from Sybase only when neither memory nor disk has the record)

This all works out of the box without custom code—Ignite handles the tiered storage, eviction, and data loading logic for you.

内容的提问来源于stack exchange，提问作者Gopu_Tunas