分布式缓存成本如何控制？
简化版
缓存成本控制不是简单缩容，而是删除无收益数据、优化编码和 value、按业务价值分层 TTL，再提高实例利用率。要用“每 GB/QPS 成本”和“缓存节省的数据库成本、延迟收益”共同衡量，避免为了省缓存把压力转回更昂贵的数据库或造成可用性风险。
详细版
先建立成本账本：实例与副本内存、网络、持久化、跨区流量、运维成本，以及按命名空间/业务归属的 key 数、实际内存、QPS、命中率和回源成本。低命中、长 TTL、大 Value、重复缓存、多份索引和孤儿 Key 是常见浪费。
治理顺序通常是：设置 owner 和预算；清理无 owner/无访问 Key；压缩或拆分 value，只缓存高频字段；按数据价值设 TTL 与淘汰策略；避免多层缓存重复保留全量数据；合并小请求和优化序列化；最后才考虑调整副本、规格和装箱率。关键数据的副本与故障余量不能作为第一刀。
每项节省都需评估回源增量和 SLO。例如命中率从 95% 降到 90%，数据库 miss 流量会从 5% 翻到 10%，不是只下降 5 个百分点。通过灰度观察数据库 QPS/P99、缓存淘汰、网络和故障接管容量，再决定全量。
完整版教学
一、先定义缓存的收益与成本
缓存消耗内存、CPU、网络、副本和运维，却能减少数据库查询、降低延迟并吸收峰值。只有成本没有收益口径，会得出“删缓存最省钱”的错误结论；只有命中率没有资源成本，也会让团队无限堆内存。
可把单位时间净收益近似为：数据库/下游避免的成本 + 延迟与容量收益 - 缓存总成本。金额不一定精确，但至少要按业务拆分，让低价值缓存不能长期占用公共集群。
记忆钩子：缓存成本优化看的是“每一 GB 内存避免了多少昂贵工作”，不是单纯追求最高命中率或最低账单。
二、建立可归属的成本账本
每个 Key 前缀应有业务 owner、环境、数据级别和预算。采集实际内存而非 value 原始长度，同时记录 QPS、命中、TTL、网络字节和回源平均成本。共享集群按使用量分摊，才能让业务看见自己的设计代价。
| 指标 | 用途 | 常见问题 |
|---|---|---|
| actual memory by namespace | 识别占用大户 | 小对象元数据被忽略 |
| hit/miss QPS | 判断使用价值 | 高命中但请求极少 |
| bytes in/out | 识别大 value 成本 | QPS 低但带宽高 |
| TTL 分布 | 发现永久或过长缓存 | 默认无过期 |
| DB cost per miss | 衡量缓存收益 | 所有 miss 被当成同成本 |
| replica/persistence cost | 核算可靠性成本 | 只看主节点内存 |
无 owner 的 Key 应先告警和冻结新增，再按观察期清理，不能立即批量删除。
三、命中率的百分点为什么会误导
假设入口 10 万 QPS，命中率 99% 时数据库承受 1000 QPS；降至 98% 后数据库变为 2000 QPS，虽然命中率只降 1 个百分点，回源却翻倍。评估 TTL 缩短和缩容时必须看 miss 的相对增幅。
不同 miss 成本也不同。用户昵称查询可能单行主键读取，复杂商品页需要联表与远程调用；用统一命中率评价会鼓励缓存廉价数据，挤掉真正昂贵的数据。可以计算“加权命中节省”：
saved_cost = Σ(hit_count_i × origin_cost_i)
cost_efficiency = saved_cost / cache_memory_cost这不是要求精确财务模型，而是帮助排序治理优先级。
四、从数据模型减少内存
常见浪费是把完整数据库对象或重复字段序列化到每个 Key。应按访问模式只缓存需要字段，共享大文本放独立 Key/对象存储，避免在列表每一项复制；选择紧凑序列化，并注意压缩会增加 CPU。
小对象可以适度聚合，减少每个 Key 的元数据开销，但聚合过大又会产生 Big Key 和写放大。需要通过 MEMORY USAGE 与实际命令压测寻找平衡，而不是仅比较 JSON 字节数。
假设 5000 万个 Key 每个减少 40B 元数据/字段，能节省约 2GB；若每个 value 从 2KB 精简到 1.2KB，则节省约 40GB，优化业务载荷通常比调 allocator 更有效。
五、TTL 与淘汰要按价值分层
TTL 应由更新频率、允许陈旧时间、回源成本和访问概率决定。热点且加载昂贵的数据可用较长 TTL 加主动失效；低频、易加载数据缩短 TTL；不存在结果使用短负缓存；不能永久缓存只因“以后也许会用”。
| 数据 | TTL 思路 | 补充机制 |
|---|---|---|
| 热点商品基础信息 | 较长 + 抖动 | 变更主动删、后台刷新 |
| 实时库存展示 | 短 TTL | 下单权威校验 |
| 搜索空结果 | 短负缓存 | 参数校验/布隆过滤器 |
| 冷门详情 | 按需短缓存 | 淘汰后直接回源 |
| 权限信息 | 按安全窗口 | 撤权事件与版本校验 |
淘汰策略应保护高价值热点，但不能代替容量治理。持续 evict 意味工作集超过安全容量或 TTL/数据模型有问题。
六、可靠性成本不能盲目削减
副本、跨区部署和内存余量看似“闲置”，实际购买的是故障接管能力。把一主一从改成单节点可省近一半资源，却会显著提高故障恢复时间和数据丢失/回源风险。应先优化数据，再根据业务等级决定副本。
非核心可重建缓存可使用较低等级集群或无持久化，核心协调数据不应与普通缓存混用。冷热业务分池能避免高可靠配置被所有 Key 继承，但池越多运维成本越高。
正常内存水位也不能追求 100%。需给碎片、复制缓冲、fork COW、故障迁移和增长留空间；节省后的装箱率必须经过故障演练。
七、灰度验证和持续治理
任何 TTL 缩短、压缩、淘汰或缩容先按命名空间/租户灰度。观察缓存命中、CPU、网络、P99、eviction、数据库 QPS/连接和总体成本。压缩 value 若节省 30% 网络却让 CPU 翻倍，可能并不划算。
建立定期报告：无访问 Key、无 TTL Key、Top 内存前缀、低收益缓存、Big/Hot Key、预算超标和 owner 缺失。清理动作带变更记录和回滚，防止误删重要数据造成雪崩。
namespace: product-detail
memory_gb: 120
hit_rate: 98.5%
origin_qps_saved: 82000
monthly_cost: 6400
estimated_db_cost_avoided: 18400
owner: product-platform八、常见误区与追问
- 误区：降低命中率 1% 影响很小。 当 miss 基数很低时，回源流量可能翻倍。
- 误区：删副本是最快且合理的降本方式。 它直接减少故障能力，应先治理数据与低收益缓存。
- 误区：压缩率越高越好。 压缩会增加 CPU 和延迟，小 value 可能得不偿失。
- 误区：设置淘汰策略就无需容量治理。 持续淘汰会造成命中抖动和数据库压力，说明工作集不匹配。
- 追问：如何识别无价值缓存？ 同时看内存、请求量、加权命中收益、回源成本和业务风险，不能只看命中率。
- 追问：为什么要给 Key 设置 owner？ 没有责任人就无法确认数据语义、清理风险和预算，孤儿缓存会长期增长。
- 追问：多级缓存会不会重复浪费？ 会，应让各层承担不同热度与生命周期，限制本地层大小而非复制全量。
九、加强记忆
按“算账、归属、瘦身、分 TTL、保可靠、灰度验”控制缓存成本。先知道谁用了多少资源、避免了多少回源工作；优先清孤儿和冗余字段、优化 value 与生命周期；副本和故障余量最后再按等级调整。任何降本都要用数据库压力和端到端 SLO 验证，不能把缓存账单转成更大的数据库事故。