一、Redis 性能压测

1. 压测工具：redis-benchmark

Redis 内置 redis-benchmark 工具用于基准性能测试，核心作用是评估 Redis 在指定场景下的读写性能，为数据安全性与性能平衡提供依据。

核心命令示例
# 20个线程，100万次请求，测试set指令（写操作）
redis-benchmark -a 123qweasd -t set -n 1000000 -c 20
结果解读

执行上述命令后，典型输出包含：

  • 吞吐量（throughput）：如 116536.53 requests per second（平均每秒 11 万次写操作）
  • 延迟统计（latency）：avg(平均)、min(最小)、p50(50%请求延迟)、p95(95%请求延迟)、p99(99%请求延迟)、max(最大)
补充说明
  • 可通过 redis-benchmark --help 查看所有参数，支持测试 get、hset、lpush 等多类指令；
  • 压测建议：
    1. 压测环境需与生产环境硬件 / 网络一致；
    2. 避免在业务高峰期压测，防止影响正常服务；
    3. 结合实际业务场景（如读写比例、数据大小）定制压测指令。

二、Redis 数据持久化机制

Redis 持久化核心目标是解决「内存数据断电丢失」问题，提供 RDB、AOF、混合持久化 三种策略，需根据业务在「性能」与「数据安全性」间取舍。

1. RDB（Redis Database）

核心定义

按指定时间间隔，对 Redis 内存中的全量数据生成快照（默认文件：dump.rdb），恢复时直接将快照加载到内存。

触发时机
触发方式 说明 注意事项
配置自动触发 满足 save <seconds> <changes> 规则（如 save 3600 1 300 100 60 10000） 默认开启，可通过 save "" 关闭
手动触发 save（阻塞主线程）/ bgsave（fork 子线程，不阻塞主线程） bgsave 是生产推荐方式，但 fork 会克隆内存数据，大内存场景可能短暂阻塞
主从复制 主节点向从节点同步数据时，会自动触发 bgsave 生成 RDB 属于集群同步的默认行为
核心配置（redis.conf）
# 快照触发规则
save 3600 1 300 100 60 10000
# RDB文件存储目录
dir /var/lib/redis
# RDB文件名
dbfilename dump.rdb
# 是否压缩RDB文件（默认yes，压缩消耗CPU，提升存储效率）
rdbcompression yes
# 是否校验RDB文件（默认yes，增加10%性能消耗，提升数据完整性）
rdbchecksum yes
# bgsave失败时是否停止写操作（默认yes，保障数据一致性）
stop-writes-on-bgsave-error yes
优缺点分析
优点 缺点
1. 文件紧凑，适合定期备份 / 灾难恢复；2. 备份时主线程无 IO 消耗（子线程执行）；3. 大数据量恢复速度远快于 AOF 1. 非实时备份，可能丢失最近一段时间数据；2. fork 子线程时克隆内存，大内存场景易造成短暂服务卡顿

2. AOF（Append Only File）

核心定义

以日志形式追加记录所有写操作（读操作不记录），恢复时通过「重演日志」恢复数据，类似 MySQL 的 binlog。

核心配置（redis.conf）
# 是否开启AOF（默认no）
appendonly yes
# AOF基础文件名（Redis7+拆分为多文件）
appendfilename "appendonly.aof"
# AOF文件存储目录（Redis7+新增，实际路径：dir + appenddirname）
appenddirname "aof"
# 同步策略（核心）
# everysecond：每秒同步（默认，最多丢失1秒数据）
# always：每次写操作同步（数据最安全，性能最差）
# no：交由操作系统同步（性能最好，数据安全性最差）
appendfsync everysecond
# AOF重写触发条件
auto-aof-rewrite-percentage 100  # 文件体积增长100%触发
auto-aof-rewrite-min-size 64mb   # 文件最小64MB才触发
# 重写期间是否禁止同步（默认no，保障重写时数据不丢失）
no-appendfsync-on-rewrite no
Redis7+ AOF 文件结构（补充）

Redis7 重构了 AOF 文件结构，拆分为三类文件，解决单文件过大问题：

  • appendonly.aof.*.base.rdb：二进制全量快照（复用 RDB 格式，提升恢复速度）；
  • appendonly.aof.*.incr.aof：文本增量写操作日志；
  • appendonly.aof.manifest：元数据文件，记录文件序列与类型。
AOF 日志修复

当 AOF 日志因异常（如手动篡改、服务崩溃）导致不完整时，可通过工具修复：

# 修复增量AOF文件
redis-check-aof --fix appendonly.aof.1.incr.aof

修复原理：删除日志中最后不完整的指令，保障日志可正常解析。

优缺点分析
优点 缺点
1. 数据安全性更高（默认每秒同步，最多丢 1 秒数据）；2. 日志可手动编辑（如删除误操作的 FLUSHALL）；3. 自动拆分大文件，避免单文件过大 1. 同数据集下，AOF 文件体积大于 RDB；2. 写操作频繁时，性能略低于 RDB

3. 混合持久化（RDB+AOF）

核心定义

Redis 默认开启（aof-use-rdb-preamble yes），结合 RDB 与 AOF 优势：

  • 写操作：先以 AOF 追加记录，AOF 重写时生成「RDB 全量快照 + AOF 增量日志」；
  • 恢复时：优先加载 AOF 文件（包含最新的 RDB 快照 + 增量日志），兼顾恢复速度与数据完整性。
补充建议
  • 生产环境推荐开启混合持久化；
  • 仍需定期备份 RDB 文件（AOF 日志实时变化，不利于离线备份）；
  • 持久化仅保障单机数据安全，磁盘故障需依赖集群方案。
持久化策略对比图解：

三、Redis 主从复制（Replica）

1. 核心定义

主从复制是 Redis 分布式基础，实现「Master 写数据，Slave 同步数据并提供读服务」，核心价值：

  • 读写分离：分摊读压力；
  • 数据备份：Slave 作为 Master 数据副本；
  • 容灾基础：Master 故障时可手动切换 Slave 为 Master。
核心配置与操作
# 从节点配置（redis.conf）
replicaof 192.168.65.214 6379  # 指定主节点IP+端口
replica-read-only yes          # 从节点只读（默认yes，禁止写操作）

# 运行时修改从节点（临时生效，重启失效）
127.0.0.1:6379> SLAVEOF 192.168.65.214 6379  # 设为从节点
127.0.0.1:6379> SLAVEOF NO ONE               # 解除主从关系
状态查看
# 查看主从复制状态
127.0.0.1:6379> info replication
  • Master 节点：重点看 connected_slaves（连接的从节点数）、master_repl_offset（同步偏移量）；
  • Slave 节点：重点看 master_link_status（主节点连接状态，up/down）、slave_read_only（是否只读）。

2. 主从同步流程

3. 关键注意事项

  • Slave 原有数据会被 Master 数据覆盖（同步前 Slave 会清空本地数据）；
  • 同步延迟：Master 写操作先执行，再异步同步到 Slave，高并发下可能出现「Slave 数据滞后」；
  • 安全加固：Slave 虽只读，但仍可执行 CONFIG、DEBUG 等危险指令，建议通过 rename-command 屏蔽： 
    rename-command CONFIG ""  # 屏蔽CONFIG指令
rename-command FLUSHALL "" # 屏蔽FLUSHALL指令

4. 缺点

  • 手动故障切换：Master 宕机后需人工调整 Slave 为 Master；
  • 同步延迟：高并发场景下 Slave 数据可能滞后；
  • 单 Master 风险：Master 是单点，故障会导致写服务不可用。

四、Redis 哨兵集群（Sentinel）

1. 核心定义

Sentinel 是 Redis 主从集群的「高可用守护进程」，不处理数据读写，仅负责：

  • 监控：实时检查 Master/Slave 状态；
  • 自动故障转移：Master 故障时，自动将 Slave 升级为 Master；
  • 消息通知：将故障转移结果通知客户端；
  • 配置中心：客户端通过 Sentinel 获取当前 Master 地址。
核心配置（sentinel.conf）
# 监控主节点（核心配置）
# sentinel monitor <集群名> <MasterIP> <MasterPort> <quorum>
sentinel monitor mymaster 192.168.65.214 6379 2
# Master主观下线超时时间（默认30秒）
sentinel down-after-milliseconds mymaster 30000
# 故障转移超时时间
sentinel failover-timeout mymaster 180000
  • quorum：客观下线阈值（需至少 N 个 Sentinel 认为 Master 下线，才判定为客观下线），建议设为 Sentinel 节点数的「过半数」（如 3 个节点设 2，5 个节点设 3）。

2. 工作原理

步骤 1：主节点状态判断（主观下线→客观下线）

步骤 2：故障转移流程
  1. 选举 Sentinel Leader：通过 Raft 算法选举一个 Sentinel 节点作为 Leader，负责故障转移；
  2. 选举新 Master：从健康 Slave 中按规则选新 Master：
    • 优先：replica-priority 配置值最小的 Slave（默认 100，值越小优先级越高）；
    • 其次：同步偏移量（offset）最大的 Slave（数据最完整）；
    • 最后：RunID 字典序最小的 Slave；
  3. 切换主从关系：
    • Leader 向新 Master 发送 SLAVEOF NO ONE；
    • Leader 向其他 Slave 发送 SLAVEOF 新MasterIP 新MasterPort；
    • 旧 Master 恢复后，自动成为新 Master 的 Slave。

3. 缺点

  • 客户端需适配：Master 切换后，客户端需重新获取 Master 地址；
  • 数据丢失风险：Master 宕机时，未同步到 Slave 的写操作会丢失；
  • 单集群规模有限：仍基于单 Master 写，无法解决「数据分片」问题。

五、Redis 集群（Cluster）

1. 核心定义

Redis Cluster 是 Redis 官方分布式解决方案，核心解决：

  • 数据分片：将数据分散到多个 Master 节点（无中心节点）；
  • 自动故障转移：Master 故障时，自动将其 Slave 升级为 Master；
  • 客户端透明：客户端连接任意节点，自动路由到数据所在节点。
核心配置（redis.conf）
# 开启集群模式
cluster-enabled yes
# 集群配置文件（自动生成/更新，无需手动编辑）
cluster-config-file nodes-6379.conf
# 集群节点超时时间（默认5000ms）
cluster-node-timeout 5000
# 开启AOF（建议开启）
appendonly yes
集群搭建命令
# 创建三主三从集群（--cluster-replicas 1 表示每个Master对应1个Slave）
redis-cli -a 123qweasd --cluster create --cluster-replicas 1 \
192.168.65.214:6381 192.168.65.214:6382 192.168.65.214:6383 \
192.168.65.214:6384 192.168.65.214:6385 192.168.65.214:6386
集群核心操作
# 连接集群（-c 表示集群模式，自动路由）
redis-cli -a 123qweasd -p 6381 -c
# 查看集群节点
127.0.0.1:6381> cluster nodes
# 查看集群状态
127.0.0.1:6381> cluster info

2. 数据分片原理

Redis Cluster 将所有数据映射到 0-16383 共 16384 个哈希槽（slot），规则：

  • 每个 Master 节点负责一部分槽（如 6381 负责 0-5460，6382 负责 5461-10922，6383 负责 10923-16383）；
  • 数据键通过 CRC16(key) % 16384 计算所属槽，路由到对应 Master 节点；
  • Slave 节点同步对应 Master 的槽数据。
Redis Cluster 分片与高可用图解：

3. 高可用验证

  • 关闭某 Master 节点（如 6383），集群会自动将其 Slave（6384）升级为 Master；
  • 原 Master 恢复后，自动成为新 Master（6384）的 Slave；
  • 客户端写入数据时，仍按槽路由，无需手动切换地址。

4. 补充说明（生产建议）

  • 集群节点数：建议「3 主 3 从」及以上，且 Master 数为奇数（便于故障投票）；
  • 数据迁移：可通过 redis-cli --cluster reshard 手动调整槽分配；
  • 客户端适配：使用支持 Cluster 协议的客户端（如 JedisCluster、Lettuce）。

六、补充与总结

1. 核心补充

  • 持久化选型建议：
    • 缓存场景：关闭持久化；
    • 核心数据场景：开启混合持久化 + 定期 RDB 备份；
    • 金融级场景：AOF 同步策略设为「always」+ 主从 + 哨兵；
  • 性能优化：
    • 禁用大 key：大 key 会导致 RDB fork 卡顿、AOF 重写缓慢；
    • 调整 fork 性能：设置 vm.overcommit_memory = 1（避免 fork 失败）；
    • 合理设置 AOF 重写阈值：避免频繁重写消耗 CPU；
  • 监控重点：
    • 持久化：rdb_bgsave_in_progress、aof_rewrite_in_progress；
    • 主从：master_repl_offset、slave_lag；
    • 集群：cluster_state（ok/fail）、cluster_slots_assigned（已分配槽数）。

2.总结

模块 核心价值 生产推荐方案
性能压测 评估 Redis 读写能力 结合业务场景定制压测指令，对比基准值优化配置
持久化 防止单机数据丢失 混合持久化（RDB+AOF）+ 定期 RDB 备份
主从复制 读写分离、数据备份 1 主多从，Slave 只读，屏蔽危险指令
哨兵 主从自动故障转移 3 节点哨兵集群，quorum 设为 2
集群 数据分片、大规模高可用 3 主 3 从 Cluster，均匀分配哈希槽

Redis 分布式架构的核心是「从单机到集群，从手动到自动」，需根据业务规模选择：

  • 小规模（QPS<10 万）：主从 + 哨兵；
  • 大规模（QPS>10 万）：Redis Cluster；
  • 超大规模：Cluster + 多集群（按业务拆分）。
# redis # bootstrap # 前端
Logo
https://edu.csdn.net/learn/39067/627173?utm_source=2019755004

汇聚全球AI编程工具，助力开发者即刻编程。

更多推荐

cover

一个 API 入口调用多个大模型：AiiOnly客户端 + CC Switch 打通 Codex AI编程流程

avatar AI编程社区
cover

VSCode Claude Code + MiMo 中转免登录完整配置教程（解决原生登录弹窗 + 模型报错）

avatar AI编程社区
cover

从零开始做一个属于自己的 Skill（保姆级教程）

avatar AI编程社区