开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第18天，点击查看活动详情
Redis基于主从架构，它是什么?
Redis服务器有两种运行模式:
主模式(Redis Master)
从模式(Redis Slave或Redis Replica)
我们可以配置从哪种模式写和读。建议通过Redis Master进行写操作，通过Redis Slaves进行读操作
如果Redis Master崩溃了怎么办?
现在我们有两个选择:
添加新机器作为Redis Master
使任何现有的Redis从作为新的Redis主
第一种方法的问题是，我们添加新机器作为新的Redis Master，这将同步/复制零数据到所有Redis slave意味着我们丢失所有数据。
第二种方法是推荐的，因为现有的slave已经有了所有的数据，一旦我们把这个Redis slave作为新的Redis Master，这将同步/复制数据到所有Redis slave，这意味着我们没有丢失数据。
如果Redis奴隶下降怎么办?
由于所有的Redis Slave都有最新的数据集(通过从Redis Master复制)，如果任何一个Redis Slave宕机，其他Redis Slave将服务读请求。
注意:默认情况下，你拥有的每台机器都是Redis Master，你必须使用' slaveof '命令将Redis机器的角色更改为Slave。
Redis适用于CAP定理的什么地方?
CAP:一致性、可用性和分区容忍度。
Redis是AP系统。让我们来理解为什么Redis不能提供强大的一致性。
当Redis Master收到客户端的写请求时会发生什么:
它确实向客户端确认。
Redis Master将写请求复制到1个或多个slave。(取决于复制因子)。
在这里你可以看到，Redis主不等待复制完成在奴隶和立即向客户端确认。
现在让我们假设，Redis Master确认客户端，然后崩溃。现在一个Redis Slave(没有收到写)将被提升到Redis Master，永远失去写。
我们能提高同步复制的一致性吗?
现在我们可能会想通过强制Redis Master先复制，然后再向客户端发送确认来提高一致性，但这导致写请求的性能较低。它类似于同步复制。
但是，对于同步复制，它不能保证有很强的一致性。可能存在这样一种情况，即无法接收写操作的从服务器被提升为主服务器。
