Reader and writer endpoints for Redis

[ishan-tripathi]

Currently, Laravel supports a single endpoint for Redis; however, many cloud providers "provide" or projects "need" to have separate endpoints for reading and writing data to Redis.
Can we look to add multi-host support for Redis in laravel, just like database connection?

Database:

[ 'read' => [ 'host' => [ '192.168.1.1', '196.168.1.2', ], ], 'write' => [ 'host' => [ '196.168.1.3', ], ],

Redis (Currently): 'host' => env('REDIS_HOST', '127.0.0.1'),

Redis (Requesting): 'host' => [ 'read' => [ 'host' => [ '192.168.1.1', '196.168.1.2', ], ], 'write' => [ 'host' => [ '196.168.1.3', ], ],

[henzeb]

Look at databases.php, by default you have a cache and a session store, pointing at the same redis instance, but you should already be able to add multiple redis instances either in cloud or single mode. Just pass the name of the store. https://laravel.com/docs/9.x/cache#accessing-multiple-cache-stores

[ishan-tripathi]

Yes, correct but this adds an over the head of maintaining another configuration and developers have to explicitly define the connection if we can have it similar to how we handle read and write connections for databases like MySQL it would be more short-hand and developer-friendly solution.

[datashaman]

Hitting this issue now. We have a Redis cluster (cluster mode disabled) in AWS. Our metrics graphs show that all traffic is being sent to the primary endpoint. This is (i guess) expected, since we are only connecting to the primary node.

• With cluster mode disabled, we would have to connect explicitly to primary and reader endpoints for each operation.
• With cluster mode enabled, the replica nodes are not redirected to unless you issue a readonly command at the beginning of the session.

Since most if not all our Redis usage is the session driver, we have very little control over how that is done.
So essentially we have a multi-node cluster just for failover. The replicas are not being used to answer requests, only replicating.

So we are faced with these courses of action:

• Remove read replicas, since they are literally only used by replication. Beef up a single node so it can handle all requests. Seems fragile. Maybe leave one for failover.
• Rewrite the session code in laravel framework to handle primary and reader endpoints.
• Enable cluster mode and rewrite session code in laravel framework to issue readonly first for all reads.

[datashaman]

Hmm, this specific project does not have clusters setup in config. I may eat my words soon. Investigating.

[sfong22]

Did you end up eating your words or is this still an outstanding enhancement idea?

[mohamedhekal]

You raise a good point. Adding support for multiple Redis hosts in Laravel similar to database connections would be beneficial, especially for configuring read replicas and improving performance/scalability.

Here are a few ways Laravel could potentially implement multi-host Redis support:

Allow defining separate read and write hosts in the Redis configuration file, like you demonstrated. Laravel could then automatically send read operations to the read hosts and write operations to the write host.
Add new connection methods like redisRead(), redisWrite() that allow manually specifying which host to use for that operation.
Allow defining multiple named Redis connections in config, each with different hosts, and selecting which one to use per operation. Similar to database connections.
Abstract the Redis client into a interface that could have multiple implementations, and inject the appropriate read or write client dynamically.
The key requirements would be preserving backwards compatibility and keeping the interface simple. As Redis is commonly used for caching and queueing, this feature would need to work smoothly with Laravel's cache, session and queue components too.

[sfong22]

Great points.

An issue here may be with consistency to replicas. AWS memory db for redis appears to have eventual consistency to the replicas. While this lag is usually ms latency it could be detrimental to some applications or operations that require strong consistency. While caches are likely not impacted by weak consistency, queues could be.

Weak consistency may be particularly relevant for queues because if the queue runners are observing replicas then two runners observing different replicas can acquire the same job due to the weak consistency.

[andreladocruz]

just to bring the conversation up.