Read/Write Separation for Sentinel in Jedis

[a-TODO-rov]

Summary

Enable native read/write separation for Redis Sentinel deployments in Jedis. This would allow applications to route writes to the Sentinel-elected master and reads to replicas, while transparently handling topology changes driven by Sentinel.

Motivation

Currently, Jedis in Sentinel mode only connects to the master. Applications that want to take advantage of replicas for read scaling must implement their own connection management and failover handling. This increases complexity and risk.

A built-in feature would:

• Simplify application code
• Reduce operational errors during failover
• Improve scalability by offloading reads to replicas

Proposal

Introduce Sentinel-aware connection handling that:

1. Maintains connections to both the master and replicas.
2. Automatically updates pools when Sentinel events occur (master switch, replica changes).
3. Routes read operations to replicas, and write operations to the master.
4. Falls back to master for reads when no replicas are available.

Benefits

• Transparent handling of failover and topology changes
• Improved scalability via replica reads
• Less boilerplate and custom failover logic in applications

Considerations

• Reads from replicas are eventually consistent
• Optionally allow fallback to master when replicas are unavailable
• Ensure predictable behavior during master failover events

Related Work

• PR Implemented read-write separation based on sentinel #4209 explored adding a replica pool for Sentinel.
• Community discussions have highlighted the need for native support to avoid duplicate custom implementations.

[koleter]

Do you mean that in the JedisSentineled class, the master node and the slave node list are maintained by the monitoring channels, and then the request is automatically distributed to the nodes of different roles according to the command type? For example, write commands are sent to the master node, and read commands are sent to the slave node.

[a-TODO-rov]

Thanks, @koleter — that’s the right direction. Some clarifications on how we should shape it:

• maintain master + replica set via Sentinel
• extend SentinelListener for all required slave events
• routing
  • writes → master, reads → replicas.
  • Fallback when no replicas are healthy: default to master (configurable)
• API surface: prefer explicit caller intent (read vs write) for the MVP :
  • Automatic command-type detection is useful, but it’s tricky (Lua, modules, multi-key ops, readonly commands that can mutate). We can add it later as opt-in with a conservative classifier.
  • For now let's think readIntent -> slaveConnection , writeIntent -> masterConnection --> executeCommand

[koleter]

@a-TODO-rov I created a new PR that implements a simple Read-Write Separation based on the JedisSentineled class. Please take a look, especially the changes to the command.
#4231

[ggivo]

Hi @koleter (and team),

Thanks for your continued work on read/write separation for Sentinel.

I noticed that PR #4209 (“Implemented read-write separation based on sentinel”) predates but overlaps with PR #4231 (“Implemented read-write separation based on JedisSentineled”)

Could you clarify whether #4231 supersedes #4209, and if so, whether we can consider PR #4209 safe to close to reduce duplication?

cc: @a-TODO-rov