redis详解-进阶

Redis（Remote Dictionary Server）是一款开源的高性能键值对数据库，核心优势是基于内存、读写速度快、支持多数据结构、可持久化，广泛应用于缓存、会话存储、消息队列、计数器等企业级场景。

一、Redis核心架构

Redis之所以能实现高性能，核心在于其「单线程+IO多路复用」的架构设计，同时结合内存存储、高效数据结构，兼顾速度与可靠性。掌握底层架构，可快速定位性能瓶颈、内存泄漏、连接异常等问题。

1. 核心架构模型（单线程模型）

Redis默认采用单线程模型（核心业务线程唯一），区别于多线程服务，其核心优势是避免线程切换开销、无锁竞争，结合内存操作的特性，实现极高的读写性能（单机QPS可达10万+）。

• 核心线程：单个主线程负责处理所有客户端的读写请求、数据持久化（RDB/AOF）触发、主从复制数据同步等核心操作，无需考虑线程安全问题，简化架构设计。

• 辅助线程：Redis 4.0+新增辅助线程（如IO线程、持久化线程），将耗时操作（如AOF日志写入、RDB文件生成、大key删除）剥离到辅助线程，避免阻塞主线程，进一步提升并发能力。

• IO多路复用：通过epoll（Linux）、kqueue（BSD）等IO多路复用机制，单个主线程可同时监听多个客户端连接，当连接有可读/可写事件时，再进行处理，实现"单线程处理多连接"，大幅降低系统资源开销。

补充：Redis单线程并非"全程单线程"，仅核心的请求处理、数据操作是单线程，耗时的IO操作（如网络IO、磁盘IO）会由辅助线程或操作系统异步处理，确保主线程不阻塞。

2. 核心数据结构与底层实现

Redis支持String、Hash、List、Set、Sorted Set等多种数据结构，不同数据结构的底层实现直接影响性能与内存占用，运维中需根据业务场景选择合适的结构，避免内存浪费或性能瓶颈。

|------------------|--------------------------------|------------------------------------|
| 数据结构 | 底层实现（核心） | 运维注意点 |
| String（字符串） | 简单动态字符串（SDS），支持扩容、预分配空间 | 避免存储过大字符串（建议单key不超过100MB），否则会阻塞主线程 |
| Hash（哈希） | 哈希表（dict），小哈希会用ziplist（压缩列表）优化 | 适合存储对象（如用户信息），避免大量小key，节省内存 |
| List（列表） | 双向链表，小列表用ziplist优化 | 避免列表过长（建议不超过10万元素），否则查询、删除效率低 |
| Set（集合） | 哈希表，无重复元素 | 适合去重、交集/并集操作，元素过多会占用大量内存 |
| Sorted Set（有序集合） | 跳表（skiplist）+ 哈希表 | 适合排行榜场景，插入、查询效率高，但内存占用比Set略高 |

二、Redis进阶核心配置（生产环境必用）

Redis配置文件（redis.conf）是运维核心，以下配置均为生产环境高频场景，直接修改参数即可落地，重点关注安全配置、持久化配置、连接限制，避免踩坑。

1. 基础安全配置（防止未授权访问，重中之重）

Redis默认无密码、绑定本地IP，若直接暴露在公网，极易被攻击（如挖矿、数据泄露），生产环境必须配置以下安全参数：

# 1. 绑定允许访问的IP（仅允许内网IP访问，禁止公网直接访问）
bind 192.168.1.10 127.0.0.1
# 2. 设置密码（复杂度建议8位以上，包含字母、数字、特殊符号）
requirepass YourStrongPassword123!
# 3. 禁止使用root用户启动Redis（避免权限过高，降低风险）
# 启动时指定普通用户：sudo -u redis redis-server /etc/redis/redis.conf
# 4. 禁用危险命令（避免误操作或攻击）
rename-command FLUSHDB ""  # 禁用清空数据库命令
rename-command FLUSHALL "" # 禁用清空所有数据库命令
rename-command CONFIG ""   # 禁用修改配置命令
# 5. 限制连接来源（结合防火墙，仅放行内网IP）
# 防火墙配置（CentOS）：firewall-cmd --add-rich-rule="rule family="ipv4" source address="192.168.1.0/24" port protocol="tcp" port="6379" accept" --permanent

2. 持久化配置（避免数据丢失，核心运维点）

Redis是内存数据库，默认情况下重启后数据会丢失，生产环境必须启用持久化（RDB或AOF），根据业务需求选择合适的持久化方式，建议「RDB+AOF混合持久化」，兼顾性能与可靠性。

（1）RDB持久化（快照持久化，适合备份）

核心原理：在指定时间间隔内，将内存中的数据快照写入磁盘（.rdb文件），恢复时直接加载快照文件，速度快，但可能丢失最后一次快照后的部分数据。

# RDB持久化核心配置（redis.conf）
# 1. 触发快照的条件（三个条件满足一个即触发）
save 900 1    # 900秒内有1个key被修改，触发快照
save 300 10   # 300秒内有10个key被修改，触发快照
save 60 10000 # 60秒内有10000个key被修改，触发快照
# 2. 快照文件存储路径与名称
dir /var/lib/redis  # 快照文件存储目录（需确保Redis用户有读写权限）
dbfilename dump.rdb # 快照文件名
# 3. 快照生成失败时，是否禁止Redis写入操作（推荐开启，避免数据不一致）
stop-writes-on-bgsave-error yes
# 4. 快照文件压缩（推荐开启，节省磁盘空间）
rdbcompression yes
# 5. 快照文件校验（推荐开启，确保文件未损坏）
rdbchecksum yes

2）AOF持久化（日志持久化，适合数据安全）

核心原理：将每一条写操作（如set、del）记录到AOF日志文件中，恢复时重新执行日志中的所有命令，数据丢失风险极低（可配置每秒写入），但性能略低于RDB。

# AOF持久化核心配置（redis.conf）
# 1. 启用AOF持久化（默认关闭，需手动开启）
appendonly yes
# 2. AOF日志文件名称
appendfilename "appendonly.aof"
# 3. AOF写入策略（生产环境推荐everysec，兼顾性能与数据安全）
# appendfsync always  # 每执行一条命令就写入磁盘，数据最安全，性能最差
appendfsync everysec  # 每秒写入一次磁盘，最多丢失1秒数据
# appendfsync no      # 由操作系统决定写入时机，性能最好，数据最不安全
# 4. AOF日志重写（避免日志文件过大，自动压缩冗余命令）
auto-aof-rewrite-percentage 100 # 当AOF文件大小达到当前基准的100%（即翻倍）时触发重写
auto-aof-rewrite-min-size 64mb  # 当AOF文件大小超过64MB时，才允许触发重写
# 5. AOF日志损坏时，是否允许Redis启动（推荐yes，避免启动失败）
aof-load-truncated yes

（3）RDB+AOF混合持久化（推荐生产环境使用）

Redis 4.0+支持混合持久化，AOF日志文件中包含RDB快照+增量AOF命令，兼顾RDB的快速恢复和AOF的数据安全性，配置如下：

# 启用混合持久化（redis.conf）
aof-use-rdb-preamble yes

优势：恢复时先加载RDB快照（速度快），再执行增量AOF命令（补充快照后的操作），既保证恢复速度，又减少数据丢失。

3. 连接与内存限制配置（避免资源耗尽）

生产环境中，需限制Redis的连接数、内存使用，避免因连接过多、内存溢出导致服务崩溃。

# 1. 最大客户端连接数（根据服务器性能调整，默认10000）
maxclients 10000
# 2. 内存限制（避免Redis占用过多内存，导致系统OOM）
maxmemory 16gb  # 限制Redis最大使用内存（根据服务器内存配置，如服务器32GB内存，设为16GB）
# 3. 内存淘汰策略（当内存达到maxmemory时，删除部分key释放内存，生产环境推荐以下两种）
# maxmemory-policy allkeys-lru  # 淘汰所有key中最近最少使用的key（适合缓存场景）
maxmemory-policy volatile-lru # 仅淘汰设置了过期时间的key中最近最少使用的key（适合既有缓存又有持久化数据的场景）
# 4. 连接超时时间（客户端空闲超过指定时间自动断开连接，避免空闲连接占用资源）
timeout 300  # 单位：秒，0表示不超时

三、Redis主从复制（高可用基础，避免单点故障）

单台Redis服务器存在单点故障（如宕机、磁盘损坏），生产环境必须部署主从复制架构------1台主节点（Master）负责读写，多台从节点（Slave）负责读，实现数据同步、读写分离，提升可用性与读并发能力。

1. 主从复制核心原理

1. 初始化同步：从节点启动后，向主节点发送SYNC命令，主节点生成RDB快照，发送给从节点，从节点加载快照完成初始化；同时主节点将初始化期间的写操作记录到缓冲区，同步给从节点，确保数据一致。

2. 增量同步：初始化完成后，主节点每执行一条写操作，都会将命令同步给从节点，从节点实时执行命令，保持与主节点数据一致。

3. 读写分离：主节点负责写操作（set、del、incr等），从节点负责读操作（get、hget等），分担主节点读压力，提升并发能力。

2. 主从复制实战配置（2主1从示例）

假设服务器IP：主节点（Master）192.168.1.10，从节点（Slave）192.168.1.11，无需修改主节点配置，仅需配置从节点。

# 从节点（192.168.1.11）redis.conf配置
# 1. 绑定自身IP
bind 192.168.1.11 127.0.0.1
# 2. 配置主节点地址与端口
slaveof 192.168.1.10 6379
# 3. 若主节点设置了密码，需配置主节点密码
masterauth YourStrongPassword123!
# 4. 从节点只读（禁止写操作，确保主从数据一致）
slave-read-only yes
# 5. 主节点宕机后，从节点是否自动成为主节点（暂时关闭，后续哨兵模式会处理）
slave-priority 100  # 数值越小，优先级越高，0表示不参与主节点竞选
# 6. 增量同步缓冲区大小（默认1mb，主从网络较差时可增大）
repl-backlog-size 10mb

配置完成后，启动主节点、从节点，执行以下命令验证主从同步状态：

# 主节点执行：查看从节点列表
127.0.0.1:6379> info replication
# 关键信息：role:master，connected_slaves:1（表示有1个从节点连接）
# 从节点执行：查看主从状态
127.0.0.1:6379> info replication
# 关键信息：role:slave，master_host:192.168.1.10（表示主节点地址正确），master_link_status:up（表示同步正常）

3. 主从复制运维注意点

• 主节点宕机后，从节点仅能提供读服务，无法执行写操作，需手动切换主节点（后续哨兵模式可实现自动切换）。

• 主从节点网络延迟不宜过高（建议≤10ms），否则会导致数据同步延迟，影响业务一致性。

• 从节点数量不宜过多（建议≤5个），否则主节点同步压力过大，可采用"主-从-从"架构（主节点→从节点→从节点）。

四、Redis哨兵模式（自动故障转移，高可用进阶）

主从复制架构无法自动处理主节点故障，需手动切换主节点，效率低且易出错。哨兵模式（Sentinel）是Redis官方提供的高可用解决方案，通过多个哨兵节点监控主从节点，当主节点宕机时，自动将最优从节点切换为新主节点，无需人工干预。

1. 哨兵模式核心架构

• 哨兵节点（Sentinel）：独立于主从节点的进程，负责监控主从节点状态、判断主节点是否宕机、自动执行故障转移。

• 核心功能：监控（实时检测主从节点健康状态）、通知（主节点宕机时，通知管理员或其他系统）、自动故障转移（主节点宕机后，选举新主节点，更新从节点配置）。

• 部署建议：哨兵节点数量为奇数（3个最佳），避免脑裂（多个哨兵节点对主节点状态判断不一致）。

2. 哨兵模式实战配置（3个哨兵+1主2从）

假设哨兵节点IP：192.168.1.12、192.168.1.13、192.168.1.14，主节点192.168.1.10，从节点192.168.1.11、192.168.1.15，哨兵配置文件（sentinel.conf）如下（3个哨兵配置一致，仅绑定IP不同）：

# 哨兵配置文件（sentinel.conf）
# 1. 哨兵节点端口（默认26379，每个哨兵节点端口需唯一）
port 26379
# 2. 绑定自身IP（允许其他哨兵节点、主从节点访问）
bind 192.168.1.12 127.0.0.1
# 3. 监控主节点（格式：sentinel monitor <主节点名称> <主节点IP> <主节点端口> <quorum>）
# quorum：判断主节点宕机的最小哨兵节点数（3个哨兵设为2，即至少2个哨兵认为主节点宕机，才会触发故障转移）
sentinel monitor mymaster 192.168.1.10 6379 2
# 4. 主节点密码（若主节点设置了密码，必须配置）
sentinel auth-pass mymaster YourStrongPassword123!
# 5. 主节点宕机后，哨兵等待多久判断为宕机（默认3000毫秒，可调整）
sentinel down-after-milliseconds mymaster 3000
# 6. 故障转移超时时间（默认180000毫秒，即3分钟）
sentinel failover-timeout mymaster 180000
# 7. 故障转移时，最多有多少个从节点同时同步新主节点（默认1，避免同步压力过大）
sentinel parallel-syncs mymaster 1

3. 哨兵模式启动与验证

# 1. 启动哨兵节点（每个哨兵节点单独启动）
redis-sentinel /etc/redis/sentinel.conf
# 2. 验证哨兵状态（任意哨兵节点执行）
redis-cli -h 192.168.1.12 -p 26379
192.168.1.12:26379> info sentinel
# 关键信息：sentinel_masters:1（监控1个主节点），sentinel_monitored_slaves:2（监控2个从节点）
# 3. 模拟主节点宕机，测试故障转移
# 主节点执行：shutdown（关闭主节点）
# 哨兵节点日志查看：tail -f /var/log/redis/sentinel.log
# 故障转移完成后，从节点执行info replication，会显示role:master（成为新主节点）

4、哨兵模式完整配置文件详解

（一）基础运行配置（必配，保障哨兵自身正常运行）

配置项	默认值	详解与生产配置建议	是否必配
port	26379	哨兵节点的监听端口，每个哨兵节点的端口必须唯一，避免端口冲突。生产配置：保持默认26379，若服务器端口紧张，可修改为26380、26381等（需统一规划）。	必配
bind	127.0.0.1	绑定哨兵节点的IP地址，用于接收其他哨兵节点、主从节点的连接，禁止绑定公网IP（避免攻击）。生产配置：绑定内网IP+本地回环地址，如bind 192.168.1.12 127.0.0.1（192.168.1.12为哨兵节点内网IP）。	必配
daemonize	no	是否以守护进程（后台）模式运行，生产环境必须开启，避免终端关闭后哨兵进程退出。生产配置：daemonize yes	必配
pidfile	/var/run/redis-sentinel.pid	哨兵进程PID文件的存储路径，用于管理哨兵进程（如停止、重启），需确保路径有读写权限。生产配置：保持默认，或修改为/var/run/redis/sentinel.pid（统一管理Redis相关PID文件）。	可选
logfile	""（默认不输出日志）	哨兵日志文件的存储路径，用于排查故障（如故障转移失败、节点连接异常），必须配置。生产配置：logfile /var/log/redis/sentinel.log，定期清理日志（避免占满磁盘）。	必配
dir	/tmp	哨兵工作目录，用于存储临时文件（如哨兵状态文件），建议修改为Redis专用目录。生产配置：dir /var/lib/redis/sentinel（需提前创建目录并授权Redis用户读写）。	可选（推荐配置）

（二）核心监控配置（必配，定义哨兵监控的主从节点）

核心配置项：sentinel monitor <master-name> <master-ip> <master-port> <quorum>，这是哨兵模式的核心配置，用于指定要监控的主节点信息。

配置项/参数	说明	生产配置示例与注意事项
sentinel monitor	监控主节点的命令关键字，固定不变	无，必须作为配置开头
<master-name>	主节点的逻辑名称（自定义），用于标识监控的主从集群，所有哨兵节点必须一致	示例：mymaster（建议命名规范：业务+redis+master，如order-redis-master）
<master-ip>	被监控主节点的内网IP地址，禁止使用公网IP	示例：192.168.1.10（主节点内网IP），确保哨兵节点能ping通该IP
<master-port>	被监控主节点的Redis服务端口（默认6379）	示例：6379，若主节点端口修改，需同步修改此处
<quorum>	判断主节点"客观下线"的最小哨兵节点数，核心参数，避免误判	生产配置建议：- 3个哨兵节点：quorum 2（至少2个哨兵认为主节点下线，才触发故障转移）- 5个哨兵节点：quorum 3⚠️ 注意：quorum值不能超过哨兵节点总数的一半，否则无法触发故障转移

生产完整示例：sentinel monitor mymaster 192.168.1.10 6379 2

（三）安全配置（必配，防止未授权访问和数据泄露）

配置项	默认值	详解与生产配置建议	是否必配
sentinel auth-pass <master-name> <password>	无	若主节点设置了访问密码（requirepass），哨兵必须配置此参数，否则无法连接主从节点，导致监控失败。生产配置：sentinel auth-pass mymaster YourStrongPassword123!（密码与主节点requirepass一致，复杂度8位以上，含字母、数字、特殊符号）	必配（主节点有密码时）
sentinel deny-scripts-reconfig	no	是否禁止通过脚本修改哨兵配置，防止恶意脚本篡改配置，生产环境建议开启。生产配置：sentinel deny-scripts-reconfig yes	可选（推荐配置）
protected-mode	yes	保护模式，禁止公网IP访问哨兵节点，仅允许内网IP和本地连接，生产环境必须开启。生产配置：protected-mode yes（配合bind配置，双重防护）	必配

（四）故障转移配置（核心，控制自动故障转移的规则）

故障转移是哨兵的核心功能，以下配置直接影响故障转移的效率和稳定性，全部为推荐必配参数。

配置项	默认值	详解与生产配置建议	是否必配
sentinel down-after-milliseconds <master-name> <ms>	3000（3秒）	哨兵判断主节点"主观下线"的超时时间（单位：毫秒），即哨兵连续多久未收到主节点的响应，就认为该主节点主观下线。生产配置：sentinel down-after-milliseconds mymaster 3000（默认值即可，若网络波动大，可调整为5000ms）	必配
sentinel failover-timeout <master-name> <ms>	180000（3分钟）	故障转移的超时时间，若超过该时间故障转移未完成，则视为失败，重新发起故障转移。生产配置：sentinel failover-timeout mymaster 180000（默认值即可，无需修改）	必配
sentinel parallel-syncs <master-name> <num>	1	故障转移时，同时同步新主节点数据的从节点数量，数量越多，新主节点压力越大，同步越慢。生产配置：sentinel parallel-syncs mymaster 1（默认值最佳，避免新主节点被同步请求压垮）	必配
sentinel failover-allow-takes-over-down-master	no	是否允许哨兵在主节点"主观下线"但未"客观下线"时，触发故障转移（用于特殊场景，如主节点网络中断但未宕机）。生产配置：sentinel failover-allow-takes-over-down-master no（默认值，避免误触发故障转移）	可选（推荐默认）
sentinel slave-priority <master-name> <priority>	100	从节点的优先级，数值越小，优先级越高，故障转移时越优先被选为新主节点（0表示不参与新主节点竞选）。生产配置：根据从节点性能调整，如高性能从节点设为50，普通从节点设为100，示例：sentinel slave-priority mymaster 50	可选（推荐配置）

（五）可选配置（根据业务场景补充）

配置项	默认值	详解与适用场景
sentinel notification-script <master-name> <script-path>	无	故障通知脚本路径，当主节点下线、故障转移完成时，哨兵会执行该脚本（如发送邮件、短信告警），适用于需要实时告警的场景。示例：sentinel notification-script mymaster /etc/redis/sentinel-alert.sh
sentinel client-reconfig-script <master-name> <script-path>	无	客户端重配置脚本，故障转移完成后，执行该脚本通知客户端（如应用程序）新主节点的地址，适用于客户端无法自动感知主节点变化的场景。
sentinel resolve-hostnames	no	是否允许哨兵使用主机名（而非IP）监控主从节点，适用于主从节点IP不固定、使用域名解析的场景，开启后需配置sentinel resolve-hostnames yes。
sentinel announce-ip <ip>	无	指定哨兵节点对外暴露的IP地址，适用于哨兵节点在NAT环境下（如容器、云服务器），确保其他哨兵节点能正常连接。
sentinel announce-port <port>	无	指定哨兵节点对外暴露的端口，与sentinel announce-ip配合使用，适用于端口映射场景。

5、生产环境完整配置文件示例（3个哨兵+1主2从）

假设：主节点IP 192.168.1.10:6379，从节点192.168.1.11:6379、192.168.1.15:6379，哨兵节点IP 192.168.1.12、192.168.1.13、192.168.1.14（3个哨兵配置一致，仅bind IP不同）。

# 基础运行配置
port 26379
bind 192.168.1.12 127.0.0.1  # 其他哨兵节点修改为自身IP（192.168.1.13、192.168.1.14）
daemonize yes
pidfile /var/run/redis/sentinel.pid
logfile /var/log/redis/sentinel.log
dir /var/lib/redis/sentinel

# 核心监控配置（所有哨兵一致）
sentinel monitor mymaster 192.168.1.10 6379 2

# 安全配置
sentinel auth-pass mymaster YourStrongPassword123!  # 与主节点密码一致
sentinel deny-scripts-reconfig yes
protected-mode yes

# 故障转移配置
sentinel down-after-milliseconds mymaster 3000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1
sentinel slave-priority mymaster 100

# 可选：故障通知脚本（根据需求启用）
# sentinel notification-script mymaster /etc/redis/sentinel-alert.sh

6、配置误区与注意事项

• 误区1：所有哨兵节点的master-name不一致 → 导致哨兵无法组成集群，无法判断主节点客观下线，故障转移失败。 解决：所有哨兵节点的sentinel monitor中的master-name必须完全一致。

• 误区2：quorum值设置过大（如3个哨兵设为3） → 若1个哨兵节点宕机，剩余2个哨兵无法达到quorum值，无法触发故障转移。 解决：quorum值设为哨兵节点总数的一半+1（向下取整），3个哨兵设为2，5个哨兵设为3。

• 误区3：主节点有密码，但哨兵未配置sentinel auth-pass → 哨兵无法连接主从节点，监控失效，日志中会出现"NOAUTH Authentication required"错误。 解决：同步配置sentinel auth-pass，密码与主节点requirepass一致。

• 注意事项1：哨兵节点与主从节点必须在同一内网，网络延迟≤10ms，否则会导致主节点状态误判、同步延迟。

• 注意事项2：配置文件修改后，需重启哨兵节点生效（systemctl restart redis-sentinel），或通过命令动态重载（redis-cli -h 192.168.1.12 -p 26379 sentinel reload）。

• 注意事项3：定期检查哨兵日志（tail -f /var/log/redis/sentinel.log），及时发现监控异常、故障转移失败等问题。

• 注意事项4：哨兵节点不要与主从节点部署在同一台服务器，避免服务器宕机导致整个高可用架构失效。

五、Redis集群部署（高并发+高可用，大规模场景）

当单主从架构无法满足高并发（如QPS超过10万）或数据量过大（如内存超过16GB）时，需部署Redis集群（Redis Cluster），将数据分片存储到多个主节点，每个主节点对应多个从节点，实现负载均衡、自动故障转移，支撑大规模业务场景。

1. 集群核心原理

• 数据分片：Redis集群将整个key空间分为16384个哈希槽（slot），每个主节点负责一部分槽位（如3个主节点，每个节点负责约5461个槽位），key通过哈希算法分配到对应槽位，实现负载均衡。

• 主从架构：每个主节点至少对应1个从节点，主节点负责读写，从节点负责备份，主节点宕机后，从节点自动切换为新主节点，确保槽位正常提供服务。

• 集群通信：节点之间通过Gossip协议通信，实时同步节点状态、槽位分配信息，确保集群一致性。

2. 集群实战部署（3主3从，共6个节点）

假设6个节点IP与端口：

主节点：192.168.1.10:6379、192.168.1.11:6379、192.168.1.12:6379

从节点：192.168.1.13:6379（对应主1）、192.168.1.14:6379（对应主2）、192.168.1.15:6379（对应主3）

（1）单个节点配置（所有节点配置一致，仅绑定IP不同）

# redis.conf配置
bind 192.168.1.10 127.0.0.1  # 每个节点绑定自身IP
port 6379
requirepass YourStrongPassword123!
masterauth YourStrongPassword123!
# 启用集群模式
cluster-enabled yes
# 集群配置文件（自动生成，无需手动修改）
cluster-config-file nodes-6379.conf
# 集群节点超时时间（默认15000毫秒）
cluster-node-timeout 15000
# 开启AOF持久化（集群环境推荐）
appendonly yes
aof-use-rdb-preamble yes
# 内存限制
maxmemory 16gb
maxmemory-policy volatile-lru

（2）启动所有节点并创建集群

# 1. 启动所有6个节点（每个节点单独启动）
redis-server /etc/redis/redis.conf
# 2. 创建集群（任意一个节点执行，Redis 5.0+无需手动分配槽位，自动分配）
redis-cli -a YourStrongPassword123! --cluster create \
192.168.1.10:6379 \
192.168.1.11:6379 \
192.168.1.12:6379 \
192.168.1.13:6379 \
192.168.1.14:6379 \
192.168.1.15:6379 \
--cluster-replicas 1  # 每个主节点对应1个从节点
# 执行后，输入yes确认创建集群
# 3. 验证集群状态
redis-cli -h 192.168.1.10 -p 6379 -a YourStrongPassword123!
192.168.1.10:6379> cluster info
# 关键信息：cluster_state:ok（集群正常），cluster_size:3（主节点数量）
# 查看槽位分配情况
192.168.1.10:6379> cluster slots

六、Redis故障排查进阶（生产环境应急处理）

Redis运维中，故障多集中在内存溢出、主从同步异常、哨兵故障转移失败、集群槽位异常等场景，掌握以下排查思路与命令，可快速定位并解决问题。

1. 故障排查核心思路（按优先级排序）

1. 检查Redis运行状态：systemctl status redis，查看是否正常运行，若异常则查看启动日志（journalctl -u redis）。

2. 连接Redis，查看核心状态：redis-cli -h 192.168.1.10 -p 6379 -a YourStrongPassword123!，执行info命令，查看内存、连接、持久化、主从/集群状态。

3. 查看Redis日志：tail -f /var/log/redis/redis-server.log，80%的故障可通过日志定位（如内存溢出、密码错误、同步失败）。

4. 测试网络连通性：ping 192.168.1.10（测试节点可达性）、telnet 192.168.1.10 6379（测试端口是否开放）。

5. 检查系统资源：top（查看Redis内存、CPU占用）、free -h（查看系统内存）、df -h（查看磁盘空间，避免持久化文件占满磁盘）。

2. 高频故障及解决方案

（1）内存溢出（OOM，Redis被系统杀死）

故障原因：Redis内存使用超过maxmemory限制，或系统内存不足，导致系统OOM killer杀死Redis进程。

解决方案：

# 1. 查看Redis内存使用情况
127.0.0.1:6379> info memory
# 重点关注used_memory、maxmemory、used_memory_percentage（内存使用率）
# 2. 若内存使用率超过90%，清理无用key（优先清理过期key、大key）
# 查看过期key数量
127.0.0.1:6379> dbsize
# 手动删除大key（先查找大key）
127.0.0.1:6379> scan 0 match * count 1000  # 遍历key
127.0.0.1:6379> del bigkey1 bigkey2  # 删除大key
# 3. 调整maxmemory配置（根据系统内存调整，如系统32GB内存，设为24GB）
# 修改redis.conf后，重载配置
redis-cli -a YourStrongPassword123! config set maxmemory 24gb
# 4. 优化内存淘汰策略（确保配置为volatile-lru或allkeys-lru）
redis-cli -a YourStrongPassword123! config set maxmemory-policy volatile-lru

（2）主从同步失败（从节点显示master_link_status:down）

故障原因：主从节点网络不通、主节点密码错误、从节点配置错误、主节点缓冲区不足。

解决方案：

# 1. 检查主从节点网络连通性
telnet 192.168.1.10 6379  # 从节点测试主节点端口
# 2. 检查从节点配置（确保slaveof、masterauth配置正确）
127.0.0.1:6379> config get slaveof
127.0.0.1:6379> config get masterauth
# 3. 重新执行主从同步（从节点执行）
127.0.0.1:6379> slaveof no one  # 取消从节点身份
127.0.0.1:6379> slaveof 192.168.1.10 6379  # 重新关联主节点
# 4. 检查主节点缓冲区大小（若同步延迟大，增大缓冲区）
127.0.0.1:6379> config set repl-backlog-size 20mb

（3）哨兵故障转移失败

故障原因：哨兵节点数量不足、主节点宕机后从节点不可用、哨兵配置错误。

解决方案：

# 1. 查看哨兵日志，定位故障原因
tail -f /var/log/redis/sentinel.log
# 2. 检查哨兵节点数量（确保为奇数，且至少2个正常运行）
redis-cli -h 192.168.1.12 -p 26379 info sentinel
# 3. 检查从节点状态（确保至少1个从节点正常运行）
redis-cli -h 192.168.1.11 -p 6379 info replication
# 4. 手动触发故障转移（任意哨兵节点执行）
redis-cli -h 192.168.1.12 -p 26379 sentinel failover mymaster

（4）集群槽位异常（cluster_state:fail）

故障原因：主节点宕机且无可用从节点、槽位未分配完整、节点之间通信失败。

解决方案：

# 1. 查看集群节点状态
redis-cli -h 192.168.1.10 -p 6379 -a YourStrongPassword123! cluster nodes
# 2. 若主节点宕机且无从节点，重启主节点；若主节点无法重启，手动分配槽位到其他主节点
# 3. 若槽位未分配完整，重新分配槽位
redis-cli -a YourStrongPassword123! --cluster fix 192.168.1.10:6379
# 4. 检查节点通信（确保所有节点之间网络通畅，Gossip协议正常）

七、Redis性能优化（生产环境高并发适配）

基于Redis架构特性，通过优化配置、业务层面调整，可进一步提升Redis并发能力、降低内存占用、减少故障概率，以下优化方案均为生产环境验证有效。

1. 内存优化（降低内存占用，提升并发）

• 选择合适的数据结构：避免使用String存储对象，优先使用Hash；避免大量小key，可将多个小key合并为一个Hash key（如user:1000:{name:xxx, age:xxx}）。

• 启用内存压缩：Redis 6.0+支持LZ4压缩，可压缩String、Hash等数据结构，配置lazyfree-lazy-eviction yes（惰性删除，减少阻塞）。

• 合理设置过期时间：对缓存数据设置合理的过期时间（如1小时、24小时），避免过期key堆积，占用内存。

• 定期清理无用数据：通过定时任务（如crontab）执行redis-cli keys "*" | xargs redis-cli del（谨慎使用，避免阻塞主线程，推荐使用scan命令遍历删除）。

2. 性能优化（提升读写速度，支撑高并发）

# 1. 优化Redis配置
# 关闭保护模式（仅内网环境，避免公网访问）
protected-mode no
# 启用TCP快速握手（减少连接建立时间）
tcp-fastopen 3
# 调整TCP缓冲区大小（提升网络传输效率）
tcp-backlog 511
# 2. 优化客户端连接
# 启用连接池（客户端层面，如Java的JedisPool、Python的redis-py连接池），减少连接建立/关闭开销
# 限制客户端连接数（maxclients），避免连接过多导致Redis阻塞
# 3. 读写分离优化
# 所有读请求转发到从节点，写请求发送到主节点，分担主节点压力
# 从节点启用只读模式（slave-read-only yes），避免误写
# 4. 避免慢查询
# 查看慢查询日志（默认慢查询阈值10毫秒）
127.0.0.1:6379> config set slowlog-log-slower-than 10000  # 调整阈值为10毫秒
127.0.0.1:6379> slowlog get 10  # 查看最近10条慢查询
# 优化慢查询命令（如避免使用keys *、hgetall等耗时命令，改用scan、hscan）

3. 持久化优化（兼顾性能与数据安全）

• 采用RDB+AOF混合持久化，既保证恢复速度，又减少数据丢失。

• 调整AOF写入策略为everysec，避免always导致的性能损耗。

• 合理设置AOF重写阈值（auto-aof-rewrite-percentage 100、auto-aof-rewrite-min-size 64mb），避免频繁重写。

• 将持久化文件存储到独立磁盘（如SSD），提升读写速度，避免与系统盘、业务盘冲突。

八、Redis常用进阶命令（运维高频）

|---------------|---------------------------------------------|------------------------|
| 命令用途 | 具体命令 | 说明 |
| 查看Redis核心状态 | info / info memory / info replication | 查看内存、主从、集群等状态，排查故障核心命令 |
| 查看慢查询日志 | slowlog get [n] | 查看最近n条慢查询，优化耗时命令 |
| 遍历所有key（安全方式） | scan 0 match * count 1000 | 替代keys *，避免阻塞主线程 |
| 手动触发RDB快照 | bgsave | 后台生成RDB快照，不阻塞主线程 |
| 手动触发AOF重写 | bgrewriteaof | 后台重写AOF日志，压缩冗余命令 |
| 集群槽位分配 | cluster addslots / cluster delslots | 手动分配/删除集群槽位 |
| 哨兵手动故障转移 | sentinel failover <主节点名称> | 主节点宕机后，手动触发故障转移 |

九、实战总结

Redis进阶运维的核心是「保障高可用、优化性能、避免数据丢失」，本文覆盖的持久化、主从复制、哨兵模式、集群部署、故障排查等内容，均为生产环境高频场景。运维过程中，需重点注意：

• 安全优先：必须配置密码、绑定内网IP、禁用危险命令，避免未授权访问。

• 数据安全：启用RDB+AOF混合持久化，定期备份持久化文件，避免数据丢失。

• 高可用：根据业务规模选择主从复制、哨兵模式或集群，避免单点故障。

• 性能监控：定期查看Redis内存、CPU、连接数、慢查询，提前发现性能瓶颈。

建议结合实际业务场景，调整Redis配置参数，多动手实操验证，熟练掌握故障排查思路，确保Redis服务稳定、高效运行。

十、Redis运维自动化Shell脚本（实战复用）

以下脚本均适配本文运维场景，可直接修改参数后使用，涵盖Redis自动部署、日志清理、故障检测、主从状态检查等高频操作，减少手动运维成本。

1. Redis自动部署脚本（单机版，CentOS 7/8）

功能：自动安装依赖、下载Redis源码、编译安装、配置基础安全参数、启动服务并设置开机自启。

#!/bin/bash
# Redis单机自动部署脚本，适配Redis 7.0.11版本
# 作者：运维实战
# 配置参数（可根据实际需求修改）
REDIS_VERSION="7.0.11"
REDIS_INSTALL_PATH="/usr/local/redis"
REDIS_CONF_PATH="/etc/redis"
REDIS_PASSWORD="YourStrongPassword123!"
REDIS_BIND_IP="192.168.1.10 127.0.0.1"
REDIS_MAXMEMORY="16gb"

# 1. 安装依赖
echo "=== 开始安装Redis依赖 ==="
yum install -y gcc gcc-c++ make openssl-devel pcre-devel gd-devel && echo "依赖安装完成" || { echo "依赖安装失败，退出脚本"; exit 1; }

# 2. 下载Redis源码并解压
echo "=== 开始下载Redis源码 ==="
wget https://download.redis.io/releases/redis-${REDIS_VERSION}.tar.gz -P /tmp && echo "源码下载完成" || { echo "源码下载失败，退出脚本"; exit 1; }
tar -zxvf /tmp/redis-${REDIS_VERSION}.tar.gz -C /tmp && echo "源码解压完成"

# 3. 编译安装
echo "=== 开始编译安装Redis ==="
cd /tmp/redis-${REDIS_VERSION}
make && make PREFIX=${REDIS_INSTALL_PATH} install && echo "编译安装完成" || { echo "编译安装失败，退出脚本"; exit 1; }

# 4. 配置Redis
echo "=== 开始配置Redis ==="
mkdir -p ${REDIS_CONF_PATH}
cp /tmp/redis-${REDIS_VERSION}/redis.conf ${REDIS_CONF_PATH}/redis.conf

# 修改核心配置
sed -i "s/^bind 127.0.0.1/bind ${REDIS_BIND_IP}/g" ${REDIS_CONF_PATH}/redis.conf
sed -i "s/^# requirepass foobared/requirepass ${REDIS_PASSWORD}/g" ${REDIS_CONF_PATH}/redis.conf
sed -i "s/^daemonize no/daemonize yes/g" ${REDIS_CONF_PATH}/redis.conf
sed -i "s/^dir \.\//dir ${REDIS_INSTALL_PATH}\/data/g" ${REDIS_CONF_PATH}/redis.conf
sed -i "s/^maxmemory .*/maxmemory ${REDIS_MAXMEMORY}/g" ${REDIS_CONF_PATH}/redis.conf
sed -i "s/^maxmemory-policy .*/maxmemory-policy volatile-lru/g" ${REDIS_CONF_PATH}/redis.conf
sed -i "s/^appendonly no/appendonly yes/g" ${REDIS_CONF_PATH}/redis.conf
sed -i "s/^aof-use-rdb-preamble no/aof-use-rdb-preamble yes/g" ${REDIS_CONF_PATH}/redis.conf

# 禁用危险命令
echo "rename-command FLUSHDB \"\"" >> ${REDIS_CONF_PATH}/redis.conf
echo "rename-command FLUSHALL \"\"" >> ${REDIS_CONF_PATH}/redis.conf
echo "rename-command CONFIG \"\"" >> ${REDIS_CONF_PATH}/redis.conf

# 创建数据目录并授权
mkdir -p ${REDIS_INSTALL_PATH}/data
chmod 777 ${REDIS_INSTALL_PATH}/data

# 5. 配置系统服务，设置开机自启
echo "=== 配置Redis系统服务 ==="
cat > /usr/lib/systemd/system/redis.service << EOF
[Unit]
Description=Redis Server
After=network.target

[Service]
Type=forking
ExecStart=${REDIS_INSTALL_PATH}/bin/redis-server ${REDIS_CONF_PATH}/redis.conf
ExecStop=${REDIS_INSTALL_PATH}/bin/redis-cli -a ${REDIS_PASSWORD} shutdown
Restart=always

[Install]
WantedBy=multi-user.target
EOF

# 启动服务并设置开机自启
systemctl daemon-reload
systemctl start redis && echo "Redis服务启动成功" || { echo "Redis服务启动失败，退出脚本"; exit 1; }
systemctl enable redis && echo "Redis开机自启配置完成"

# 验证安装
echo "=== 验证Redis安装 ==