Creating Regional Replicas With Multiple Redis Sentinels on Java
Redis provides a fast, in-memory data store for many of today's top applications. Java developers turn to Redis because they need best-in-class performance for high-availability deployments. Regional replicas are typically a part of these implementations, with each replica providing optimal performance to different parts of the world.
Developers often take advantage of the Redis Sentinel functionality to maintain high availability across geographically distributed replicas. However, developers may encounter data consistency issues if they deploy standard, out-of-the-box Sentinels. Here's what to know about creating regional replicas with multiple Redis Sentinels on Java—and how to best avoid the problems of an "eventually consistent system."
What Are Redis Sentinels?
Redis Sentinel is a distributed coordination service for Redis deployments. It monitors a set of Redis master servers, detects failures, and automatically promotes a healthy replica to become the new master. Here's a breakdown of Sentinel's functionalities:
- Master monitoring: Sentinels constantly ping Redis master servers to assess their health.
- Failover: If a Sentinel detects a master failure, it initiates a failover process. This involves selecting a suitable replica, promoting it to become the new master, and notifying other Sentinels and clients about the change.
- Configuration management: Sentinels share information about the Redis cluster configuration, enabling automatic reconfiguration after a failover.
Redis Sentinels vs. Redis Clusters
It's common for Java developers to deploy regional replicas with Redis Clusters—and it's not always clear which is the better solution for any given implementation.
While both Sentinels and Redis Clusters provide HA for Redis, they cater to different use cases:
- Redis Sentinels are ideal for deployments where high availability is a priority, as they offer a simple automatic failover mechanism in master-replica setups.
- Redis Clusters are designed for horizontal scaling and data sharding across multiple Redis nodes. They offer horizontal scaling and high-performance data distribution but can be more complex to deploy and manage.
Redis Sentinels as an Eventually Consistent System
It's important to note that Redis Sentinels are an eventually consistent system. This means that data writes are replicated asynchronously from the master to replicas. Therefore, there might be a slight delay between a write operation on the master and its reflection on the replica.
The Redis Sentinel documentation notes that there are two guaranteed ways to avoid losing acknowledged writes in an eventually consistent system:
- Use synchronous replication (and a proper consensus algorithm to run a replicated state machine).
- Use an eventually consistent system where different versions of the same object can be merged.
The documentation then points out that Redis can't use either of these solutions. The second is possible but only with the help of proxies. Proxy servers introduce their own issues with regional replica implementations, including latency and additional failure points.
How Redisson PRO's Multi-Sentinel Mode Provides a Regional Replicas Solution
Redisson PRO's Multi-Sentinel mode offers Java developers a streamlined approach to managing regional replicas through active and passive Redis Sentinel setups. A single active Sentinel setup is the primary authority for failover decisions and configuration management in this configuration.
Multiple passive Sentinel setups in different regions monitor the same Redis master-slave configuration but remain dormant unless the active Sentinel fails. If the active Sentinel becomes unavailable, one of the passive Sentinels automatically takes over, ensuring continuous availability and data consistency across all regions.
Redisson's configuration API allows you to specify the address of any active Redis Sentinel node, followed by the address of any passive Redis Sentinel node, using the useMultiSentinelServers()
method:
Config config = new Config();
config.useMultiSentinelServers()
.setReplicationMode(ReplicationMode.ASYNC)
.setMasterName("mymaster")
// use "rediss://" for SSL connection
.addSentinelAddress("redis://sentinel_primary_cluster:26389",
"redis://sentinel_secondary_cluster1:26379",
"redis://sentinel_secondary_cluster2:26379")
RedissonClient redisson = Redisson.create(config);
In addition, the replicationMode
parameter provides a simple way to ensure data synchronization across multiple Sentinels. Here are the available values and what they do:
NONE - No replication executed by Redisson. Replication should be executed on the Redis side,
SYNC - Each Redisson method invocation which modifies data is completed only if it has been replicated to all Redis setups,
ASYNC - Each Redisson method invocation which modifies data doesn't wait for replication to complete on other Redis setups.
To learn more about Multi-Sentinel mode and Redisson PRO's other solutions tailored for Java developers, visit the Redisson website.