k8s 手动恢复redis 集群_高工面试之：redis的几种集群方式你都熟悉吗？

最新推荐文章于 2024-03-18 14:46:18 发布

weixin_39734048

最新推荐文章于 2024-03-18 14:46:18 发布

阅读量183

点赞数

文章标签： k8s 手动恢复redis 集群

Redis三种集群方式：主从复制、哨兵模式和Cluster模式

一、主从复制模式

Redis配置成主从模式，主库(Master)只负责客户端的写数据，从库(Slave)只负责客户端的读数据。

主从数据复制过程如图所示：

主从复制原理：

slave redis连接master redis，发送sync命令；
master redis接收到sync命名后，执行BGSAVE命令生成RDB文件,使用缓冲区记录此后执行的所有写命令；
master redis BGSAVE执行完后，向所有slave redis发送快照文件，并在发送期间继续记录被执行的写命令；
slave redis收到快照文件后丢弃所有旧数据，载入收到的快照；
master redis快照发送完毕后开始向slave redis发送缓冲区中的写命令；
slave redis器完成对快照的载入，开始接收命令请求，并执行来自master redis缓冲区的写命令；
master redis每执行一个写命令就会向slave redis发送相同的写命令，slave redis接收并执行收到的写命令

主从复制优缺点：

优点：

实现读写分离：客户端从master redis写数据，从slave redis读数据
支持主从复制:master redis自动将数据同步到slave redis
Slave分载Master的同步压力:slave可以接受其它Slaves的连接和同步请求
Master Server是以非阻塞的方式为Slaves提供服务：在Master-Slave同步期间，客户端仍然可以提交查询或修改请求
Slave Server同样是以非阻塞的方式完成数据同步：在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据

缺点：

不具备自动容错和恢复功能：主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复；宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性
较难支持在线扩容：在集群容量达到上限时在线扩容会变得很复杂。

二、哨兵模式

哨兵模式：

在主从复制模式中当主服务器中断服务后，需要人工手动操作来将一个从服务器升级为主服务器，以便继续提供服务。而哨兵模式可以实现自动化的系统监控和故障恢复功能。

哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。

哨兵的作用:

监控主服务器和从服务器是否正常运行。
主服务器出现故障时自动将从服务器转换为主服务器

故障切换(failover)过程:

假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。

哨兵除了监控服务器，哨兵之间也相互监控，如下图所示：

哨兵模式的优缺点

优点：

基于主动复制模式，主从复制模式的所有优点都有
主从可以自动切换，系统更健壮，可用性更高

缺点：

很难支持在线扩容，在线扩容复杂

三、Redis-Cluster集群

现在很多公司采用的是这种redis集群模式。

redis的哨兵模式基本已经可以实现高可用，读写分离，但是在这种模式下每台redis服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了cluster模式，实现的redis的分布式存储，也就是说每台redis节点上存储不同的内容。解决了前面哨兵模式扩容复杂的问题。

Cluster集群模式是在哨兵模式的基础上进行升级改造：

集群节点复制：遵循前面讲到的主从复制模式的节点复制方式
故障转移：和前面讲到的哨兵模式进行故障转移的方法基本一样，不同的是，在集群里面，故障转移是由集群中其他在线的主节点负责进行的，所以集群不必另外使用Redis Sentinel。
集群分片策略：每台redis节点上存储不同的内容

Redis Cluster的具体实现细节：

采用了Hash槽的概念，集群会预先分配16384个槽，并将这些槽分配给具体的服务节点，通过对Key进行CRC16(key)%16384运算得到对应的槽是哪一个，从而将读写操作转发到该槽所对应的服务节点。当有新的节点加入或者移除的时候，再来迁移这些槽以及其对应的数据。在这种设计之下，我们可以很方便的进行动态扩容或缩容，目前很多公司都倾向于这种集群模式。

如下图所示：

面试不可怕，掌握真正的精髓可以让你一击即中。