【Redis】Redis面试热点

Redis 集群有哪些方案？

主从复制：解决了高并发问题
哨兵模式：解决了高并发，高可用问题
分片集群：解决了海量数据存储，高并发写的问题

主从复制

图示：

在这里插入图片描述
主从复制：单节点 Redis 并发能力有限，为了进一步提高 redis 并发能力，所以搭建主从集群，实现读写分离。主节点是写，从节点是读，这就是主从复制
主从同步流程，分为两种情况，分为全量同步和增量同步

全量同步

在这里插入图片描述

根据上图：

同步的时候，从节点首先会和 master 节点建立连接，携带replid、offset请求数据同步
master 节点会判断是否第一次同步（是根据 replid 来进行判断）。
如果说是第一次，那么 master 就会返回 master 的数据版本信息（并且还会返回 replid 和 offset），进而从节点进行保存版本信息。
接下来 master 节点会执行 bgsave 命令，生成 RDB 文件，并发送给从节点。
从节点清空本地数据，加载 RDB 文件。
到这里，所有流程其实完毕了，但是在执行 bgsave 命令期间，肯定是会有新的命令执行的。所以说，在 master 节点执行 bgsave 命令期间，还会在 repl_baklog 中记录这期间所有命令，并发送给从节点，从节点收到后执行命令。这样就保证数据不会丢失。
假如根据 replid 判断发现不是第一次同步，那么这个时候就需要用到 offset 了。根据 offset 来进行判断偏移量，然后再次进行同步。

增量同步

在这里插入图片描述

从节点发送同步请求，master 节点判断 replid 是否一致（肯定是一致的），不是第一次同步就会去日志文件中获取 offset 后的数据，然后发送repl_baklog文件中 offset 后的命令，从节点执行命令即可。

哨兵模式

主从复制解决了高并发问题，但是我们能保证Redis不宕机么？那万一宕机了，我们又怎么知道呢？那么就引入哨兵模式，哨兵模式的引入就保证了Redis的高可用问题。
哨兵模式三个作用：监控，自动故障恢复，通知

在这里插入图片描述

服务状态监控

在这里插入图片描述

哨兵模式中有心跳机制，每隔1s会向集群中每个实例发送ping命令，如果回复pong，那就说明OK。如果某一个哨兵发现某一个实例在一定时间里没有回应，那么认为该实例是主观下线。若是超过一定数量（最好是超过哨兵实例数量的一半。）的哨兵都认为这个实例主观下线，那么这个实例客观下线。

脑裂

脑裂：主节点、从节点、哨兵处于不同网络分区，导致哨兵没有感知到主节点，所以哨兵又选举出了一个从节点为主，这样就存在了两个master，这样导致客户端还在老的主节点那里写数据，新节点无法同步。当网络恢复后，哨兵将老的主节点降为从节点，这是再从新的主节点同步数据，就会导致数据丢失。
解决办法：修改Redis的配置，设置最少的从节点数量以及缩短主从数据同步的延迟时间，达不到要求就拒绝请求。