积压策略

1）为什么要结结，在哪里做

• 速度（p95/p99）、成本（少于egress/CPU）、稳定性（少于峰值下的依赖）。
• 平滑峰并与"嘈杂的邻居"隔离。

1.客户端（浏览器/移动）-HTTP kesh, IndexedDB,本地存储。

2.Edge/CDN-POP节点更接近用户,缓存静态和API的一部分。

3.L7网关/逆向-Nginx/Envoy/Varnish（微网，SWR）。

4.服务缓存-群集内的Redis/Memcached。

5.进程内-内存（Caffeine/Guava/LRU-map）。

6.DB中的缓存是材料表示，次要索引。

规则：尽可能接近消费者，但保留真相一次。

2）腰带模式

2.1 Cache-aside (“lazy loading”)

应用程序首先从缓存中读取；错过时-从源中,然后写入缓存。
优点：简单,控制。缺点：寒冷的开始，争吵的窗口。

2.2 Read-through

读取总是通过高速缓存,该高速缓存本身会在错误时到达源（库/伸缩层）。
集中TTL/灰化策略非常方便。

2.3 Write-through / Write-back (write-behind)

写入：写入缓存和源同步→一致性更高,潜伏性更高。
写回：写入缓存,异步闪存写入源→快,但损失和冲突的风险。

2.4 Refresh-ahead (proactive)

预测"TTL即将到期"，并在背景中更新钥匙，防止踩踏。

2.5 Negative caching

在短的TTL上散列"无数据/404/空白"可减少源负载。

2.6 Micro-caching

非常短的TTL（0。5-5 c）在L7上"接近扬声器"（列表，主要）-显着降低尾巴。

3） HTTP-kesh： 标题和控制

3.1基本标题

`Cache-Control`: `max-age`, `s-maxage` (для shared кэшей), `public/private`, `no-store`, `stale-while-revalidate`, `stale-if-error`.

验证者："ETag"（内容哈希），"Last-Modified"。
条件查询："If-None-Match"、"If-Modified-Since" → 304 Not Modified。

3.2 Vary和钥匙

"Vary：Accept-Encoding，授权，Cookie，Accept-Language"-形成不同的缓存选项。尽量减少"Vary"以免被"炸毁"基数。

3.3 HTTP响应示例

Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=60
ETag: "a1b2c3"
Vary: Accept-Encoding

4）密钥设计和TTL

4.1个钥匙

构造："tenant： user： {id}：profile： v3"（包括架构版本）。
避免使用PII。
对于集合-键+查询参数（归一化和排序）。

4.2 TTL和一致性

短的TTL减少了争执，但增加了失误。
对于关键数据-验证器（"ETag"）和SWR（stale-wile-revalidate）。
对于很少改变的人来说，长期TTL+"炸弹"致残。

4.3转化/罢工

如果更改不兼容,请更改密钥前缀/版本（"v2 → v3"）。
对于静态资源,文件名中的content hash。

5）残疾： 战略和做法

5.1直接删除

代理上的"DEL key"/"PURGE"。危险：删除和多读者之间的种族。

5.2个Tagi/Surrogate键

将文档与标签集（类别/作者）关联。残疾-按标签。

В Varnish/Edge — `Surrogate-Key: article:42 tag:author:7` + `BAN tag:author:7`.

5.3事件驱动残疾

Pub/Sub （Kafka/NATS）：更改源时,我们发布"入侵"事件。
缓存用户收听并删除/更新密钥。

5.4双相

首先，通过标记已过时的密钥（soft TTL），我们为stale服务，我们更新背景并用原子替换。

6）对抗stampede/dogpile和热键

6.1 Request coalescing (singleflight)

一个制作人更新密钥，其余的则等待结果（mutex/标签"更新"）。

6.2 Jitter к TTL

在TTL中添加随机性（± 10-20%）,以避免同步擦伤。

6.3 Soft-TTL + hard-TTL

从缓存到软式TTL，与触发缓存平行；根据hard-TTL-我们认为是错误的。

6.4热键

本地缓存高于一般缓存（二级）。
将热键复制到多个硬盘和随机选择（仅读取）。
更新特定密钥的限额。

6.5 Redis+Lua示例（单机草图）

lua
-- SETNX lock with TTL to avoid deadlocks local ok = redis. call("SET", KEYS[1], "1", "NX", "EX", ARGV[1])
if ok then return "LOCKED"
else return "WAIT"
end

7）置换策略和接受缓存

7.1 Eviction

LRU：简单且适合本地化。
LFU：在"长寿"热键下更好。
ARC/TinyLFU：回收/频率平衡。

7.2 Admission（进口）

不要让巨型稀有物体（TinyLFU/Bloom过滤器）。
在"大小/潜伏"边界上压缩大值（LZ4/Zstd）。

8）硬化和拓扑

8.1 Consistent hashing

稳定地将密钥分布在指节上，减少群集生长/压缩时的移动。

8.2 Redis/Memcached拓扑

Redis Cluster （插槽/shards）, Sentinel （failover）, read-only复制。
Memcached是客户端侧面的sharding（ketama hashing），没有服务器级复制。

8.3本地+分布

级联：proc（微型TTL/LRU）→ Redis（TTL更长）→源。
小心TTL冒号和缓存验证器。

9） Edge、CDN和L7-kesh

9.1 Micro-cache на Nginx

nginx proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api:100m inactive=10m;
map $request_method $skip_cache { default 0; POST 1; PUT 1; DELETE 1; }

server {
location /api/list {
if ($skip_cache) { add_header Cache-Control "no-store"; }
proxy_cache api;
proxy_cache_valid 200 2s;       # micro-cache proxy_cache_use_stale error timeout updating;
proxy_cache_background_update on;   # SWR add_header X-Cache $upstream_cache_status;
proxy_pass http://upstream;
}
}

9.2 Envoy （SWR和条件）

yaml http_filters:
- name: envoy. filters. http. cache typed_config:
"@type": type. googleapis. com/envoy. extensions. filters. http. cache. v3. CacheConfig typed_config:
"@type": type. googleapis. com/envoy. extensions. http. cache. file_system_http_cache. v3. FileSystemHttpCacheConfig cache_path: "/var/cache/envoy"

9.3 Varnish (Surrogate keys)

按标签使用"Surrogate-Key"和"ban"进行批处理残疾。

10） Kesh和数据一致性

10.1 Read-your-writes

对于自定义配置文件/购物车,请提供短的TTL或通过缓存写入（write-through）或客户端标记（写入后N秒的旁路）。

10.2 Eventual vs Strong

对于推荐/分析-eventual+长的TTL。
对于金钱/订单状态-短TTL，验证，有时在关键路径上没有缓存。

10.3不变量

在没有严格的TTL和重新检查的情况下,不要取消影响安全/ACL的字段。

11）可观察性，SLO和控制

11.1个指标

hit_ratio (общий и per-route), byte_hit_ratio, miss_rate.

stampede_prevented_total, refresh_ahead_total, ban/purge_total.

潜伏期：来自缓存的p50/p95/p99来自源。
hot_keys_topN和QPS/字节。

11.2个日志和跟踪

编写"X-Cache： HIT/MISS/STALE/UPDATING"。
在预告片中，标记响应源（"cache=true"，"tier=edge"服务"local"）。

11.3 SLO方法

示例："对于API/catalog p99 ≤ 250毫秒，cache命中≥ 85％，stampede ≤ 0。1%的查询"。

11.4 Runbooks

"失误增加"→检查TTL，加热/残疾，热键，缓存大小和接受策略。

12）安全性和多重性

将tenant-id嵌入键中（以及HTTP下的"Vary"中）。
不要将私人回应称为"公共"。
使用敏感数据加密缓存或仅存储非PII/ID。

13）典型食谱

13.1目录/磁带（接近扬声器）

Edge-Microcash 1-3 with+SWR, Inside-Redis on 15-60 s,残疾升级事件。

13.2用户配置文件

Cache-aside with TTL 30-120 s, bypass 5-10 with profile update （cookie/header） or write-through。

13.3文凭课程/参考书

长的TTL（分钟-小时）+发布新数据时的目标残疾；条件性GET的"ETag"。

13.4搜索引证

Edge-Microcesh 1-2，内部为refresh-ahead和coalescing，将密钥中的查询参数标准化。

14）反模式

无障碍缓存：只有TTL的希望→无关紧要的长窗口。
巨型"Vary"：变种的"爆炸"→低命中率。
prod/experiments的单一缓存→污染。
TTL到期时，源头上没有阻塞→峰保护。
现金/权利/ACL缓存没有严格的保证。
"全部连续"压缩是额外的CPU，小型设施的p99恶化。

15）实施支票

• 确定腰果水平及其目标（edge/service/local）。
• 设计按键（转换,tenant,参数标准化）。
• 选择模式（cache-aside/read-through/refresh-ahead）。
• 配置TTL/soft-TTL/jitter,启用SWR。
• 实现coalescing/singleflight, stampede保护。
• 组织残疾（事件,标签,purge/ban）。
• 输入"X-Cache"的hit-ratio/latency和dashbords度量。
• 使用热键进行负载测试。
• 请参考SLO和runbooks。
• 检查安全/tenant隔离和"Vary"。

16) FAQ

Q： 选择什么-cache-aside或read-through?

A：对于简单的服务-cache-aside。需要集中化和统一的政策-阅读。

Q： 如何理解最佳TTL?

答：从允许的过时性，更新的频率和目标命中率出发；添加jitter并观察p95/p99/成本。

Q： write-back何时合适?

答：对于高负载流，可以接受事件一致性，并且存在"附加值"的可靠队列/日志。

Q：授权答案可以取消吗？
答：是的，但标记"私人"和/或将tenant/用户包含在/"Vary"键中。对于truly-private-客户端缓存。

Q： 如何加热缓存?

A：流行键列表,背景蠕虫,爬行动物从日志,发布/高峰前加热（黑色星期五等）。

17）结果

有效的悬挂是按键设计+合理的TTL+精心选择的模式，并通过事件残疾，SWR/refresh-ahead和抗踩踏保护来增强。分层缓存（客户端/边缘/服务）,添加可观察性和SLO-并获得稳定的潜伏尾巴、可预测的成本和对峰值负载的抵抗力。