1. 引言

本文整理自一份超详细的 Redis 7 安装部署教程，覆盖 Linux 环境下 Redis 的四种部署方式：单机部署、主从部署、哨兵部署和集群部署。内容包含完整的安装步骤、核心配置项、架构原理、故障模拟演示以及常见面试问题，适合作为系统学习 Redis 部署的实战笔记。

2. 环境准备

Redis 由 C 语言编写，运行需要 C 编译环境，因此安装前必须先准备 gcc。同时建议关闭或卸载防火墙，避免端口访问受限。

# 关闭防火墙 systemctl stop firewalld.service # 查看防火墙状态 firewall-cmd --state # 卸载防火墙 yum remove firewalld # 检查 gcc 版本 gcc --version # 安装 gcc yum install gcc

3. 单机部署

3.1 下载与安装

养成文件归类的良好习惯，将 Redis 安装到统一目录，使用 wget 下载官方稳定版并编译安装。

# 创建安装目录 mkdir -p /opt/software/redis # 进入目录并下载 cd /opt/software/redis wget https://download.redis.io/redis-stable.tar.gz # 解压 tar -xzf redis-stable.tar.gz # 进入源码目录编译安装 cd redis-stable make install # 检查生成的服务文件 ll /usr/local/bin

安装完成后，/usr/local/bin目录下会生成以下核心工具：

• redis-server：Redis 服务器启动命令
• redis-cli：客户端，操作入口
• redis-benchmark：性能测试工具
• redis-check-aof：修复有问题的 AOF 文件
• redis-check-rdb：修复有问题的 RDB 文件
• redis-sentinel：Redis 哨兵（集群高可用）

3.2 启动 Redis

有两种启动方式：源码路径下启动或使用/usr/local/bin下的命令启动。但直接启动无法后台运行，退出终端后服务即关闭，因此需要修改配置文件。

# 源码路径下启动 ./src/redis-server # 使用 usr/local/bin 路径启动 redis-server

3.3 Redis核心配置

前⾯的启动⽅式⽆法再后台运⾏，退出之后直接关闭了 Redis 服 务。修改redis.conf配置，建议先输入:set number显示行号。以下为单机部署的关键配置项：

修改完成后，使用配置文件启动 Redis，并通过 redis-cli 连接测试。由于配置了密码，连接后需先验证密码。

# 使用配置文件启动 redis-server redis.conf # 连接客户端 redis-cli # 验证密码 auth 1qaz@WSX

# 退出 quit # 关闭 Redis redis-cli shutdown

4. 主从部署（Master-Slave Replication）

4.1 主从复制的作用

• 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速故障恢复，本质是服务的冗余。
• 负载均衡：配合读写分离，主节点提供写服务，从节点提供读服务，在写少读多的场景下可大幅提升并发量。
• 高可用基石：主从复制是哨兵和集群能够实施的基础，是 Redis 高可用的基础。

4.2 部署步骤

主节点无需任何修改，从节点只需在配置文件中添加主节点信息即可。

# 从节点配置中添加主节点信息 replicaof 192.168.75.129 6379 # 主节点查看从节点信息 info Replication

4.3 主从复制的缺点

• 复制延时：所有写操作先在 master 上执行再同步到 slave，存在一定延迟；系统繁忙或 slave 数量增加时延迟更严重。
• 主节点故障需人工干预：默认不会在 slave 中自动重选 master，每次都要人工介入。
• 不提供高可用：主从复制主要用于数据冗余备份和读分担，单纯的主从架构无法保证系统高可用。

5. Sentinel Deployment (Sentinel)

5.1 哨兵模式原理

Redis 哨兵模式通过在独立哨兵节点上运行特定哨兵进程，监控主从节点状态，在发现故障时自动完成故障发现和转移，并通知应用方，实现高可用。

启动时每个哨兵节点会执行选举过程，其中一个被选为领导者（leader），负责协调其他哨兵节点。选举规则如下：

• 每个在线的哨兵节点都可以成为领导者，向其他哨兵发送is-master-down-by-addr命令征求判断并要求将自己设置为领导者。
• 其他哨兵收到命令后可同意或拒绝其成为领导者。
• 当哨兵获得的票数大于等于num(sentinels)/2+1时成为领导者，否则继续选举。

5.2 故障转移流程

• 监控主从节点：哨兵周期性发送命令检查主从节点健康状态，包括主节点是否在线、从节点是否同步等。如果哨兵节点发现主节点不可⽤，它会触发⼀次故障转移。
• 故障转移：⼀旦主节点被判定为不可⽤，哨兵节点会执⾏故障转移操作。它会从当前的从节点中选出⼀个新的主节点，并将其他从节点切换到新的主节点。这样系统可以继续提供服务⽽⽆需⼈⼯介⼊。
• 故障转移过程：由Sentinel(哨兵)节点定期监控发现主节点是否出现了故障：sentinel会向master(主)发送⼼跳PING来确认master是否存活，如 果master在“⼀定时间范围”内不回应PONG 或者是回复了⼀个错误消息，那么这个sentinel会主观地(单⽅⾯地)认为这个master已经不可⽤了。
• 主观下线：哨兵向 master 发送心跳 PING，若 master 在一定时间内不回应 PONG 或回复错误消息，该哨兵主观认为 master 不可用。
• 客观下线：当主观下线的节点是主节点时，该哨兵通过sentinel is-master-down-by-addr寻求其他哨兵判断，超过 quorum 选举个数同意下线操作即客观下线。
• 客户端重定向：哨兵通知客户端新主节点位置，使其能够与新的主节点建⽴连接并发送请求。确保客户端无缝切换继续操作。

选举新主节点时按以下优先级：

1. 过滤掉不健康的（下线或断线）、没有回复哨兵 ping 响应的从节点。
2. 选择从节点优先级最高的。
3. 选择复制偏移量最大（复制最完整）的从节点。
4. 当主节点出现故障， 由领导者负责处理主节点的故障转移。

5.3 哨兵部署配置

整体架构图

3 台机器都需要修改sentinel.conf，配置完成后先从主节点开始启动哨兵。

protected-mode no # 6行，关闭保护模式 daemonize yes # 15行，后台启动 logfile /opt/software/redis/redis-stable/sentinel.log # 34行，日志路径 dir /opt/software/redis # 73行，数据库存放路径 sentinel monitor mymaster 192.168.75.129 6379 2 # 93行，监控主节点，2表示至少2个哨兵同意才能判定故障 sentinel down-after-milliseconds mymaster 30000 # 134行，判定 down 的时间周期（30秒） sentinel failover-timeout mymaster 180000 # 234行，故障节点最大超时时间（180秒）

都是启动后检查哨兵状态： redis-cli -p 26379 info sentinel

5.4 故障模拟演示

# 杀掉主节点进程或直接停掉主节点服务 ps aux | grep redis redis-cli shutdown # 观察哨兵日志，129 主节点下线，重新选举 131 为主节点 tail -f sentinel.log # 重新启动 129 服务并观察日志，129 加入主从，此时主节点为 131 redis-server redis.conf tail -f sentinel.log redis-cli -p 26379 info sentinel # 停止哨兵 redis-cli -p 26379 shutdown

# 切换到 131 服务，已为主节点 redis-cli info replication # 查看文件内容（触发选举后配置文件会被后台修改） cat redis.conf cat sentinel.conf

5.5 哨兵使用建议

• 哨兵节点数量应为多个，哨兵本身应集群化，保证高可用。
• 哨兵节点数应为奇数。
• 各个哨兵节点的配置应一致。
• 若哨兵部署在 Docker 等容器中，尤其注意端口号的正确映射。

5.6 哨兵模式不能保证数据零丢失

• 复制延迟：从节点数据异步复制自主节点，主节点故障时从节点可能未完全同步最新数据，导致数据丢失。
• 故障检测和转移时间：检测到故障并执行转移需要时间，期间主节点可能已接收部分写操作但尚未复制到从节点。
• 网络分区：部分节点与主节点失去联系时，若主节点继续处理写操作，网络恢复前这些操作可能未被复制。
• 多个从节点同时故障：若所有从节点同时故障或与主节点失联，主节点故障时将没有可用从节点可提升。

6. 集群部署（Cluster）

6.1 集群的作用

• 数据分区（分片）：集群最核心的功能。将数据分散到多个节点，突破单机内存大小限制，存储容量大大增加；每个主节点都可对外提供读写服务，大幅提高响应能力。
• 高可用：集群支持主从复制和主节点自动故障转移（与哨兵类似），任一节点故障时集群仍可对外提供服务。

6.2 哈希槽与数据分片

Redis 集群引入哈希槽概念，共有16384 个哈希槽（编号 0-16383）。每个 Key 通过 CRC16 校验后对 16384 取余，决定放置到哪个哈希槽，再通过该值找到对应节点，自动跳转存取。

以 3 节点集群为例：

• 节点 A：包含 0 到 5460 号哈希槽
• 节点 B：包含 5461 到 10922 号哈希槽
• 节点 C：包含 10923 到 16383 号哈希槽

集群采用主从复制模型：若节点 B 失败，整个集群会因缺少 5461-10922 范围的槽而不可用。为每个节点添加从节点 A1、B1、C1 后，集群由三个 Master 和三个 Slave 组成，节点 B 失败时集群选举 B1 为主节点继续服务；当 B 和 B1 都失败时集群才不可用。

6.3 集群部署

集群采用三主三从模式，每台服务器上运行两个 Redis 节点（一个 master、一个 slave）。创建集群配置文件目录并编辑配置：

# 创建集群配置文件夹（另外两台机器重复此过程） mkdir -p /opt/software/redis/redis-stable/cluster mkdir -p /opt/software/redis/cluster vim ./cluster/redis_6379.conf vim ./cluster/redis_6380.conf -- 配置⽂件准备完成之后，启动所有redis服务，⽤cluster配 置⽂件 redis-server ./cluster/redis_6379.conf redis-server ./cluster/redis_6380.conf -- 检查服务 ps aux | grep redis -- 创建三主三从集群模式，每⼀个主节点带⼀个从节点 redis-cli --cluster create --cluster-replicas 1 1 92.168.75.129:6379 192.168.75.129:6380 192.168.7 5.131:6379 192.168.75.131:6380 192.168.75.132:637 9 192.168.75.132:6380 -- 查看集群信息 redis-cli cluster info -- 查看单个节点信息 redis-cli info replication -- 查看集群节点身份信息 redis-cli cluster nodes 20 -- 停⽌redis服务 redis-cli -p 6379 shutdown redis-cli -p 6380 shutdown

6379 配置示例：

bind * -::* # 允许所有 IP daemonize yes # 后台运行 protected-mode no # 允许远程连接 cluster-enabled yes # 开启集群模式 cluster-node-timeout 5000 # 集群节点超时时间 dir "/opt/software/redis/cluster" # 数据存储目录 appendonly yes # 开启 AOF 持久化 port 6379 # 端口 logfile "/opt/software/redis/redis-stable/cluster/redis6379.log" cluster-config-file nodes-6379.conf appendfilename "appendonly6379.aof" dbfilename "dump6379.rdb"

6380 配置与 6379 类似，仅端口、日志、集群配置文件名、AOF 文件名、RDB 文件名不同。

6.4 创建集群

# 启动所有 redis 服务（用 cluster 配置文件） redis-server ./cluster/redis_6379.conf redis-server ./cluster/redis_6380.conf # 检查服务 ps aux | grep redis # 创建三主三从集群，每个主节点带一个从节点 redis-cli --cluster create --cluster-replicas 1 192.168.75.129:6379 192.168.75.129:6380 192.168.75.131:6379 192.168.75.131:6380 192.168.75.132:6379 192.168.75.132:6380 # 查看集群信息 redis-cli cluster info # 查看单个节点信息 redis-cli info replication # 查看集群节点身份信息 redis-cli cluster nodes

6.5 集群数据读写演示

-- 连接⼀个主节点进⾏写数据 redis-cli info replication -- 直接连接读写可能会出现以下问题，是因为不同的节点的槽位不 同，图中就是提示我们去132:6379进⾏写⼊数据

直接连接读写时，由于不同节点槽位不同，可能会提示跳转到对应节点写入。开启路由规则-c即可自动处理。

# 开启集群路由模式 redis-cli -c # 写入数据 set k1 b1

6.6 模拟故障转移

# 将 129 机器的主节点干掉（129 的 6379 服务） redis-cli -p 6379 shutdown # 查看 129 机器从节点工作日志（131 的 6380 日志） cat redis6380.log # 切换到 132 机器查看集群节点信息，131:6380 已升为主节点 redis-cli cluster nodes

# 重新启动 129.6379 服务 redis-server ./cluster/redis_6379.conf # 查看 129.6379 节点信息，主节点已变为从节点 redis-cli -p 6379 info replication # 观察 131.6380 日志，129.6379 重新加入集群

7. 文件目录与配置汇总

7.1 文件目录结构

• /opt/software/redis/：Redis 应用目录
• /opt/software/redis/redis-stable：Redis 应用根目录
• /opt/software/redis/cluster：Redis 集群应用文件目录（日志、快照等）
• /opt/software/redis/redis-stable/cluster：Redis 集群配置文件存放路径

7.2 常用命令汇总

Redis 基础常见命令：

keys * # 查看当前库所有 key exists key # 判断 key 是否存在 type key # 查看 key 类型 del key # 删除指定 key unlink key # 非阻塞

8. 面试常见问题与业务场景设计

8.1 基础与部署类

Q1：Redis 为什么需要先安装 gcc？

Redis 由 C 语言编写，编译安装过程依赖 C 编译器，因此必须先准备 gcc 环境，否则无法完成源码编译。

Q2：直接启动 Redis 为什么无法后台运行？如何解决？

直接使用redis-server启动时进程在前台运行，退出终端后服务即关闭。解决方法是修改redis.conf，将daemonize设置为yes，开启守护进程模式实现后台运行。

Q3：如何实现 Redis 远程连接？

需要修改bind配置为* -::*支持所有 IP，同时将protected-mode设置为no；若设置了requirepass密码，客户端连接后需先执行auth验证密码。

8.2 主从复制类

Q4：主从复制解决了哪些问题？

主要解决四方面问题：一是数据冗余，实现热备份；二是故障恢复，主节点故障时从节点可接管服务；三是负载均衡，配合读写分离提升并发量；四是作为哨兵和集群高可用架构的基础。

Q5：主从复制存在哪些缺点？

一是复制延时，写操作先在主节点执行再异步同步到从节点，系统繁忙时延迟更明显；二是主节点故障需人工干预，不会自动重选主节点；三是单纯主从架构不提供高可用保障。

Q6：如何配置主从复制？

主节点无需修改配置，只需在从节点的redis.conf中添加replicaof 主节点IP 端口，然后通过info Replication在主节点查看从节点连接状态。

8.3 哨兵模式类

Q7：哨兵模式如何实现高可用？

哨兵节点独立运行，周期性监控主从节点健康状态。当主节点被判定不可用时，哨兵自动执行故障转移，从从节点中选举新主节点，并通知客户端切换连接，整个过程无需人工介入。

Q8：什么是主观下线和客观下线？

主观下线是单个哨兵向主节点发送心跳 PING，若主节点在超时时间内未回应 PONG 或回复错误消息，该哨兵单方面认为主节点不可用。客观下线是当主观下线的节点为主节点时，该哨兵通过sentinel is-master-down-by-addr征求其他哨兵判断，超过 quorum 数量同意后才判定为客观下线。

Q9：哨兵选举新主节点的优先级是什么？

首先过滤掉不健康、下线或断线、未回复哨兵 ping 的从节点；其次选择从节点优先级最高的；最后选择复制偏移量最大、数据复制最完整的从节点。

Q10：哨兵模式为什么不能保证数据零丢失？

原因包括：复制延迟导致从节点可能未完全同步最新数据；故障检测和转移期间主节点可能已接收写操作但尚未复制；网络分区时主节点继续处理写操作但未复制；多个从节点同时故障时无可用从节点可提升。

8.4 集群模式类

Q11：Redis 集群如何实现数据分片？

集群引入 16384 个哈希槽（编号 0-16383），每个 Key 通过 CRC16 校验后对 16384 取余，决定放置到哪个哈希槽，再通过该值找到对应节点，实现数据自动分片存储。

Q12：为什么集群中每个主节点需要配置从节点？

集群采用主从复制模型，若某个主节点失败且没有从节点，整个集群会因缺少对应哈希槽范围而不可用。配置从节点后，主节点故障时从节点可自动提升为新主节点，保证集群持续对外服务。

Q13：集群模式下直接连接读写为什么可能报错？如何解决？

因为不同节点负责的哈希槽范围不同，直接连接某个节点写入时，若 Key 的哈希槽不属于该节点，会提示跳转到对应节点。开启redis-cli -c路由模式即可自动处理跳转。

8.5 业务场景设计题

场景一：电商秒杀活动，如何保证 Redis 高可用？

秒杀场景写多读少、并发极高，可采用哨兵模式保障高可用，主节点负责写入，从节点分担读取和备份。若数据量超过单机内存限制，可升级为集群模式，将热点数据分片到多个主节点，并为每个主节点配置从节点实现自动故障转移。

场景二：社交平台 Feed 流，读写比例约 1:10，如何设计？

该场景读多写少，适合主从复制配合读写分离：主节点处理写操作，多个从节点分担读请求，大幅提升并发读能力。同时配置哨兵监控，主节点故障时自动切换，避免人工干预。

场景三：数据量超过单机内存，且要求任一节点故障不影响服务，如何设计？

应采用集群模式，通过哈希槽将数据分片到多个主节点，突破单机内存限制。每个主节点配置一个从节点，主节点故障时从节点自动提升，保证集群持续可用。同时开启 AOF 持久化，降低数据丢失风险。

场景四：金融交易系统对数据一致性要求极高，如何选型？

需明确哨兵和集群模式均无法保证数据零丢失，因为复制是异步的。金融场景应结合同步复制或业务层补偿机制，必要时引入消息队列做最终一致性保障，并定期备份 RDB 和 AOF 文件。

8.6 总结

本文档覆盖 Redis 从单机到主从、哨兵、集群的完整部署链路。面试中应重点掌握四种部署方式的适用场景、核心配置项、故障转移原理及数据一致性边界。业务设计题需结合读写比例、数据量、可用性要求综合选型，并清晰说明各方案的优缺点。