Redis availability and CAP theorem

Question

In CAP theorem, Redis is specified as a database which lacks availability (which has partition tolerance and consistency).

But there are many places where Redis is considered as a high availability key-value store.

What is right? I would be thankful if you could provide an in-depth answer.

Answer 1

According to the book "Redis Essentials" in page 170：

Since Redis Sentinel and Redis Cluster are distributed systems, it is fair to analyze them using the CAP theorem. Network partitions are unavoidable in a distributed system, so it should ensure either consistency or availability; that is, it should be either CP or AP.

Theoretically, Redis Sentinel and Redis Cluster are neither consistent nor available under network partitions. However, there are some configurations that can minimize the consistency and availability problems. They cannot provide availability because there is a quorum that needs to agree on a master election, and depending on the quorum's decision, part of the system may become unavailable.

They cannot provide consistency under network partitions, for example, when two or more partitions accept writes at the same time. When the network heals and the partitions are joined, some of those writes will be lost (conflicts are not automatically solved, nor are they exposed for clients).

Hope this will help you.The online book:（https://subscription.packtpub.com/book/big_data_and_business_intelligence/9781784392451/9/ch09lvl1sec52/the-cap-theorem）

Answer 2

I would start by saying that there is no 'CA' category. Most systems are CA in absence of Network Partition.

CAP theorem is applicable for Distributed Data Stores and comes into effect when Network Partition (P) happens. It says when (P) happens then the Distributed Data Store has to chose between Consitency (C) or Avaiability (A).

i.e. when P happens then either it will be PA or PC.

RDBMS used to be PC but with time they have started supporting PA as well.

Coming to Redis specifically, High Availability is more than being Partition Tolerance. Redis has Master Slave architecture and if a Master fails then Redis Sentinels promote a Slave to be the new Master, making the entire solution highly available. And a master can fail (or become unavailable) for number of reasons (e.g. out of memory), it isn't necessarily due to a Network Partition.

Then comes the case of Network Partition (P), and if (P) happens then Redis becomes unvailable in the minority partition. That's why from CAP perspective, Redis is CP because it becomes unavailable in minority partitions. Please note it will still be available in majority partition.

You can read more about Redis High Availability here. Refer para titled "Consistency under partitions" for details around Partitioning.

Redis is also called eventually consistent because when (P) happens, the minority parition is still available for a few seconds and any writes done during that period on the minority parition will eventually get discarded.