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

缓存架构演进之路：从单机 Redis 到亿级分布式多级缓存体系

Sun, 16 Aug 2026 15:00:00 +0800

缓存是构建高性能 Web 系统的核心基础设施。从早期工程师在单机内存里放一个 HashMap 临时存数据，到今天支撑亿万 QPS 的分布式多级缓存体系，缓存架构经历了一场深刻的技术演进。理解这一演进过程，不仅有助于我们在不同业务阶段做出合理的架构选型，更能帮助我们在面对电商大促、社交热点等高并发场景时从容应对。本文将系统梳理缓存架构从单体到分布式的完整演进路径，并深入探讨热点 Key 治理、一致性哈希、缓存预热及成本优化等生产实践议题。

Redis 7.x 重大新特性与架构升级深度解析

Sun, 16 Aug 2026 14:00:00 +0800

Redis 7.x 是 Redis 发展史上最重要的版本之一。从 2022 年 Redis 7.0 GA 发布，到 2023 年 Redis 7.2 引入 waitaof 和客户端驱逐，再到 2024 年 Redis 7.4 及 Redis 8.0 预览版的推出，这一系列的版本迭代不仅在底层数据结构上完成了关键重构，还在服务端脚本、权限安全、集群通信和性能扩展方面带来了革命性变化。本文将逐层拆解 Redis 7.x 每个大版本的核心改进，并提供生产环境迁移的完整决策地图。

Redis 消息队列深度对比：Pub/Sub、Streams 与 Kafka/RabbitMQ 选型指南

Sun, 16 Aug 2026 13:00:00 +0800

消息队列是现代分布式系统的核心基础设施。Redis 作为广为人知的内存数据库，在消息队列领域提供了 Pub/Sub 和 Streams 两套方案。与此同时，Apache Kafka 和 RabbitMQ 长期占据专业消息中间件的主导地位。它们之间不是简单的替代关系，而是在延迟、吞吐量、持久化与运维成本之间做出了不同的权衡。本文将从架构原理到生产实战，全方位对比这四种方案，帮助你做出准确的技术选型。

Redis 数据迁移与集群扩容：从单节点到分布式的大规模迁移实战

Sun, 16 Aug 2026 12:00:00 +0800

Redis 作为内存数据库，在生产环境的生命周期中必然面临各种迁移需求：业务增长推动单节点升级为集群架构、机房搬迁需要跨数据中心迁移、服务器老化触发硬件替换，或是云原生转型需要接入 Kubernetes 部署。每一次迁移都牵一发而动全身，数据完整性、服务可用性、迁移效率三者必须同时满足。本文从真实生产场景出发，系统梳理 Redis 数据迁移的九大核心主题，涵盖工具选型、Slot 重分片、BigKey 治理、一致性校验与零停机切换的完整操作流程。

Redis 监控与可观测性实战：生产运维全链路指南

Sun, 16 Aug 2026 11:00:00 +0800

Redis 在生产环境中性能极高，但一旦出现问题往往是突发性的：内存瞬间耗尽导致 OOM、单条慢查询拖垮主线程、客户端连接数暴涨引发服务拒绝。监控与可观测性不是锦上添花，而是保障 Redis 持续可靠运行的底线工程。

Redis 微服务架构模式：缓存、限流、会话与熔断

Sun, 16 Aug 2026 10:00:00 +0800

微服务架构将单体应用拆分为独立部署的服务单元，每个服务拥有自己的数据域和生命周期。在这一架构下，Redis 不再只是简单的缓存组件，而是演变为支撑服务间通信、数据共享、流量治理和高可用保障的基础设施。本文系统梳理 Redis 在微服务场景中的八大核心模式，并提供可落地的代码实现。

Redis 网络模型与高 I/O 性能：从单线程事件循环到多线程 I/O

Sat, 15 Aug 2026 14:30:00 +0800

Redis 之所以能在单机缓存领域长期保持 10 万 QPS 以上的吞吐量，与其精心设计的网络模型密不可分。从经典的单线程事件循环到 Redis 6.0 引入的多线程 I/O，从 RESP 明文协议到 TLS 加密传输，每一步架构选择都蕴含着深刻的工程权衡。本文深入 Redis 底层源码与操作系统机制，带你理解 C10K（单机万级连接）甚至 C100K 场景下 Redis 如何做到高并发低延迟，以及在生产环境中如何调优网络参数、规避性能陷阱。

Redis 内存管理深度解析：分配器、碎片治理与驱逐策略

Sat, 15 Aug 2026 14:00:00 +0800

Redis 作为纯内存数据库，内存不仅是数据存储介质，更是决定服务可用性的核心资源。一个 64GB 内存的 Redis 节点，可能实际存储的有效数据不足 40GB，剩余空间被内部分配器开销、数据结构元数据、内存碎片以及过期键残留所吞噬。理解 Redis 内存管理的底层机制，是在生产环境中避免 OOM、控制成本、提升容量的必修课。

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