大厂面试官问我：哨兵怎么实现的，Redis 主节点挂了，获取锁时会有什么问题？【后端八股文六：Redis集群八股文合集】

 hello hello~ ，这里是绝命Coding——老白~💖💖 ，欢迎大家点赞🥳🥳关注💥💥收藏🌹🌹🌹

💥个人主页：绝命Coding-CSDN博客
💥 所属专栏：后端技术分享
这里将会不定期更新有关后端、前端的内容，希望大家多多点赞关注收藏💖

   往期内容：

大厂面试官问我：Redis处理点赞，如果瞬时涌入大量用户点赞（千万级），应当如何进行处理？【后端八股文一：Redis点赞八股文合集】-CSDN博客

大厂面试官问我：布隆过滤器有不能扩容和删除的缺陷，有没有可以替代的数据结构呢？【后端八股文二：布隆过滤器八股文合集】-CSDN博客

大厂面试官问我：Redis持久化RDB有没有可能阻塞？阻塞点在哪里？【后端八股文三：Redis持久化八股文合集】-CSDN博客

大厂面试官问我：Redis内存淘汰，LRU维护整个队列吗？【后端八股文四：Redis内存淘汰策略八股文合集】-CSDN博客

本文为【Redis集群八股文合集】初版，后续还会进行优化更新，欢迎大家关注点赞评论交流~

大家第一眼看到这个标题，不知道心中是否有答案了？在面试当中，面试官经常对项目亮点进行深挖，来考察你对这个项目亮点的理解以及思考！这个时候，你如果可以回答出面试官的问题，甚至是主动说出自己的思考，那在面试中是大大加分的~

Redis的集群

以前的做法：
比如说我们有个Redis的实例挂了，有用户反馈，然后我们运维的就加班加点就是去更新服务器，就是去启用一个新的Redis实例，重启起来，然后把数据恢复进去

高可用：
自动切换
有一台就是这主的Redis，还有几台从的Redis，因为我们主要我们的主的这个 Redis 会不断的就是去发数据,要让这从的节点去同步我们这个主的Redis里面的数据。

当我们的主节点这一个 Redis 它发生了这一个宕机之后，我们的 Redis 集群它里面有一种特殊的实例叫做哨兵实例，我们通过这个哨兵实例就可以就可以将这个主节点替换下来，就判断它下线以后我们再把从节点部署上去，这样的话就可以实现一个相当于实现节点的自动切换,尽管用户会感觉到有一段时间卡顿了,但是不需要运维人员手动实现切换了，那么那么我认为这就是一种高可用，像 MySQL 里面其实它也有这样的高可用的这种场景存在。

redis高可用，mysql高可用，节点间怎么同步的，哨兵模式是什么，mysql支持哨兵模式吗

1. Redis 高可用:
   Redis 支持主从复制和哨兵模式来实现高可用。在主从复制中,数据会从主节点同步到从节点。哨兵模式是在主从复制的基础上,增加了自动故障转移的功能。哨兵会监控主从节点的状态,当主节点发生故障时,哨兵会自动选举出新的主节点,实现故障的自动恢复。
2. MySQL 高可用:
   MySQL 常见的高可用方案包括主从复制和使用第三方工具如MGR(MySQL Group Replication)、ProxySQL 等。在主从复制中,数据会从主库同步到从库。MGR 则是一种分布式高可用方案,可以在多个节点之间进行数据同步和自动故障转移。
3. 节点间同步:
   无论是 Redis 还是 MySQL,节点间的数据同步都是通过主从复制的方式实现的。主节点负责接受写入请求,将数据变更同步到从节点。从节点会定期从主节点拉取数据变更,保持与主节点的数据一致性。
4. 哨兵模式:
   Redis 哨兵模式是在主从复制的基础上,增加了节点监控和自动故障转移的功能。哨兵会监控主从节点的状态,当主节点发生故障时,哨兵会自动选举出新的主节点,并通知其他从节点切换主节点。
5. MySQL 是否支持哨兵模式:
   MySQL 本身不支持哨兵模式,但可以通过第三方工具如 Keepalived 实现类似的功能。Keepalived 可以监控 MySQL 主从节点的状态,并在主节点发生故障时自动切换到备用节点。

Redis的主从、哨兵、集群有没有搭建过？怎么搭建部署的

Redis 主从复制:

在主节点和从节点的 Redis 配置文件中,配置 replicaof 或 slaveof 指令,指定主节点的地址和端口。

从节点会自动连接主节点并开始数据复制。可以通过 info replication 命令查看主从复制的状态。

Redis Sentinel 哨兵模式:

首先启动 3 个或更多个 Sentinel 进程,在配置文件中指定监控的主节点信息。

在主节点和从节点的 Redis 配置文件中,配置 sentinel 指令,指定 Sentinel 节点的地址和端口。

Sentinel 会自动监控主节点状态,在主节点故障时自动将从节点晋升为新的主节点。

Redis 集群(切片):

在每个 Redis 节点的配置文件中,配置 cluster-enabled yes 开启集群模式。

使用 redis-cli --cluster create 命令,指定集群中所有节点的地址和端口,创建集群。

Redis 集群会自动将数据切分到不同的节点上,实现水平扩展和高可用。

Redis有哪几种高可用部署方式

主从、哨兵、分布式集群

redis 如何保证高可用

主从、哨兵、集群

可以扩展的一些点：数据不丢失和服务不中断，AOF，AOF重写，RDB，redis默认的RDB生成时机以及与AOF重写命令的冲突问题，写时复制，主从数据同步，复制积压缓冲区，复制缓冲区，哨兵机制，主从切换，脑裂问题

什么时候用Redis主从集群，什么时候用哨兵集群

Redis 主从集群:

适用于读写分离的场景:

主节点负责写入,从节点负责读取。这样可以提高系统的读写性能。

适用于简单的高可用场景:

当主节点发生故障时,可以手动或自动将从节点升级为新的主节点。

适用于小规模的数据量:

主从复制适合中小型 Redis 集群,当数据量较大时,主从复制的性能会下降。

缺点:

主从复制是异步的,从节点可能与主节点存在数据延迟。

手动故障切换较为繁琐,需要人工介入。

Redis 哨兵集群:

适用于自动故障转移的场景:

当主节点发生故障时,Sentinel 可以自动将从节点晋升为新的主节点。

适用于大规模的数据量:

Sentinel 模式可以支持更大规模的 Redis 集群,性能表现更优。

适用于更复杂的高可用场景:

Sentinel 可以监控整个 Redis 集群的状态,提供更强大的高可用保证。

缺点:

需要部署和配置额外的 Sentinel 节点,增加了系统复杂度。

Sentinel 本身也是单点故障,需要部署多个 Sentinel 节点来提高可用性。

redis集群和哨兵机制有什么区别？

Redis 集群和哨兵机制的区别:

结构不同:

Redis 集群是由多个 Redis 节点组成的分布式系统,节点之间通过 Gossip 协议进行通信。

Redis 哨兵是一个独立的进程,用于监控主从节点的状态,并在主节点故障时自动执行failover。

功能不同:

Redis 集群提供了数据分片和自动故障转移的功能,可以实现水平扩展和高可用。

Redis 哨兵只负责监控和故障转移,不参与数据存储和分片。

复杂度不同:

Redis 集群的搭建和管理相对更加复杂,需要配置各个节点的集群参数。

Redis 哨兵相对更加简单,只需要配置好监控的主从节点即可。

你搭过Redis哨兵和集群吗？Redis集群的数据是怎么存储的？key-value是怎么找到自己的位置？

Redis 集群:

数据存储:Redis 集群使用哈希槽(hash slot)的方式来存储和查找数据。每个 key 都会被映射到 0-16383 之间的一个哈希槽上。

查找过程:客户端在访问 key 时,先通过 crc16 算法计算出该 key 所在的哈希槽,然后路由到负责该槽位的节点上。

优点:集群具有很强的扩展性和高可用性,可以动态添加或删除节点。

Redis 哨兵:

监控和故障转移:哨兵会定期检测主节点和从节点的状态,一旦发现主节点故障,会自动将某个从节点晋升为新的主节点。

客户端连接:客户端在连接时,需要指定哨兵集群的地址,哨兵会返回当前的主节点地址。

优点:哨兵部署相对简单,可以保证主从节点的高可用性。

redis主节点挂掉了，哨兵还没有选出下一个结点，这个时候写的数据会怎么样？

主节点挂掉,哨兵还没选出新的主节点时的数据写入:

在这种情况下,客户端的写入操作将会失败。因为没有确定的主节点,客户端无法确定数据应该写入哪个节点。

直到哨兵完成主从切换,选出新的主节点,客户端才能恢复正常的写入操作。

这段时间内写入的数据会丢失,除非使用了持久化方式或者 AOF 日志。

cluster 在服务器扩容时如何 rehash，哈希槽如何计算

当增加或减少 Redis 集群的节点时,需要对哈希槽进行重新分配,这个过程称为 rehash。

rehash 的具体步骤是:

计算新的哈希槽分配方案

迁移数据到新的槽位

更新客户端路由信息

哈希槽的计算公式是: slot = crc16(key) & 16383

crc16 是一种常用的哈希算法

结果被 16383 取模,得到 0-16383 之间的槽位号

Redis 哨兵模式的脑裂

脑裂是指在主从切换过程中,多个哨兵节点同时认定不同的节点为主节点的情况。

造成脑裂的常见原因包括:

网络分区:哨兵节点之间网络不通

资源竞争:多个哨兵节点同时试图提升自己为主节点

解决方案包括:

增加仲裁节点,通过多数派选举主节点

调整哨兵节点的权重和配置

Redis宕机了你是怎么处理的？

如果是单机 Redis 宕机,可以通过重启 Redis 服务来恢复。

如果是 Redis 集群宕机,需要检查每个节点的状态,并按需重启节点。

如果是主从 Redis 宕机,需要通过哨兵机制自动或手动切换主从节点。

如果数据丢失,可以通过 RDB 或 AOF 文件进行数据恢复。

有没有可能redis因为主从哨兵，两个线程拿到同一个锁的情况，怎么办

这确实可能出现,因为主从节点之间存在一定的延迟,当主节点宕机后,新的主节点可能无法感知之前获取的锁。

解决方案包括:

使用带有过期时间的分布式锁,这样即使出现锁竞争也能自动过期释放。

在获取锁的时候,先检查当前节点是否为主节点,如果不是就放弃获取锁。

redis的高可用（哨兵和分片），主从同步的流程

哨兵模式:

配置好主从节点

启动哨兵进程监控主从节点状态

当主节点故障时,哨兵自动选举新的主节点

客户端通过哨兵获取新的主节点地址

集群模式:

搭建集群,配置各节点信息

集群节点之间通过Gossip协议同步状态

客户端根据哈希槽路由访问数据

集群节点动态扩容或缩容时,自动执行rehash

哨兵模式下，写redis是单台机器提供写的能力还是多台机器提供

在哨兵模式下,写操作是由当前的主节点提供。

当主节点发生故障时,哨兵会自动将某个从节点提升为新的主节点,客户端会自动感知并切换到新的主节点。

多个主库如何实现

在 Redis 中,一般不会存在多个主库的情况,因为这样会导致数据一致性问题。

如果确实有这种需求,可以考虑使用 Redis 集群模式,通过哈希槽的方式将数据分散在多个主节点上。

假设Redis有一个主库，2个从库，主库持有分布式锁，如果主库这个时候因为某些原因宕机了，哨兵选举新的从库为主库，但是因为主库实例故障而导致从库也无法同步到这把锁，这个问题应该怎么解决呢？

（ZooKeeper 实现或者使用分布式锁算法Redlock）

解决方案包括:

使用带有过期时间的分布式锁,这样即使出现锁竞争也能自动过期释放。

在获取锁的时候,先检查当前节点是否为主节点,如果不是就放弃获取锁。

使用Redlock等分布式锁算法,提高锁的可靠性。

Redis的集群和哨兵这两个有什么区别和优缺点吗？

集群模式:

采用分布式存储,数据分散在多个节点上

通过哈希槽的方式实现扩容和负载均衡

集群内部通过 Gossip 协议维护节点状态

客户端直接连接集群节点进行读写

哨兵模式:

采用主从复制架构,有一个主节点和多个从节点

通过独立的哨兵进程监控主从节点状态

当主节点故障时,哨兵会自动将某个从节点晋升为新的主节点

客户端通过哨兵获取最新的主节点地址

Redis主从架构和哨兵的区别

集群模式:

优点:

支持水平扩展,可以线性增加存储和计算能力

具有自动故障转移和负载均衡的能力

缺点:

搭建和维护相对复杂

单个节点容量受限

哨兵模式:

优点:

简单易用,易于部署和维护

可靠性高,能够实现自动主从切换

缺点:

存储能力受限于单个主节点

无法实现水平扩展

Redis相关：引入哨兵集之后，主从故障的转移过程？

主从复制模式下,当主节点故障时:

哨兵监测到主节点故障

哨兵在从节点中选举出新的主节点

哨兵通知客户端新的主节点地址

客户端切换到新的主节点进行读写

整个过程由哨兵自动完成,客户端无需感知主从切换细节。

哨兵怎么实现的，redis 主节点挂了，获取锁时会有什么问题？

Redis哨兵的实现原理:

哨兵是一个独立的Redis进程,它通过与Redis节点建立连接来监控主从节点的状态。

哨兵会定期向主节点和从节点发送 INFO 命令,来获取节点的各种信息,如角色、复制偏移量等。

当哨兵发现主节点不可达时,它会与其他哨兵进程商议,达成一致后选举出新的主节点。

选举新主节点的算法类似Raft算法,需要获得大多数哨兵进程的投票。

选举成功后,哨兵会通知客户端新的主节点地址,客户端切换到新主节点进行访问。

主节点挂掉后获取锁的问题:

在Redis主从复制+哨兵模式下,当主节点挂掉后,会出现一些潜在的问题:

如果主节点在持有分布式锁时发生故障,新选举出的主节点可能无法感知之前的锁状态。

这会导致两个问题:

新主节点可能无法获取之前主节点持有的锁,导致业务逻辑错误。

如果旧主节点的锁还在持有状态,新主节点也无法重新获取该锁,从而造成死锁。

解决方案包括:

使用带有过期时间的分布式锁,这样即使出现锁竞争也能自动过期释放。

在获取锁的时候,先检查当前节点是否为主节点,如果不是就放弃获取锁。

使用Redlock等分布式锁算法,提高锁的可靠性。

Redis的哈希槽

哈希槽的概念:

Redis 集群将所有的键值对分散存储在 16384 个哈希槽(hash slot)中

每个键根据其 key 值通过一个哈希函数映射到一个特定的哈希槽

集群中的每个节点负责管理一部分哈希槽

哈希槽的实现:

当客户端访问 Redis 集群时,客户端首先通过 CRC16 算法计算出 key 的哈希值,然后将哈希值对 16384 取模得到槽号。

客户端将请求路由到负责该槽号的节点上执行。

节点之间通过 Gossip 协议交换自己负责的槽号信息,客户端可以缓存这些信息,直接访问正确的节点。

集群扩容:

当需要扩容时,可以通过增加新节点的方式来扩展集群。

添加新节点后,需要在现有节点和新节点之间迁移部分哈希槽,以达到负载均衡。

迁移哈希槽的过程由集群自动完成,客户端无需感知。

新节点加入后,集群会根据新的拓扑结构重新计算哈希槽分布,并将部分槽位迁移到新节点。

 更多精彩内容以及一手消息请关注公众号：绝命Coding