## 01、痛点

我是老李。有一次订单中心接口在上量后 P99 从 180ms 飙到 900ms，监控看 Redis CPU 只有 20%，内存使用率 52%，没有慢查询告警。团队第一反应是调 maxmemory、换 LRU 策略、加连接池。调了一轮，P99 只降了不到 50ms。后来用 Slowlog 抓不到几条慢命令，但客户端埋点发现一次请求里有 40 多次 Redis 往返，其中有个 Key 的 JSON 体 2.3MB，每次查询都全量拉出来。问题不在 Redis 忙，而在我们用错了数据结构和访问方式。

这就是今天要聊的：真正的 Redis 优化首先是内存和数据模型优化，然后才是参数调优。为什么现在要讲？因为 Redis 8.10 在 Core、Search、JSON 等方向继续做了大量内存和性能优化，其中 Compact Hash 是很重要的内存优化能力，很多团队还没用上；同时 Spring Boot 2.7/3.x 配合 Lettuce 和 Micrometer 已经能很好观测缓存，但多数人仍只在参数层面试错。

## 02、是什么

Redis 优化分三层。第一层是数据模型，包括 Key 命名、结构选型、字段数量、过期时间；第二层是内存与访问模型，包括 maxmemory、淘汰策略、大 Key、热 Key、序列化成本；第三层才是参数调优。只调第三层，无法解决前两层的结构性问题。

核心概念：
- maxmemory：Redis 允许使用的最大内存，达到后按 eviction policy 淘汰。
- LRU/LFU：Redis 两种淘汰近似算法。LRU 按最近使用时间，LFU 按使用频率。
- TTL：键的过期时间，惰性删除和定期删除共同完成。
- eviction policy：noeviction、allkeys-lru、allkeys-lfu、volatile-lru、volatile-lfu、volatile-ttl 等。
- 大 Key：单个键的 Value 过大，通常是字符串大对象、集合元素过多，会导致读取阻塞、网络传输放大。
- 热 Key：访问特别集中的 Key，可能打爆单分片。
- Slowlog：记录执行耗时超过阈值的命令，但不记录网络等待和排队时间。
- Pipeline：客户端把多个命令打包发送，减少网络往返 RTT。
- 连接池：复用连接，避免每次请求建连。Lettuce 基于 Netty，连接是单连接多路复用。
- 网络 RTT：一次命令从客户端到服务端再返回的时间，跨机房可能是 1-5ms。
- 序列化成本：JDK 序列化通常体积大、慢；JSON 可读但仍有冗余；String 直接存文本，往往最快。

Redis 8.10 在 Core、Search、JSON 等方向继续优化，如更紧凑的 Hash 存储、Search 查询性能提升、JSON 路径解析内存减少。其中 Compact Hash 是针对小 Hash 的编码优化，字段较少时使用紧凑数组而不是哈希表，降低内存占用。

## 03、为什么

为什么内存和数据模型优先？因为 Redis 单线程命令执行模型决定了：一个慢命令会阻塞后续所有命令。大 Key 读取需要分配大块内存并拷贝到输出缓冲区，可能让主线程停顿几十甚至几百毫秒。热 Key 虽然单次很快，但集中打到同一分片会造成 CPU 飙到单核瓶颈，其他 Key 排队。这解释了一个反直觉现象：Redis 总体 CPU 20%，但某个核已经 100%，P99 很高。单线程只用一个核，而 Redis 6 之后虽然有多线程 IO，但命令执行仍是单线程。所以 CPU 20% 可能已经是单核上限，也可能瓶颈不在 Redis，而在客户端序列化、网络 RTT、GC 或业务逻辑。

序列化成本常被低估。JDK Serialization 生成字节流通常比 JSON 大 3-10 倍，且需要 Java 原生反序列化，CPU 消耗高。如果把 2MB 的对象用 JDK 序列化塞进 Redis，读出来反序列化可能花 100ms。数据模型同样关键：存储大 JSON 字符串，每次只改一个字段却全量读写；换成 Hash 按字段存储，读写只触碰相关字段，网络传输和内存都降下来。TTL 设置不当也会引起内存浪费或缓存雪崩。淘汰策略在 maxmemory 触发时如果选 noeviction 会直接报错；如果选 allkeys-lru，高频但不够新的 Key 可能被误淘汰，导致缓存命中率下降、打到数据库。参数调优是在正确的内存/数据模型上做微调，不是救命稻草。

## 04、架构

从请求路径拆解一次 Redis 访问：业务线程 -> 序列化器 -> Lettuce 连接池 -> 网络发送 -> Redis 服务端事件循环 -> 命令执行 -> 数据结构读写 -> 内存分配/释放 -> 响应返回 -> 反序列化。每一层都可能产生延迟和内存放大。

数据模型架构建议：
- Key 采用业务域:对象:标识，如 order:detail:123456，禁用过长 Key，哈希标签用 {} 控制分片。
- 热数据用 Hash 而不是大 JSON 字符串，字段独立更新。
- 冷热分离：热 Key 可以本地缓存或业务侧多副本，避免集中。
- TTL 采用基础值加随机抖动，防止同一时间大量过期。
- 大集合用拆分或压缩编码，如 Redis 8.10 的 Compact Hash 对 small hash 减少内存。

连接架构：Lettuce 默认是共享单个连接，命令通过 Netty 多路复用，适合高并发；不像 Jedis 需要连接池对应线程。连接池参数如 max-active、max-idle、timeout、command timeout 要结合业务设置。配太多连接并不能提高吞吐，反而增加 Redis 客户端和服务端上下文切换。Micrometer 可以暴露 Lettuce 连接池指标和 Redis 命令耗时。

Redis 8.10 优化点：Core 层对整数编码、SDS 内存分配做了优化；Search 模块减少索引暂存内存；JSON 模块对路径查找和嵌套对象序列化做了压缩。Compact Hash 让一个小 Hash 在字段数量小于阈值时使用数组存储字段和值，省掉 dictEntry 指针和哈希表，特别适合用户画像、配置项、商品属性等场景。

## 05、实战

准备一个 Spring Boot 3.x 项目，依赖 spring-boot-starter-data-redis、lettuce-core、micrometer-registry-prometheus。实体以订单详情为例，包含 orderId、userId、skuId、price、address、extJson 等字段。

第一步：比较三种序列化器。
- JDK Serialization：使用 JdkSerializationRedisSerializer，需要类实现 Serializable。优点是对象直接读写；缺点体积大、跨语言差、反序列化慢。
- JSON：使用 GenericJackson2JsonRedisSerializer，可读性好，但需要类型信息或指定类型，序列化体积中等。
- String Serializer：手动把对象用 Jackson 转成 String 再 set，读取时再反序列化。最灵活，可以控制字段裁剪，也便于排查。

配置 RedisTemplate，使用 StringRedisSerializer 作为 key，value 分别替换。Jackson 的 ObjectMapper 配置 FAIL_ON_UNKNOWN_PROPERTIES 为 false。

测试接口：
- /nocache：每次查数据库，不经过 Redis。
- /cache-json：Redis 存整个订单 JSON，命中后读取整个 JSON 反序列化。
- /cache-hash：Redis 用 Hash 存订单字段，按需 HMGET 指定字段。
- /cache-pipeline：批量查询 20 个订单，使用 Lettuce 的 executePipelined 批量发送。
- /cache-mget：批量查询 20 个订单，使用 RedisTemplate.opsForValue().multiGet 一次取多个。

连接参数配置在 application.yml：
spring.data.redis.host: 127.0.0.1
spring.data.redis.port: 6379
spring.data.redis.timeout: 300ms
spring.data.redis.lettuce.pool.max-active: 16
spring.data.redis.lettuce.pool.max-idle: 8
spring.data.redis.lettuce.pool.min-idle: 2
spring.data.redis.lettuce.shutdown-timeout: 100ms

Micrometer 注册 LettuceCommandLatency 指标，在 Grafana 观察命令平均耗时和 P95。

压测使用 wrk 或 JMeter，并发 200，持续 60 秒。记录 QPS、P95、Redis 内存使用、客户端 CPU。

结果示例：
- 无缓存：QPS 420，P95 780ms，数据库 CPU 高。
- 普通缓存 JSON：QPS 2100，P95 160ms，Redis 内存 1.8GB；但单个大 JSON 读取偶发 P99 900ms，与 Full GC 和大 Key 有关。
- 普通缓存 Hash：QPS 3800，P95 72ms，Redis 内存 0.9GB；因为只取需要的字段，反序列化开销小。
- Pipeline 批量 20：QPS 5200，P95 48ms；RTT 从 20 次降到 1 次，吞吐大幅提升。
- MGET 批量 20：QPS 6100，P95 40ms；单命令批量读取比 Pipeline 更直接。
- 序列化对比：JDK 序列化写入 1 万次平均 18ms，JSON 6ms，String 4ms；内存占用 JDK 是 JSON 的 3 倍。

分析：普通缓存 JSON 虽然命中，但大 JSON 每次全量反序列化，GC 压力大；Hash 按字段访问减少网络和 CPU；Pipeline/MGET 主要消除 RTT，对批量场景收益最大。

## 06、洞见

第一，先做数据模型审计，再谈参数。用 redis-cli --bigkeys 或 RedisInsight 找大 Key，用 OBJECT ENCODING key 看编码是否正常。小 Hash 如果还是 hashtable，说明没触发紧凑编码，检查 Redis 版本和 hash-max-listpack-entries 参数。Redis 8.10 的 Compact Hash 会自动优化，但仍需避免字段过多。

第二，热 Key 不能靠加 Redis 内存解决。单分片打满是单核瓶颈，需要客户端本地缓存、读写分离、业务侧打散、增加副本或使用代理层分发。

第三，序列化成本必须量化。不要只看 Redis 内存，还要看客户端 CPU、GC 和反序列化耗时。String 加手动 Jackson 往往性价比最高。

第四，网络 RTT 是隐形杀手。跨可用区甚至跨机房，一次 RTT 可能 2-10ms，循环 50 次就是 100-500ms。Pipeline、MGET、Lua 脚本把多次往返合并成一次，是最直接的降 P99 手段。

第五，连接池不是越大越好。Lettuce 单连接即可承载高并发，连接数过多反而增加内存和线程切换。关注 command timeout 和资源泄漏。

第六，Redis 8.10 的优化方向说明：Core、Search、JSON 持续减少内存和 CPU，使用新版本并关注新编码，能获得无侵入的性能提升。Compact Hash 对商品属性、用户标签、配置项等小 Hash 场景尤其有效。但升级前要验证序列化兼容性和持久化格式。

第七，监控指标要分层：Slowlog 只能看到服务端执行慢，看不到排队和网络。必须结合客户端埋点、Micrometer、Redis 的 total_commands_processed、instantaneous_ops_per_sec、evicted_keys、keyspace_hits/misses 等指标。

## 07、行动

如果你遇到“Redis CPU 只有 20%，但接口 P99 很高”的情况，按下面路径排查：
1. 客户端埋点：统计一次接口中 Redis 命令数量、每个命令耗时、序列化耗时、网络 RTT。如果命令次数多，先做 Pipeline/MGET 合并。
2. 抓 Slowlog：SLOWLOG GET 50，查看是否有超过 10ms 的命令。没有慢命令不代表没问题，可能是大量小命令排队或网络等待。
3. 找大 Key：redis-cli --bigkeys，或使用 MEMORY USAGE key 查看单 Key 内存。大 Key 即使不慢，也会导致客户端内存和 GC 压力。
4. 查热 Key：使用 MONITOR 或 RedisInsight 的热 Key 分析，看是否有单 Key 访问集中。热 Key 单分片 CPU 高，但整体 CPU 可能不高。
5. 看淘汰和命中：INFO stats 中的 keyspace_hits/misses、evicted_keys。命中率低、淘汰多说明数据模型或 maxmemory 设置有问题。
6. 检查序列化体积：把要存的对象大小打出来，比较 JDK/JSON/String 三种方式。如果单对象超过 100KB，考虑拆分 Hash 或压缩。
7. 检查连接池与超时：Lettuce 连接池参数、command timeout 是否过小导致排队，连接是否被占满。
8. 网络路径：是否跨可用区？Ping 一下 Redis 延迟。RTT 高就必须合并命令。
9. 看 Redis CPU 具体核：Redis 单线程命令执行，整体 20% 可能已经是单核 100%。用 top -H 或 pidstat 查看线程，确认是否达到单核上限。
10. 验证 Redis 版本与编码：如果是 Redis 7/8，用 OBJECT ENCODING 查看小 Hash 是否 compact/listpack，String 是否 int/embstr。

行动清单：
- 立即抓 Slowlog 和 bigkeys，定位大 Key、慢命令。
- 把批量循环改成 Pipeline 或 MGET。
- 大 JSON 对象改 Hash，只读写必要字段。
- 热 Key 增加本地缓存或业务打散。
- 统一用 String 序列化 + Jackson，避免 JDK 默认序列化。
- 升级到 Redis 8.10 后，观察 Compact Hash 带来的内存下降，但需先做基准测试。

## 08、小结

Redis 优化不是调 maxmemory 和淘汰策略就能解决高 P99。真正的顺序是：先看数据模型是否合理，Key 和结构是否匹配访问方式；再看内存与访问模型，大 Key、热 Key、TTL、淘汰策略是否健康；最后才是连接池、超时、序列化等参数调优。Redis 8.10 在 Core、Search、JSON 和 Compact Hash 上的优化，为内存和性能提供了新红利。Spring Boot 项目里用 Lettuce 加 Micrometer，把命令耗时、连接池、命中率暴露出来，才能从“感觉慢”走向“指标定位”。记住一句话：缓存不是把数据库搬进 Redis，而是把访问模式搬进数据结构。

## 09、链接与概念说明

概念说明：
- maxmemory：Redis 最大内存上限，达到后按淘汰策略释放。
- LRU/LFU：近似最近最少使用 / 最不频繁使用淘汰算法。
- TTL：键存活时间，过期后惰性删除和定期删除。
- eviction policy：内存达到上限时的键淘汰策略。
- 大 Key：单个 Value 内存占用过大的键，会导致阻塞和网络放大。
- 热 Key：访问频率极高的键，容易造成单分片瓶颈。
- Slowlog：Redis 记录执行超过阈值的命令，是服务端慢日志。
- Pipeline：客户端一次发送多条命令，减少网络往返。
- 连接池：复用客户端与 Redis 的 TCP 连接，Lettuce 采用单连接多路复用。
- 网络 RTT：请求响应往返时间，跨机房影响显著。
- 序列化成本：对象与字节流转换的 CPU 和空间开销。
- Compact Hash：Redis 对小 Hash 的紧凑存储编码，字段少时用数组存储，降低内存。

参考链接：
- Redis 官方文档内存优化：https://redis.io/docs/latest/operate/oss_and_stack/management/optimization/memory-optimization/（如果无法访问可搜索 redis memory optimization）
- Redis 8.10 发布说明：可搜索 Redis 8.10 release notes，关注 Core、Search、JSON 与 Compact Hash 改进。
- Spring Data Redis 文档：搜索 spring data redis lettuce 配置。
- Lettuce 官方文档：搜索 lettuce connection pooling。
- Micrometer 指标：搜索 micrometer redis 指标。
- redis-cli --bigkeys 使用：搜索 redis bigkeys and memory usage。

以上链接只作为扩展阅读，关键还是在自己的项目里做一次数据模型审计和客户端埋点。

我是老李。有一次订单中心接口在上量后 P99 从 180ms 飙到 900ms，监控看 Redis CPU 只有 20%，内存使用率 52%，没有慢查询告警。团队第一反应是调 maxmemory、换 LRU 策略、加连接池。调了一轮，P99 只降了不到 50ms。后来用 Slowlog 抓不到几条慢命令，但客户端埋点发现一次请求里有 40 多次 Redis 往返，其中有个 Key 的 JSON 体 2.3MB，每次查询都全量拉出来。问题不在 Redis 忙，而在我们用错了数据结构和访问方式。

《Redis 8.10 + Spring Boot 实战》第13招 内存与性能——Redis 快不代表你的 Redis 系统一定快

一次 Redis 延迟排查让我明白：接口 P99 高不一定是 Redis 忙，而是大 Key、序列化膨胀和网络往返在拖后腿。本文从内存模型、数据模型到 Spri

架构师

数据库

后端

架构设计

Redis优化核心在于数据模型和内存结构，而非仅调参数。大Key、热Key和序列化成本是P99飙升的主因，需优先审计。通过Hash存储替代大JSON、用Pipeline/MGET合并命令、控制序列化体积，能显著降低延迟。Redis 8.10的CompactHash进一步减少小Hash内存占用。结合客户端埋点与监控定位瓶颈，实现从"感觉慢"到"指标驱动"的转变。

往返时间

数据结构

Redis

JSON

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Redis优化核心在于数据模型和内存结构，而非仅调参数。大Key、热Key和序列化成本是P99飙升的主因，需优先审计。通过Hash存储替代大JSON、用Pipeline/MGET合并命令、控制序列化体积，能显著降低延迟。Redis 8.10的CompactHash进一步减少小Hash内存占用。结合客户端埋点与监控定位瓶...

《Redis 8.10 + Spring Boot 实战》第13招 内存与性能——Redis 快不代表你的 Redis 系统一定快-腾讯云开发者社区-腾讯云

《Redis 8.10 + Spring Boot 实战》第13招内存与性能——Redis 快不代表你的 Redis 系统一定快

《Redis 8.10 + Spring Boot 实战》第13招内存与性能——Redis 快不代表你的 Redis 系统一定快

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Redis 8.10 + Spring Boot 实战》第13招 内存与性能——Redis 快不代表你的 Redis 系统一定快

《Redis 8.10 + Spring Boot 实战》第13招 内存与性能——Redis 快不代表你的 Redis 系统一定快

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Redis 8.10 + Spring Boot 实战》第13招内存与性能——Redis 快不代表你的 Redis 系统一定快

《Redis 8.10 + Spring Boot 实战》第13招内存与性能——Redis 快不代表你的 Redis 系统一定快