Scaling Out Redis: Read-Only Slaves or Cluster?
Thankfully, no humans are enslaved by Redis.
Instead, it uses asynchronous replication “for scalability ... or simply for data redundancy.”
Also, “a [Redis] master can have multiple slaves … [that] are able to accept other slaves’ connections. Aside from connecting a number of slaves to the same master, slaves can also be connected to other slaves in a graph-like structure.”
Setting up Redis replication is trivial and its flexibility provides great power.
Classic use cases for Redis’ replication are:
- Scaling performance by using the replicas for intensive read operations.
- Making data redundant in multiple locations.
- Offloading data persistency costs from the master by delegating it to the slaves.
As a Redis Service provider, we are often asked why we do not provide access to our read-only replicas. It’s a valid question, and our answer relates to each of the use cases:
Our service scales by allocating resources to the databases that we manage. We deploy clusters on which we create database instances. Each database instance is sharded across the cluster’s members and each of the shards is split-able, highly available, relocatable and dynamically (re)sizable. To provide for more reads (or writes, RAM, CPUs, or bandwidth), we just reshard and rebalance as needed. Our cluster immediately and transparently provides access to the new shards, hence there is no need to access read-only replicas.
We use replication for data redundancy at the shard level. Our redundancy is augmented with monitoring and auto-failover mechanisms that are internal to our service and do not require any user intervention.
Our replicas are configured to manage data persistency so the master shard is free to process requests.
Since replication is asynchronous, it can introduce inconsistencies when accessing stale data. Sharding, on the other hand, does not exhibit that property and is therefore a preferable approach to addressing read and write scaling challenges. Because our managed service addresses scalability (via sharding), redundancy (with auto-failover) and load management, there are only a handful of scenarios in which having access to the read replicas is of any value.
For example, a replica can be set up to give read-only database access to interested parties (e.g. development).
We are planning to support this functionality in the future, so if you have other use cases for read replicas we’d love to hear about them. Let us know if you are using replication for purposes other than scaling, redundancy or offloading - just drop us a line at firstname.lastname@example.org or contact our support.
Redis Labs is the open source home and commercial provider of Redis, a database benchmarked as the world’s fastest. The company’s software and service solutions power cutting edge applications with blazing fast enterprise-class Redis and are trusted by thousands of customers for high performance, infinite scalability, true high availability and best-in-class expertise. Redis has been ranked the #1 NoSQL (and #4 database) in User Satisfaction and Market Presence based on user reviews (G2 Crowd), the most popular NoSQL database in containers (DevOps.com and ClusterHQ), the #2 NoSQL among Top 50 Developer Tools & Services (Stackshare), the fastest growing database since January 2013 and among the top three NoSQL databases (DB-engines).
Interact with Redis
Enter your Redis commands,
see how fast it responds!
See Our Open Source Contributions
Get the hottest Redis news with our