阶段二：非关系型数据库Redis进阶

Redis哨兵概述

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费时费力，还会造成一段时间内服务不可用。

这不是一种推荐的方式，更多时候，我们优先考虑哨兵（Sentinel, 森特尼尔）模式。

什么是哨兵

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

哨兵的作用

这里的哨兵有两个作用

• 通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。

• 当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

FailOver “FailOver” 的中文标准译法是 “故障转移”，是 IT 领域（尤其是高可用架构）的核心术语。 “Fail”（故障）+ “Over”（转移），当主设备或服务 “故障” 时，业务 “转移” 到备用设备服务。是高可用性（High Availability, HA）中的核心技术。

• 故障切换流程

1）主观下线（Subjective Down, SDOWN）​​

哨兵 1 定期检测主节点（如心跳超时、无响应），发现主节点不可用，但 仅代表哨兵 1 的主观判断（可能因网络问题误判），此时进入 主观下线状态。

2）客观下线（Objective Down, ODOWN）​​

其他哨兵（如哨兵 2、哨兵 3）也检测到主节点不可用，且 达到预设的投票阈值（如多数哨兵同意） 时，哨兵集群通过内部投票确认主节点 确实故障（客观下线）。

3）选举 Leader 哨兵

多个哨兵通过投票机制选出一个 Leader 哨兵（负责执行故障切换操作），其他哨兵仅参与决策，不直接操作。

4）执行 Failover（故障切换）​​

Leader 哨兵主导以下操作：

• 从所有从节点中 选择一个最优从节点（如数据最完整、延迟最低的节点）提升为 新主节点。

• 将其他从节点重新配置为 同步新主节点（通过 SLAVEOF命令）。

• 若原主节点恢复，将其降级为 新主节点的从节点。

5）通知客户端（透明化）​​

哨兵集群通过 发布订阅模式（Pub/Sub） 广播主节点变更信息，所有连接的客户端（如应用程序）收到通知后，自动将请求路由到 新主节点，对业务代码无感知（故障切换对客户端透明）。

部署实战

环境准备

配置3个哨兵和1主2从的Redis服务器来演示这个过程。

特别注意：使用Redis哨兵模式，最少需要3个节点（一主多从结构），这样至少能部署3 个哨兵进程，从而保证共同投票选出新的主节点。

Redis 哨兵模式的核心功能是监控主从节点状态，并在主节点故障时自动完成故障切换（Failover）。这一过程依赖多个哨兵节点的协同投票

一主两从配置

安装三台 Redis

1：找到对应的安装包资源，使用wget命令下载，这里安装的7.4.0版本。
安装包资源地址：https://download.redis.io/releases/

2：上传Redis到Linux系统中
dnf install wget -y
wget https://download.redis.io/releases/redis-7.4.0.tar.gz

3：配置=>编译=>安装
shell > tar -zxvf redis-7.4.0.tar.gz
shell > cd redis-7.4.0
shell > make && make PREFIX=/usr/local/redis install

4：添加redis到环境变量
sudo vim /etc/profile
export PATH="$PATH:/usr/local/redis/bin"
source /etc/profile

5：过量使用内存设置为0！在低内存环境下，后台保存可能失败
sudo vim /etc/sysctl.conf
vm.overcommit_memory = 1
sysctl -p

命令作用：

• 使用 dnf 包管理器执行 install 操作，对软件包进行安装、更新、删除或查询。

• 访问 https://download.redis.io/releases/redis-7.4.0.tar.gz；curl 默认把响应写到终端，wget 默认下载到文件。可据 HTTP 状态、响应内容或下载结果判断服务是否可访问。

• 这条命令用于打开并编辑文件。进入编辑器后需要保存退出，修改才会写回文件。

执行结果：

• 成功后软件包会按指定动作完成安装、更新、删除或查询；失败时检查仓库、网络和权限。

• 成功后目标文件会下载到当前目录或 -O 指定的位置。

• 编辑器会打开目标文件；保存并退出后文件内容才会改变。

• 成功后应以该命令实际输出、生成的文件或目标服务状态为准；失败时先阅读终端报错，再核对命令参数和运行环境。

关键参数：

注意事项：

#

| Master | ---> | Replica |

| (receive writes) | | (exact copy) |

# #

#

整体配置如下：

关键参数如下（注意不能直接粘贴）：

**注意事项：**

关键参数：

注意事项：

先停止手动起来的服务，不然后面端口冲突

**注意事项：**

[Unit]
After=network.target

[Service]
Type=forking

PrivateTmp=true

[Install]
WantedBy=multi-user.target

注意事项：

**注意事项：**





(0.68s)

注意事项：

**注意事项：**

查看状态，发现已经发生故障转移，另外一台机器升级为主节点

一旦failover发生时，系统会自动调整2个文件，redis.conf更改主节点信息，sentinel.conf最末端会写入一些选举等信息。

可能有同学会疑惑：当原主节点（Master）故障恢复后，能否重新夺回“老大”身份，继续主导集群？​​

答案很明确：不能！​

原主节点恢复后，会以“从节点（Slave/Replica）”的身份加入集群，自动连接当前的主节点（即故障期间接管的新主节点），并同步其最新数据。 它不会主动挑战新主节点的地位，也不会尝试夺回原有的主节点角色。

相同点：都是基于主从模式

集群：针对主从高可用架构，发现master主节点故障，不需要切换，因为在整个集群中，多主多从，某个节点出现故障，不影响整个集群使用，所以切换速度特别快。

可以查看Redis官网查看集群搭建方式，连接如下

https://redis.io/topics/cluster-tutorial

注：实际运维工作中，大概需要3台机器，每台机器2个实例。详细规划主从关系，尽量不要把一组主从放在同一台服务器中。

主机名称：redis01.itcast.cn/redis02.itcast.cn/redis03.itcast.cn

注意事项：

**注意事项：**

注意事项：

第一步：环境规划（3主3从，对外提供服务的一共是3个节点）

前提：Redis集群往往在搭建环境时必须要提前设计，而且Redis集群要求，在创建集群之前，任何都不能有数据！！！

设置之前，把Redis01、Redis02、Redis03机器上的所有Redis全部停止，在每个节点上创建新的文件夹redis-cluster

**注意事项：**

注意事项：

**注意事项：**

注意事项：

第四步：创建集群（集群最少需要3个主节点）





# 

参数说明：
集群模式不需要提前搭建主从架构，而是在创建集群时，系统会自动配置主从，不需要人工干预

常见问题说明：

常见问题：Redis集群要求Redis中不能有数据，包括appendonlydir、dump.rdb、nodes_700X.conf

解决方案：哪个节点报错，就清除哪个节点（以7001为例）

找到7001对应的进程

清除完成后，重启Redis

选项说明：
-c代表已集群的方式进行连接
查看集群状态

重启步骤非常简单，只需要把每台服务器的各个节点依次启动即可。

需要注意的是：必须要3个或以上的主节点，否则在创建集群时会失败，并且当存活的主节点数小于总节点数的一半时，整个集群就无法提供服务了。

因为写只和master主节点相关，所以16384要被3个master拆分

问题：为什么要分槽？写入一条记录如name:itheima，写入到哪个槽中？

答：分槽目的是为了实现数据最大程度使用，也可以避免数据写入混乱。

写入一条记录如name:itheima，写入到哪个槽中？




第一步：添加新的主节点或者在其中一台服务器复制两份配置文件启动新的两个实例（服务器内存不足的情况）

槽位迁移示意图

可能遇到的问题

第二步：修复未完成的槽迁移（若存在）

注意事项：