亿级分布式缓存架构
在面向亿级访问量的系统中，构建多级分布式缓存架构，是保障高并发响应的关键。
多数大厂会采用“本地缓存 L1 + 分布式缓存 L2/L3 + 持久层 DB/搜索”的多级缓存体系。
请求入口 ↓ 【L1 本地缓存】（JVM / Caffeine） ↓ 【L2 分布式缓存】（Redis Cluster） ↓ 【L3 远端缓存 / 二级存储】（Redis + SSD / KV） ↓ 数据库 / 搜索 / 文件存储
L1 本地缓存
首先，本地缓存位于应用进程或机器内存。
命中时能将响应延迟压缩到毫秒级甚至亚毫秒级，适用于极高频次的读场景。
其劣势是容量受限且存在数据孤岛问题，因此通常承担短时或线程/进程级的缓存职责。
并采用失效、LRU 等策略控制内存占用。
常见的技术包含：JVM 内存、Caffeine/Guava 等。
特点：访问最快（无需网络）、适合存放最热点的小数据集，提升 P99 延迟表现。
问题：容量有限、分布在每个实例上，天然是多副本，需要处理数据一致性和污染问题。
L2/L3 分布式缓存
其次，分布式缓存（如 Redis、Memcached、基于一致性哈希的自研缓存）。
提供节点间的数据共享与容错能力，成为 L1 与后端持久层之间的中间层。
通过水平扩展与主从、集群复制机制。
分布式缓存既提升了缓存容量与可用性，也承担了流量削峰的核心功能。
多级之中，L2 通常是“热数据集群”，L3 可以是“冷数据/大 Value 集群”或跨机房/跨地域缓存层。
持久层（DB / 搜索 / 对象存储）
最后，持久层（关系型/非关系型数据库、搜索引擎）。
保存全量与强一致的数据，负责复杂查询、事务与长期归档。
缓存无法替代其一致性与可靠性保障，因此当缓存未命中或需回源验证时，系统必须回落到持久层。
主要负责写入和复杂查询，尽量通过高缓存命中率降低直连访问频率，避免在流量高峰期成为瓶颈。
常见是 MySQL 分库分表 + ES/HBase/OLAP 之类的组合。
mikechen睿哥
10年+一线大厂架构实战经验，操盘多个亿级大厂核心项目，就职于阿里、淘宝等一线大厂。