Redis: Master-Slave Architecture
Redis is based on Master-Slave Architecture, What Is It?
Redis server can be run in two modes:
- Master Mode (Redis Master)
- Slave Mode (Redis Slave or Redis Replica)
We can configure which mode to write and read from. It is recommend to serves writes through Redis Master and reads through Redis Slaves.
Redis Master does replicate writes to one or more Redis Slaves. The master-slave replication is done asynchronously.
What if Redis Master goes Down?
Now here we have two choices:
- Add new machine as Redis Master
- Make any existing Redis Slave as New Redis Master
Problem with first approach where we add new machine as new Redis Master is that this will sync/replicate Zero data to all Redis Slaves means we loose all data.
Second approach is recommended as existing slave will already have all data and once we make this Redis Slave as new Redis Master, this will sync/replicate data to all Redis Slaves which means we did not loose data.
What if Redis Slave goes Down?
Since all Redis Slaves are having latest set of data (by replication from Redis Master), if any of the Redis Slave goes down, other Redis Slave will serve read requests.
Note: By default every machine you have for Redis is Redis Master, you have to change role of redis machine to Slave by using ‘slaveof’ command.
Where does Redis fit in CAP theorem?
CAP: Consistency, Availability and Partition Tolerance.
Redis is AP system. Lets understand why Redis doesn’t provide strong Consistency.
What happens when Redis Master receives write request from Client:
- It does acknowledge to Client.
- Redis Master replicates the write request to 1 or more slaves. (Depends on Replication factor).
Here you can see, Redis Master does not wait for replication to be completed on slaves and does acknowledgment to client immediately.
Now lets us assume, Redis Master acknowledged to client and then got crashed. Now one of the Redis Slave (that did not receive the write) will get promoted to Redis Master, loosing the write forever.
Can we improve consistency with Synchronous replication?
Now we may think to improve consistency by forcing the Redis Master to replicate first and then send acknowledgment to client but this results in low performance for write requests. It is similar to synchronous replication.
But again with synchronous replication it is not guaranteed to have strong Consistency. There might be a scenario that a slave that was not able to receive the write is promoted to master.
I am sure you must have learned from this Story. Feel free to give your suggestions or write me for any topic you want to cover.
Write me here at sunnyg28@gmail.com
