capacity ledger / chapter 04
Redis 内存预算与 big key 决策器
先把每个 key 的账算清楚，再决定实例是否还有余量；big key 不是一个固定数字，而是体量、访问方式与运维动作共同造成的风险。
01 · 容量账本
估算用于前期选型与压测起点，生产值仍应由采样校准
0%
安全预算使用率
计算中
本次预算明细
- 业务数据与元数据
- —
- 碎片与分配器增量
- —
- 为持久化 / 复制预留
- —
- 预算后剩余
- —
≤ 70% 从容70–90% 观察> 90% 危险
02 · big key 决策台
把“它有多大”和“怎样访问它”放在一起判断
优先拆分，并改造遍历方式
该画像同时出现体量、元素数和全量读取风险。先确认访问链路，再逐步迁移，避免直接在线重写整份数据。
按业务维度拆分
渐进遍历
用 UNLINK 删除
03 · 从估算回到证据
先观测，再改造；扫描命令安排在低峰期并关注实例负载
看某个 key 的内存
MEMORY USAGE 返回 Redis 为该 key 及其 value 分配的字节数；复杂类型可用采样数平衡精度和成本。
MEMORY USAGE user:profile:42 SAMPLES 10
估算键空间内存构成
--memkeys 逐步扫描 keyspace，按类型报告内存分布，适合寻找主要占用来源。
redis-cli --memkeys
找各类型的大 key
--bigkeys 扫描并报告每种类型中较大的 key；它是发现线索，不等于替你定义了业务风险。
redis-cli --bigkeys
核对实例整体水位
关注 used_memory、used_memory_rss、mem_fragmentation_ratio 与峰值，验证账本假设。
redis-cli INFO memory
别把警戒带当成 Redis 的硬限制：本页用 70% / 90%、10 MiB、10 万元素等条件生成规划提示，它们是便于讨论的经验起点。编码方式、命令复杂度、网络带宽、客户端超时、持久化策略与业务延迟目标都会改变实际边界。上线前应通过 MEMORY USAGE、压测和生产监控校准。
为什么预留不能只看 maxmemory？
Redis 的数据占用并不是操作系统看到的全部内存。复制缓冲区、客户端缓冲区、加载过程、写时复制以及内存分配器碎片都可能抬高 RSS。发生 RDB 或 AOF 重写时，父子进程写时复制还会出现额外峰值。因此账本把“可用内存”与“允许业务数据长期占用的安全预算”分开，余量不是浪费，而是给变更和故障恢复留出操作空间。