1. 监控阶段：建立可观测性
1.1 关键指标与数据源
在面对Redis 内存过高的问题时，首先要建立完整的可观测性体系。关注的核心指标包括used_memory、used_memory_rss、maxmemory、mem_fragmentation_ratio以及数据库维度的dbsize、keys数量等。通过这些指标可以快速判断内存是否已接近上限、是否存在内存碎片，以及热数据与冷数据的分布情况。
除了 Redis 自身的指标，操作系统层面的内存、容器/虚拟机的内存配额、以及持久化相关的内存开销也是重要的数据源。将 主机内存、cgroup 限制、页面换出率等信息纳入监控，可以帮助判断是否存在内存抖动、内存碎片加剧等问题。
1.2 监控工具与数据可视化
建议将 Redis 的内存指标接入集中监控平台，结合 Prometheus、Grafana 等工具实现可视化告警。通过仪表盘可以直观地看到 内存使用趋势、突发峰值、碎片比率 的变化，以及 maxmemory 与 eviction 策略的关系。
常用的数据抓取方式包括直接执行命令获取内存相关信息，以及使用专门的扩展插件/模块提供更丰富的指标。常用命令组合示例如下，能够快速定位内存信息的分布情况：
redis-cli INFO memory
此外，通过 MEMORY STATS 与 MEMORY USAGE 等子命令，可以分解内存来源，帮助定位高内存对象的结构和数量。
redis-cli MEMORY STATS
redis-cli MEMORY USAGE some:hot:key
2. 排查阶段：定位内存飙升的原因
2.1 常见内存热点与原因
内存过高往往来自几个维度的叠加：一是缓存命中率高但数据量持续增长导致内存占用持续上升；二是数据结构选择不当，例如大量使用 Strings/Hashes造成单个键的内存膨胀；三是持久化/快照策略与 AOF 重写引发瞬时内存抖动。了解这些热点，有助于有的放矢地进行后续优化。
在排查阶段，可以优先定位以下几类对象：热Key、占用内存最大的 Key、以及高基数数据的结构体。通过统计 Key 的 MEMORY USAGE、查看 大键与大结构的分布，可以快速锁定问题区域。
2.2 诊断工具与诊断命令
对内存诊断而言，MEMORY DOCTOR、MEMORY STATS、以及 MEMORY USAGE 是三件最直接的辅助工具。MEMORY DOCTOR 会给出内存使用的原因与优化建议，结合实际场景进行逐项排查。
如果需要逐键定位大对象，可以使用如下命令对单个键进行内存统计与定位：
redis-cli MEMORY USAGE some:hot:key对整个数据库的内存分布进行全局分析时，可以使用 MEMORY STATS 获取结构化统计信息，再结合 Redis 版本和部署方式，推断碎片率与分配情况。
redis-cli MEMORY STATS
通过这组诊断，若发现 mem_fragmentation_ratio>1.5、used_memory_rss 与 used_memory 相差较大，说明存在显著的内存碎片问题，需要进一步处理。
3. 实战优化：从配置到策略落地
3.1 优化内存配置与回收策略
在确认内存压力后，第一步通常是通过调整 maxmemory 与 maxmemory-policy 来控制内存使用和淘汰策略。将内存上限设定在机器可承载范围，并选择合适的淘汰策略，可以有效控制内存过高的情况。
redis-cli CONFIG SET maxmemory 2gb
redis-cli CONFIG SET maxmemory-policy allkeys-lru
若系统存在持续的写入压力，可以结合持久化策略优化来减缓内存暴涨。对写入-持久化的平衡进行权衡，必要时调整持久化策略或禁用部分高成本的持久化操作，以降低突发的内存峰值。
redis-cli CONFIG SET appendonly yes
redis-cli CONFIG SET appendfsync everysec
redis-cli CONFIG SET save "900 1 300 10 60 10000"
另一种做法是通过限制 AOF 重写的触发条件，避免在高并发时段频繁触发重写造成内存波动。相关参数可以结合实际场景进行调整。
redis-cli CONFIG SET auto-aof-rewrite-percentage 50
redis-cli CONFIG SET auto-aof-rewrite-min-size 64mb
3.2 数据结构与使用场景的优化
在内存过高时，重新评估数据结构是关键。对于大量字段聚合的场景，可以考虑将 Hash 的字段分散到多个键，或者将热数据以合并聚合的方式存储，减少单个键的内存占用。
同时，对高基数数据尽量避免使用唯一字符串作为主键，改用 紧凑的数据结构（如 ZSET 的分区策略、HyperLogLog 代替部分去重操作、Bitmap/Bitfield 的位级操作等），以降低单位数据的内存占比。
# 将大 Hash 拆分成若干 Hash，以降低单键内存膨胀
HSET user:1001 field1 value1
HSET user:1001:part2 field2 value2
通过分区策略将冷数据迁移到其他存储介质或缓存层，也能显著减轻单实例内存压力。
3.3 持久化与内存压力的权衡
持久化策略对内存压力影响显著，AOF 重写与 RDB 保存会产生额外的内存开销。在内存高峰期，可以选择短期内降低持久化强度，或在内存压力缓解后再逐步开启完整的持久化策略。
具体做法包括：降低 RDB 的快照频率、减少 AOF 的写入开销、以及在非高峰期执行重写操作。通过动态调整策略，可以在不牺牲数据安全的前提下缓解内存压力。
redis-cli CONFIG SET save ""
redis-cli CONFIG SET snapshotting-delay 60
3.4 实战落地：场景化演练与落地步骤
场景一：应用高并发写入导致内存快速上升。落地步骤如下：先用 maxmemory 控制容量，设定合理的淘汰策略；再通过对热 Key 的分离和结构优化降低单键内存占比；最后评估持久化配置与重写策略，确保在内存压力下仍可保持可用性。
redis-cli CONFIG SET maxmemory 1gb
redis-cli CONFIG SET maxmemory-policy allkeys-lru
场景二：内存碎片显著，mem_fragmentation_ratio 高于阈值。落地策略包括分析碎片来源、临时性清理与重启计划，以及对结构的重构以降低碎片。
redis-cli MEMORY DOCTOR
场景三：热数据集增大，需要分区或持久化策略调整。落地做法包括按热度分区、将冷数据改为只读缓存、并在必要时使用外部存储缓解内存压力。
通过上述步骤，可以构建一个从监控到排查再到实战优化的完整路径，确保在Redis 内存过高时有清晰的诊断和落地的优化方案。所有操作均可结合实际集群架构、部署方式与业务场景进行定制化调整。
