Redis on PlumePHP

Redis 性能调优与生产监控

Fri, 14 Aug 2026 14:10:00 +0800

1. 内存优化策略

1.1 查看内存使用

# 内存统计
INFO memory
# used_memory: 1073741824 # Redis 分配的总内存（字节）
# used_memory_rss: 1572864000 # OS 视角 RSS（含碎片、库等）
# mem_fragmentation_ratio: 1.46 # 碎片率 = RSS / used_memory
# used_memory_dataset: 805306368 # 纯数据占用
# used_memory_overhead: 268435456 # 内部数据结构开销

1.2 减少内存占用

策略	说明	适用场景
哈希化小对象	Hash 存储 > 10 个字段的对象	用户资料、配置
整数编码	String 存整数用 int 编码	计数器、ID
ziplist/listpack	小集合用紧凑编码	列表元素 < 512，单个 < 64B
共享对象	0-9999 整数复用	计数器值
持久化压缩	RDB 启用压缩	备份文件

# 查看某个 key 的内存占用
MEMORY USAGE user:1001

# 查看编码方式
OBJECT ENCODING user:1001:name # "embstr" / "raw" / "int"

1.3 内存上限与淘汰策略

# 配置最大内存
maxmemory 2gb

# 淘汰策略
maxmemory-policy allkeys-lru # 所有 key LRU 淘汰
# volatile-lru: 只淘汰有过期时间的 key（LRU）
# allkeys-lfu: 所有 key LFU 淘汰
# volatile-ttl: 淘汰即将过期的 key
# noeviction: 不淘汰，新写入报错（默认）

2. 大 Key 治理

2.1 大 Key 的危害

影响	说明
阻塞	单线程 Redis，大 Key 操作阻塞其他请求
网络瓶颈	传输大 Key 占用带宽
复制延迟	主从同步时大 Key 造成延迟
内存不均衡	Cluster 模式下某节点内存突增

2.2 检测大 Key

# 扫描大 Key（线上慎用，会阻塞）
redis-cli --bigkeys

# 内存采样分析
redis-cli --memkeys

# 查看具体 key 大小
MEMORY USAGE mykey SAMPLES 50

2.3 大 Key 拆分

# 大 Hash 拆分：按字段前缀分桶
# 原: HGETALL article:123 → 10000 个字段
# 拆: HGETALL article:123:content
# HGETALL article:123:metadata

# 大 List 拆分：按时间窗口
# 原: LPUSH log → 1000 万条
# 拆: LPUSH log:202401
# LPUSH log:202402

# 大 ZSet 拆分：按分数范围
# 原: ZADD timeline → 100 万条
# 拆: ZADD timeline:2024Q1
# ZADD timeline:2024Q2

# 渐进式删除大 Key（非阻塞）
UNLINK bigkey # 异步删除（Redis 4.0+）
# 或分批次删除
LRANGE biglist 0 99
LTRIM biglist 100 -1 # 循环直到删完

3. 慢查询诊断

3.1 慢查询日志

# 配置慢查询阈值（微秒）
CONFIG SET slowlog-log-slower-than 10000 # > 10ms
CONFIG SET slowlog-max-len 128

# 查看慢查询
SLOWLOG GET 10
SLOWLOG LEN
SLOWLOG RESET

3.2 延迟监控

# 内置延迟监控
CONFIG SET latency-monitor-threshold 10 # > 10ms 记录

LATENCY LATEST # 最新延迟事件
LATENCY HISTORY command # 命令延迟历史
LATENCY GRAPH command # 命令延迟分布图
LATENCY GRAPH fork # RDB/AOF fork 延迟
LATENCY DOCTOR # 延迟诊断建议
LATENCY RESET # 重置统计

3.3 常见延迟原因

原因	现象	解决
大 Key 操作	某命令耗时数百 ms	拆分大 Key
AOF 同步	fsync 阻塞	改为 everysec 或 no
RDB Fork	内存大时 fork 耗时	禁用/增大内存/使用 AOF
内存交换	内存不足触发 swap	增大物理内存或限制 maxmemory
网络延迟	跨可用区/地域	就近部署或使用连接池

4. 基准测试

# Redis 自带基准测试工具
redis-benchmark -h localhost -p 6379 -n 100000 -c 50

# 参数说明
# -n: 总请求数
# -c: 并发连接数
# -d: 数据大小（字节）
# -t: 测试的命令集
# -P: Pipeline 批量数

# 测试 Pipeline 性能
redis-benchmark -n 100000 -c 50 -P 16 -t set,get

# 测试特定命令
redis-benchmark -n 10000 -t lpush,lpop

5. 生产监控指标体系

指标	告警阈值	说明
used_memory	> maxmemory × 80%	内存使用率
mem_fragmentation_ratio	> 1.5 或 < 1.0	碎片率
connected_clients	> maxclients × 80%	连接数
rejected_connections	> 0	拒绝连接数
keyspace_hits / (hits+misses)	< 90%	命中率
instantaneous_ops_per_sec	观察趋势	实时 QPS
master_link_down_since_seconds	> 0	主从断连
rdb_last_bgsave_status	!= ok	持久化失败
aof_last_write_status	!= ok	AOF 写入失败

09. Java 客户端与 Spring Data Redis

Fri, 14 Aug 2026 14:09:00 +0800

1. Jedis vs Lettuce

特性	Jedis	Lettuce
线程安全	否（需连接池）	✅（基于 Netty）
连接方式	阻塞 BIO	异步非阻塞 NIO
连接池	必须	可选（通常不用）
集群支持	较好	更好
Spring Boot 默认	2.x 以前	2.x+

2. Spring Data Redis 配置

spring:
 data:
 redis:
 host: localhost
 port: 6379
 password: secret
 database: 0
 lettuce:
 pool:
 max-active: 8
 max-idle: 8
 min-idle: 0
 cluster:
 refresh:
 adaptive: true
 period: 60s

3. RedisTemplate

@Service
public class CacheService {
 @Autowired private StringRedisTemplate redisTemplate;
 @Autowired private RedisTemplate<String, Object> objectRedisTemplate;

 public void cacheUser(String userId, User user) {
 objectRedisTemplate.opsForValue().set(
 "user:" + userId, user, Duration.ofMinutes(30)
 );
 }

 public void addToList(String key, String item) {
 redisTemplate.opsForList().leftPush(key, item);
 redisTemplate.opsForList().trim(key, 0, 99); // 保留100条
 }

 // 原子递增
 public Long increment(String key) {
 return redisTemplate.opsForValue().increment(key);
 }

 // 分布式锁
 public boolean tryLock(String key, String value, long seconds) {
 Boolean locked = redisTemplate.opsForValue()
 .setIfAbsent(key, value, Duration.ofSeconds(seconds));
 return Boolean.TRUE.equals(locked);
 }
}

4. @Cacheable 注解

@Configuration
@EnableCaching
public class CacheConfig {
 @Bean
 public CacheManager cacheManager(RedisConnectionFactory cf) {
 return RedisCacheManager.builder(cf)
 .cacheDefaults(RedisCacheConfiguration.defaultCacheConfig()
 .entryTtl(Duration.ofMinutes(10))
 .serializeKeysWith(RedisSerializationContext
 .SerializationPair.fromSerializer(new StringRedisSerializer()))
 .serializeValuesWith(RedisSerializationContext
 .SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer()))
 )
 .build();
 }
}

@Service
public class ProductService {
 @Cacheable(value = "products", key = "#id")
 public Product getProduct(String id) {
 return productRepo.findById(id);
 }

 @CacheEvict(value = "products", key = "#product.id")
 public void updateProduct(Product product) {
 productRepo.save(product);
 }

 @CachePut(value = "products", key = "#product.id")
 public Product refreshProduct(Product product) {
 return product;
 }
}

Redis 事务、Lua 脚本与原子操作

Fri, 14 Aug 2026 14:08:00 +0800

1. Redis 事务（MULTI/EXEC/DISCARD）

1.1 事务模型

Redis 事务与关系型数据库事务不同：没有回滚机制，命令在 EXEC 时批量顺序执行，中间某命令失败不影响后续命令。

Redis 主从复制与 Sentinel 高可用

Fri, 14 Aug 2026 14:04:00 +0800

1. 主从复制（Replication）

1.1 复制流程

Slave 发起同步 ──→ Master 判断同步方式 ──→ 全量或增量同步

全量同步（首次或 runid 不匹配）：
 1. Slave 发送 PSYNC ? -1
 2. Master 执行 BGSAVE → 生成 RDB
 3. Master 发送 RDB 到 Slave
 4. Slave 清空内存 → 加载 RDB
 5. Master 将新写入命令追加到 Replication Buffer → 发送给 Slave
 6. 进入持续同步模式

增量同步（offset 在 replication backlog 内）：
 1. Slave 发送 PSYNC <runid> <offset>
 2. Master 检查 offset 是否在 backlog 中
 3. 直接发送缺失部分的命令 → Slave 执行
 4. 无需全量 RDB，快速恢复

1.2 关键概念

概念	说明
runid	Master 的唯一标识，重启后改变
offset	复制偏移量，Master 和 Slave 各自维护
replication backlog	Master 的固定大小缓存区（默认 1MB），存储最近命令
Replication Buffer	每个 Slave 连接的独立输出缓存

# 查看复制状态
INFO replication
# role:master
# connected_slaves:2
# slave0:ip=192.168.1.2,port=6379,state=online,offset=123456,lag=0
# master_repl_offset:123456

1.3 配置

# Slave 配置
replicaof 192.168.1.1 6379
masterauth <password>
replica-read-only yes

# 允许 Slave 处理过期 key（默认）
replica-lazy-flush yes

2. Sentinel 哨兵模式

2.1 架构与职责

 Client (连接 Sentinel 获取地址)
 │
 ┌───────────────┼───────────────┐
 │ │ │
Sentinel-1 Sentinel-2 Sentinel-3 (至少 3 个，奇数)
 │ │ │
 └───────────────┼───────────────┘
 │
 ┌─────▼─────┐
 │ Master │
 └─────┬─────┘
 ┌────────┴────────┐
 ┌────▼────┐ ┌────▼────┐
 │ Slave 1 │ │ Slave 2 │
 └─────────┘ └─────────┘

Sentinel 职责：
1. 监控：定时 ping Master/Slave/Sentinel
2. 通知：故障时通知管理员（通过脚本）
3. 自动故障转移：Master 宕机 → 选举新 Master
4. 配置提供：客户端向 Sentinel 询问当前 Master 地址

2.2 故障转移流程

1. Sentinel-1 发现 Master 无响应（主观下线，SDOWN）
2. 询问其他 Sentinel，多数同意 → 客观下线（ODOWN）
3. 选举 Leader Sentinel（Raft 算法）
4. Leader 选择最优 Slave 提升为 Master（选择优先级最高、复制最完整的）
5. 原 Slave 重新配置为新 Master 的 Slave
6. 客户端通过 Sentinel 获取新 Master 地址

2.3 Sentinel 配置

# sentinel.conf
sentinel monitor mymaster 192.168.1.1 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
sentinel auth-pass mymaster password

参数	说明
`monitor`	监控的 Master，最后的 2 是「同意下线」的 Sentinel 数
`down-after-milliseconds`	无响应判定为下线的时间
`failover-timeout`	故障转移超时
`parallel-syncs`	同时重新配置的 Slave 数

2.4 脑裂问题与解决

# 脑裂：网络分区时，原 Master 和 Sentinel 断开
# 原 Master 仍在写入，但已经不被 Sentinel 认可
# 分区恢复后，原 Master 的数据被覆盖 → 数据丢失

# 解决方案：主库最小从库数 + 延迟限制
min-replicas-to-write 1 # 至少有 1 个 Slave 同步才能写入
min-replicas-max-lag 10 # Slave 延迟超过 10 秒则拒绝写入

3. 读写分离

// Spring Boot + Lettuce 读写分离
@Bean
public RedisConnectionFactory lettuceConnectionFactory() {
 LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
 .readFrom(ReadFrom.REPLICA_PREFERRED) // 优先从 Slave 读
 .build();

 RedisStaticMasterReplicaConfiguration config =
 new RedisStaticMasterReplicaConfiguration("master", 6379);
 config.addNode("slave1", 6379);
 config.addNode("slave2", 6379);

 return new LettuceConnectionFactory(config, clientConfig);
}

// 纯 Lettuce
RedisClient client = RedisClient.create("redis://master:6379");
StatefulRedisMasterReplicaConnection<String, String> conn = MasterReplica.connect(
 client, StringCodec.UTF8,
 RedisURI.create("redis://slave1:6379"),
 RedisURI.create("redis://slave2:6379")
);
conn.setReadFrom(ReadFrom.REPLICA_PREFERRED);

Redis 持久化机制: RDB vs AOF

Fri, 14 Aug 2026 14:03:00 +0800

1. 为什么需要持久化

Redis 是内存数据库，进程退出后数据全部丢失。持久化将内存数据保存到磁盘，用于数据备份、灾难恢复和进程重启后的数据恢复。

2. RDB（Redis Database）快照

2.1 触发方式

# 手动触发
SAVE # 同步保存，阻塞主线程（生产不用）
BGSAVE # 后台异步保存，fork 子进程

# 自动触发（redis.conf）
save 900 1 # 900 秒内至少 1 个 key 变化 → 触发 BGSAVE
save 300 10 # 300 秒内至少 10 个 key 变化
save 60 10000 # 60 秒内至少 10000 个 key 变化
save "" # 禁用 RDB

2.2 Copy-On-Write 原理

BGSAVE 执行时：

1. 主进程 fork() 子进程
 │
 ├── 父进程（Redis 主线程）──→ 处理客户端请求
 │ │
 │ 写入 key A ──→ 页面被修改 ──→ COW 复制页面
 │ │ │
 │ 新数据 ──→ 新页 旧页（子进程读取）
 │
 └── 子进程 ──→ 读取内存页 ──→ 写入 RDB 文件

COW 开销：fork 时只需复制页表，无需复制全部内存
 实际额外内存 ≈ 写入操作涉及的数据量

2.3 RDB 优缺点

优点	缺点
文件紧凑，备份和传输方便	可能丢失两次快照间的数据
恢复速度快（直接加载）	大数据量时 fork 可能耗时较长
对运行时性能影响小

3. AOF（Append Only File）

3.1 写入策略

# 同步策略
appendfsync always # 每条命令 fsync → 最安全，性能最差
appendfsync everysec # 每秒 fsync → 默认，最多丢 1 秒数据
appendfsync no # 由 OS 决定 → 最快，最不安全

# 在 rewrite 期间是否不 fsync（减少 IO 压力）
no-appendfsync-on-rewrite yes

3.2 AOF 重写（Rewrite）

AOF 持续追加会不断膨胀，重写将内存中的最新数据生成精简的命令集。

Redis 缓存与高性能数据结构专题

Fri, 14 Aug 2026 14:00:00 +0800

Redis 是最流行的内存数据存储系统，不仅是缓存层的标准选择，还广泛应用在分布式锁、消息队列、实时排行榜、限流器等场景。本专题从底层数据结构深入到集群架构与安全运维。

Redis on PlumePHP

Redis 性能调优与生产监控

1. 内存优化策略

1.1 查看内存使用

1.2 减少内存占用

1.3 内存上限与淘汰策略

2. 大 Key 治理

2.1 大 Key 的危害

2.2 检测大 Key

2.3 大 Key 拆分

3. 慢查询诊断

3.1 慢查询日志

3.2 延迟监控

3.3 常见延迟原因

4. 基准测试

5. 生产监控指标体系

延伸阅读

09. Java 客户端与 Spring Data Redis

1. Jedis vs Lettuce

2. Spring Data Redis 配置

3. RedisTemplate

4. @Cacheable 注解

延伸阅读

Redis 事务、Lua 脚本与原子操作

1. Redis 事务（MULTI/EXEC/DISCARD）

1.1 事务模型

Redis 主从复制与 Sentinel 高可用

1. 主从复制（Replication）

1.1 复制流程

1.2 关键概念

1.3 配置

2. Sentinel 哨兵模式

2.1 架构与职责

2.2 故障转移流程

2.3 Sentinel 配置

2.4 脑裂问题与解决

3. 读写分离

延伸阅读

Redis 持久化机制: RDB vs AOF

1. 为什么需要持久化

2. RDB（Redis Database）快照

2.1 触发方式

2.2 Copy-On-Write 原理

2.3 RDB 优缺点

3. AOF（Append Only File）

3.1 写入策略

3.2 AOF 重写（Rewrite）

Redis 缓存与高性能数据结构专题