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 gcc3. 单机部署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-serverRedis 服务器启动命令redis-cli客户端操作入口redis-benchmark性能测试工具redis-check-aof修复有问题的 AOF 文件redis-check-rdb修复有问题的 RDB 文件redis-sentinelRedis 哨兵集群高可用3.2 启动 Redis有两种启动方式源码路径下启动或使用/usr/local/bin下的命令启动。但直接启动无法后台运行退出终端后服务即关闭因此需要修改配置文件。# 源码路径下启动 ./src/redis-server # 使用 usr/local/bin 路径启动 redis-server3.3 Redis核心配置前⾯的启动⽅式⽆法再后台运⾏退出之后直接关闭了 Redis 服 务。修改redis.conf配置建议先输入:set number显示行号。以下为单机部署的关键配置项配置项行号说明bind * -::*87支持远程连接daemonize yes309开启守护进程后台运行logfile /opt/software/redis/redis-stable/redis.log355指定日志文件目录dir /opt/software/redis510指定工作目录requirepass 1qazWSX1044设置访问密码可自行学习可不设置protected-mode no111允许远程连接若不设置密码必须关闭此选项修改完成后使用配置文件启动 Redis并通过 redis-cli 连接测试。由于配置了密码连接后需先验证密码。# 使用配置文件启动 redis-server redis.conf # 连接客户端 redis-cli # 验证密码 auth 1qazWSX# 退出 quit # 关闭 Redis redis-cli shutdown4. 主从部署Master-Slave Replication4.1 主从复制的作用数据冗余主从复制实现了数据的热备份是持久化之外的一种数据冗余方式。故障恢复当主节点出现问题时可以由从节点提供服务实现快速故障恢复本质是服务的冗余。负载均衡配合读写分离主节点提供写服务从节点提供读服务在写少读多的场景下可大幅提升并发量。高可用基石主从复制是哨兵和集群能够实施的基础是 Redis 高可用的基础。4.2 部署步骤主节点无需任何修改从节点只需在配置文件中添加主节点信息即可。# 从节点配置中添加主节点信息 replicaof 192.168.75.129 6379 # 主节点查看从节点信息 info Replication4.3 主从复制的缺点复制延时所有写操作先在 master 上执行再同步到 slave存在一定延迟系统繁忙或 slave 数量增加时延迟更严重。主节点故障需人工干预默认不会在 slave 中自动重选 master每次都要人工介入。不提供高可用主从复制主要用于数据冗余备份和读分担单纯的主从架构无法保证系统高可用。5. Sentinel Deployment (Sentinel)5.1 哨兵模式原理Redis 哨兵模式通过在独立哨兵节点上运行特定哨兵进程监控主从节点状态在发现故障时自动完成故障发现和转移并通知应用方实现高可用。启动时每个哨兵节点会执行选举过程其中一个被选为领导者leader负责协调其他哨兵节点。选举规则如下每个在线的哨兵节点都可以成为领导者向其他哨兵发送is-master-down-by-addr命令征求判断并要求将自己设置为领导者。其他哨兵收到命令后可同意或拒绝其成为领导者。当哨兵获得的票数大于等于num(sentinels)/21时成为领导者否则继续选举。5.2 故障转移流程监控主从节点哨兵周期性发送命令检查主从节点健康状态包括主节点是否在线、从节点是否同步等。如果哨兵节点发现主节点不可⽤它会触发⼀次故障转移。故障转移⼀旦主节点被判定为不可⽤哨兵节点会执⾏故障转移操作。它会从当前的从节点中选出⼀个新的主节点并将其他从节点切换到新的主节点。这样系统可以继续提供服务⽽⽆需⼈⼯介⼊。故障转移过程由Sentinel(哨兵)节点定期监控发现主节点是否出现了故障sentinel会向master(主)发送⼼跳PING来确认master是否存活如 果master在“⼀定时间范围”内不回应PONG 或者是回复了⼀个错误消息那么这个sentinel会主观地(单⽅⾯地)认为这个master已经不可⽤了。主观下线哨兵向 master 发送心跳 PING若 master 在一定时间内不回应 PONG 或回复错误消息该哨兵主观认为 master 不可用。客观下线当主观下线的节点是主节点时该哨兵通过sentinel is-master-down-by-addr寻求其他哨兵判断超过 quorum 选举个数同意下线操作即客观下线。客户端重定向哨兵通知客户端新主节点位置使其能够与新的主节点建⽴连接并发送请求。确保客户端无缝切换继续操作。选举新主节点时按以下优先级过滤掉不健康的下线或断线、没有回复哨兵 ping 响应的从节点。选择从节点优先级最高的。选择复制偏移量最大复制最完整的从节点。当主节点出现故障 由领导者负责处理主节点的故障转移。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 sentinel5.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.conf5.5 哨兵使用建议哨兵节点数量应为多个哨兵本身应集群化保证高可用。哨兵节点数应为奇数。各个哨兵节点的配置应一致。若哨兵部署在 Docker 等容器中尤其注意端口号的正确映射。5.6 哨兵模式不能保证数据零丢失复制延迟从节点数据异步复制自主节点主节点故障时从节点可能未完全同步最新数据导致数据丢失。故障检测和转移时间检测到故障并执行转移需要时间期间主节点可能已接收部分写操作但尚未复制到从节点。网络分区部分节点与主节点失去联系时若主节点继续处理写操作网络恢复前这些操作可能未被复制。多个从节点同时故障若所有从节点同时故障或与主节点失联主节点故障时将没有可用从节点可提升。6. 集群部署Cluster6.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 shutdown6379 配置示例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.rdb6380 配置与 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 nodes6.5 集群数据读写演示-- 连接⼀个主节点进⾏写数据 redis-cli info replication -- 直接连接读写可能会出现以下问题是因为不同的节点的槽位不 同图中就是提示我们去132:6379进⾏写⼊数据直接连接读写时由于不同节点槽位不同可能会提示跳转到对应节点写入。开启路由规则-c即可自动处理。# 开启集群路由模式 redis-cli -c # 写入数据 set k1 b16.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-stableRedis 应用根目录/opt/software/redis/clusterRedis 集群应用文件目录日志、快照等/opt/software/redis/redis-stable/clusterRedis 集群配置文件存放路径7.2 常用命令汇总Redis 基础常见命令keys * # 查看当前库所有 key exists key # 判断 key 是否存在 type key # 查看 key 类型 del key # 删除指定 key unlink key # 非阻塞8. 面试常见问题与业务场景设计8.1 基础与部署类Q1Redis 为什么需要先安装 gccRedis 由 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 集群模式类Q11Redis 集群如何实现数据分片集群引入 16384 个哈希槽编号 0-16383每个 Key 通过 CRC16 校验后对 16384 取余决定放置到哪个哈希槽再通过该值找到对应节点实现数据自动分片存储。Q12为什么集群中每个主节点需要配置从节点集群采用主从复制模型若某个主节点失败且没有从节点整个集群会因缺少对应哈希槽范围而不可用。配置从节点后主节点故障时从节点可自动提升为新主节点保证集群持续对外服务。Q13集群模式下直接连接读写为什么可能报错如何解决因为不同节点负责的哈希槽范围不同直接连接某个节点写入时若 Key 的哈希槽不属于该节点会提示跳转到对应节点。开启redis-cli -c路由模式即可自动处理跳转。8.5 业务场景设计题场景一电商秒杀活动如何保证 Redis 高可用秒杀场景写多读少、并发极高可采用哨兵模式保障高可用主节点负责写入从节点分担读取和备份。若数据量超过单机内存限制可升级为集群模式将热点数据分片到多个主节点并为每个主节点配置从节点实现自动故障转移。场景二社交平台 Feed 流读写比例约 1:10如何设计该场景读多写少适合主从复制配合读写分离主节点处理写操作多个从节点分担读请求大幅提升并发读能力。同时配置哨兵监控主节点故障时自动切换避免人工干预。场景三数据量超过单机内存且要求任一节点故障不影响服务如何设计应采用集群模式通过哈希槽将数据分片到多个主节点突破单机内存限制。每个主节点配置一个从节点主节点故障时从节点自动提升保证集群持续可用。同时开启 AOF 持久化降低数据丢失风险。场景四金融交易系统对数据一致性要求极高如何选型需明确哨兵和集群模式均无法保证数据零丢失因为复制是异步的。金融场景应结合同步复制或业务层补偿机制必要时引入消息队列做最终一致性保障并定期备份 RDB 和 AOF 文件。8.6 总结本文档覆盖 Redis 从单机到主从、哨兵、集群的完整部署链路。面试中应重点掌握四种部署方式的适用场景、核心配置项、故障转移原理及数据一致性边界。业务设计题需结合读写比例、数据量、可用性要求综合选型并清晰说明各方案的优缺点。