技术和基础架构→ Kesh层和数据存储

Kesh层和数据存储

1）为什么需要多层kesh

Kesh是无需访问"昂贵"子系统（DB，外部API，网络）即可响应的捷径。多层分配负载：浏览器→ CDN/ed → ge应用层→分布式kesh → DB/存储。目标：降低P95/P99，卸载起源，更强大地承受峰值并降低字节成本。

2） kesha水平图

1.Браузер: `Cache-Control`, `ETag`, `Last-Modified`, `stale-while-revalidate`.

2.CDN/Edge: TTL/ключ, Vary, Signed URLs, image-resize;tiered/shield.

3.Gateway/Service Mesh API：关于安全GET的简短回程。
4.应用程序（in-process）： LRU/LFU,用于热键的近程缓存,毫秒。
5.分布式kesh （Redis/Memcached）：用于扬声器的主层。

6.缓存DB： Pg/Innodb缓冲区,PgBouncer multiplexing, materialized views.

7.磁盘/对象堆栈：precomputed snapshots, blob-kesh（例如S3+CDN）。

原则： "与用户的距离越近-TTL越短，个性化就越少；数据越接近-一致性策略越丰富。"

3）腰带模式

Cache-Aside （Lazy）：我们从MISS上读到来自源头的货物→储存在kesh中的→。普罗斯特，给TTL控制。
Read-Through：应用程序通过kesh读取，kesh本身是从源头拉出的。集中策略很方便。
Write-Through：记录立即进入kesh和源。更一致，但条目更昂贵。
Write-Back （Write-Behind）：写入kesh,源以异步方式更新（队列）。速度快，需要交货保证和等效性。
Refresh-Ahead：在"顶级"密钥中，我们在TTL到期之前更新值。

其中：游戏卡/目录-cache-aside/read-through；计数器/排行榜-写回+CRDT/聚合；货币/限额手册-通过受控的TTL阅读。

4）密钥、分割和神经识别

Шаблон: `domain:entity:{id}:v{schema}|region={R}|currency={C}|lang={L}`.

仅将真正改变答案（区域，货币，语言，方案版本）的内容包含在密钥中。
电路转化：如果发生不兼容的变化，则在键中提高"vN"，从而避免大规模购买。
按产品/tenant进行命名：'tenant： {t}：'-对于多重类型至关重要。
"密钥存在"的Bloom过滤器可以减少对源的访问。

5）TTL，新鲜和残疾

• 静态（哈希文件）：30-365天+"immutable"；
• 目录/横幅：5-60分钟+"stale-wile-revalidate"；
• 领导层/报价：2-15秒；
• 目录（货币/限额）：1-10分钟。
• 事件致残：发布"产品"。updated '→禁用点键/前缀。
• 基于标签的垃圾桶：按标签分组清除（促销/目录版本）。
• Soft-Expiry： TTL到期后,我们以"stale"的形式放弃过时的版本,并行更新（SWR/SIE）。
• Versioned Keys> mass purge：更便宜、更安全。

6）Stampede，"热门"钥匙和竞争

• 单次飞行（request coalescing）：一个领导者更新密钥,其他领导者等待。
• TTL挤压：模煳到期，避免一次性崩溃。
• 本地SWR：我们给用户一个过期的值，我们更新背景。
• Hot Keys:

将热键复制到多个通过阅读分布的"key#1..N"插槽；

过程内存中的近轴缓存；

预告片/refresh-ahead在高峰（比赛/比赛）之前。
重键的升级协变限制。

7）一致性和交叉层

Write-invalidate：写入源时-同步禁用相应的密钥（pub/sub）。
读取修复：如果出现差异,请更新正确值的Kesh。
Eventual vs Strong：直接阅读/短期TTL的关键现金交易；UI展示和统计-事件。
CRDT/聚合器：对于分布式计数器/评级-"merge-safe"结构（G-Counter，线程上的Top-K）。
级联残疾："游戏"更新使卡+清单+定制推荐缓存残疾。

8）序列化、压缩和格式

格式：protobuf/MessagePack比JSON快；CDN/浏览器-带有Brotli的JSON。
在Redis中压缩：对对象>1-2 KB有利,但要注意CPU。
按需部分响应/字段：少字节→少于TTFB和RAM。

9）驱逐政策和规模

LRU（默认）-安全；LFU更适合"流行"内容。
按键/值大小：保持控制（"avg value size","max"指标）。
namespace/tenant配额，以免单个产品被"吃掉"整个kesh。

10）安全和PII/PCI

个人/财务数据-不要在CDN/edge上和共享层中打结；使用令牌/投影。
通过client-side crypto在Redis中加密敏感值（注意TTL控制丢失）。
严格的ACL和网络隔离；固定的NAT/IP，用于向提供商发送信息。

11）kesha的可观察性和SLO

• Hit Ratio（按图层和前缀）、Origin Offload。
• TTFB/P95/P99 kesh之前/之后，Latency Redis。
• Evictions, OOM, keyspace hits/misses.
• Stampede rate（并行更新比例）,refresh时间。
• Stale served % и Freshness lag.

• 游戏目录：Hit Ratio ≥ 85%，TTFB P95 ≤ 150毫秒（边缘）。
• API参考：Revalidation-hit ≥ 60%, P95 ≤ 200毫秒。
• Redis：P99手术≤ 5毫秒，每小时不超过1%。

12）FinOps： 腰果成本

$/GB月RAM vs $/RPS起源：计算回报点。
Offload and egress： CDN+Redis减少了来自区域起源的出站流量。
Image/WebP/AVIF和非规范化可以节省最多的字节。
限制"昂贵的MISS"：分析"字节× MISS ×地区"。

13）示例（片段）

13.1 Cache-Aside with single-flight（伪代码）

python def get(key, ttl, loader):
val = redis. get(key)
if val: return val with single_flight (key): # only one updates val = redis. get (key) # double check if val: return val data = loader () # request to source redis. setex(key, ttl_with_jitter(ttl), serialize(data))
return data

13.2根据事件发布残疾

json
{
"event": "game. updated",
"game_id": "g123",
"affected": ["catalog:list:region=TR", "game:card:g123:"]
}

Consumer签署了该频道，并使"DEL"/"PUBLISH"与密钥/标签匹配。

13.3键与电路版本和位置

game:card:v2:id=g123    region=BR    currency=BRL    lang=pt-BR

14）实施支票

1.Kesha和TTL矩阵级别映射（静态/半静态/API）。

2.密钥： 域,方桉版本,地方/地区/货币,tenant.

3.选择per-endpoint模式（aside/read-through/write-through/back）。
4.SWR/SIE，单次飞行和TTL推杆对阵踩踏。
5.事件障碍（pub/sub），团体标签。
6.在峰会之前为"热线"密钥和prewarm提供近距离缓存。
7.格式和压缩（protobuf/MsgPack，Brotli），尺寸控制。
8.LRU/LFU政策，namespace/tenant配额。

9.SLO/метрики: hit ratio, latency, evictions, stale %, freshness lag.

10.安全性：个人化、令牌化、网络/ACL无商店。

15）反模式

"no-cache""以防万一"，TTL的豁免为零。
关键包括所有查询/标题→基数爆炸。
每次发行时"整个CDN/Redis"的质量冲浪。
缺乏抗踩踏防护和"顶级钥匙"一次性到期。
没有配额/隔离的统一共享Redis；"热"tenant吞噬了整个kesh。
对edge/CDN进行个人响应。
没有新鲜遥测/进度→盲目控制。

16） iGaming/fintech上下文： 实用音符

排行榜/排名：TTL 2-10 s，aggregate流+CRDT，SWR发生故障。
游戏/横幅目录：CDN+Redis；关键：区域/货币/语言；根据"promo： update"标签进行残疾。
支付状态：写入路径上没有缓存；阅读-简短的TTL （≤3 -5 c）或直接查询。
KYC/AML回应：取消非PII衍生工具（状态）,不要将图像/文档存储在Redis中。
VIP路径：单独的namespace/Redis池,优先服务。

底线

强大的kesh策略是层级体系结构，正确的更新模式，经过深思熟虑的TTL/残疾，抗踩踏性，整洁的键和版本以及可观察性和FinOps。按照这些原则，您将稳定P95/P99尾巴，减少源头负荷并获得可预测的毫秒成本-这对于产品和业务来说是最重要的。