delorex/test-repo
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
bb28f010e359982f2f8114acb3c7b825c04af90e
test-repo/docs/zh-cn/appendix/cache-design.md
T

834 lines
27 KiB
Markdown
Raw Normal View History

feat: update docs and components, fix DLQ demo bug
2026-01-18 12:21:49 +08:00
# 系统缓存设计：从原理到实战 (Interactive Guide to Caching)
> 💡 **学习指南**：本章节带你深入理解后端系统的"加速器"——缓存。我们将从最基础的"为什么要缓存"讲起，一步步掌握多级缓存架构、缓存模式、以及实战中的坑与解决方案。
<CacheArchitectureDemo />
## 0. 引言：看不见的"加速器"
你刷朋友圈时，为什么几秒钟就能加载出几百张图片？
你查询订单时，为什么瞬间就能看到几个月前的数据？
这背后都有一个功臣：**缓存 (Cache)**。
如果数据库是"仓库"，那缓存就是"柜台"。
常用的商品（热数据）放在柜台上，随拿随用；不常用的商品才需要去仓库里找。
### 0.1 为什么要缓存？
只有一个理由：**快**。
| 存储介质 | 访问延迟 | 吞吐量 | 典型用途 |
| :--------------- | :------- | :----- | :------------- |
| **L1 CPU 缓存** | ~1 ns | 极高 | 寄存器、变量 |
| **内存 (Redis)** | ~100 ns | 高 | 热点数据、会话 |
| **SSD 数据库** | ~1 ms | 中 | 持久化存储 |
| **HDD 数据库** | ~10 ms | 低 | 归档存储 |
**关键点**：缓存的本质是**用空间换时间**，通过在更快的存储介质中保留数据副本，减少访问慢速存储的次数。
---
## 1. 第一步：理解缓存的本质
### 1.1 局部性原理 (Locality Principle)
缓存之所以有效，是因为两个神奇的观察：
1. **时间局部性 (Temporal Locality)**：
- 如果你现在访问了某个数据，未来很可能**再次访问它**。
- _例子_：一个用户登录后，接下来几分钟的每次请求都需要查询他的用户信息。
2. **空间局部ity (Spatial Locality)**：
- 如果你访问了某个数据，很可能**访问它附近的数据**。
- _例子_：浏览商品列表时，通常会翻到下一页（相邻的商品）。
<LocalityPrincipleDemo />
### 1.2 缓存的生命周期
一个缓存条目（Cache Entry）的一生：
1. **写入 (Write)**：首次访问数据时，从数据库读取并存入缓存。
2. **命中 (Hit)**：后续访问直接从缓存返回（快！）。
3. **过期 (Expiration)**：超过设定时间（TTL），标记为过期。
4. **淘汰 (Eviction)**：缓存满了，需要腾空间给新数据。
<CacheLifecycleDemo />
**关键点**：好的缓存设计需要平衡**命中率**（Hit Ratio）和**内存占用**。
---
## 2. 单机缓存 vs 分布式缓存
### 2.1 本地缓存 (Local Cache)
缓存和应用在同一个进程里。
- **优点**：
- 极快（没有网络开销）。
- 简单（就是一个 Map/Dictionary）。
- **缺点**：
- 容量有限（受限于单机内存）。
- 不一致（每个实例的缓存独立）。
- **典型实现**：
- Java: Caffeine、Guava Cache
- Go: bigcache、ristretto
- Python: functools.lru_cache
```java
// Java Caffeine 示例
Cache<String, User> userCache = Caffeine.newBuilder()
.maximumSize(10_000) // 最多存 1 万条
.expireAfterWrite(10, TimeUnit.MINUTES) // 10 分钟过期
.build();
// 使用
User user = userCache.get(userId, key -> {
// 缓存没命中，从数据库查
return database.getUserById(key);
});
```
### 2.2 分布式缓存 (Distributed Cache)
缓存是一个独立的服务，应用通过网络访问。
- **优点**：
- 容量巨大（可以集群扩展）。
- 一致性好（所有实例共享同一份缓存）。
- **缺点**：
- 有网络延迟（通常 1-5 ms）。
- 需要额外维护缓存服务。
- **典型实现**：**Redis**、Memcached
```python
# Python + Redis 示例
import redis
r = redis.Redis(host='localhost', port=6379)
def get_user(user_id):
# 先查缓存
cached = r.get(f'user:{user_id}')
if cached:
return json.loads(cached)
# 缓存未命中，查数据库
user = db.query(f'SELECT * FROM users WHERE id = {user_id}')
# 写入缓存，过期时间 10 分钟
r.setex(f'user:{user_id}', 600, json.dumps(user))
return user
```
<LocalVsDistributedCacheDemo />
**关键点**：现代系统通常**组合使用**——本地缓存做第一道防线，分布式缓存做第二道防线。
---
## 3. 多级缓存架构 (Multi-Level Caching)
真实的系统通常是"多层防御"：
```
用户请求
↓
浏览器缓存 (Cache-Control)
↓ (未命中)
CDN 缓存 (静态资源)
↓ (未命中)
负载均衡器
↓
应用服务器 (本地缓存: Caffeine)
↓ (未命中)
分布式缓存 (Redis)
↓ (未命中)
数据库 (MySQL / PostgreSQL)
```
### 3.1 每一层的特点
| 层级 | 存储介质 | 典型容量 | 响应时间 | 适用场景 |
| :------------- | :--------- | :------- | :------- | :------------------------- |
| **浏览器缓存** | 用户磁盘 | ~100 MB | ~0 ms | 静态资源（图片、CSS、JS） |
| **CDN 缓存** | 边缘节点 | TB 级 | ~10 ms | 静态文件、API 响应 |
| **本地缓存** | 应用内存 | ~1 GB | ~1 ms | 极热点数据（配置、白名单） |
| **Redis 缓存** | Redis 集群 | ~100 GB | ~5 ms | 热点数据（用户信息、商品） |
| **数据库** | SSD/HDD | TB ~ PB | ~50 ms | 持久化存储 |
<MultiLevelCacheDemo />
**关键点**：每一层都是上一层的"保护伞"，逐级过滤请求，最终打到数据库的流量可能只有原来的 **1%**。
---
## 4. 缓存模式 (Caching Patterns)
### 4.0 为什么需要缓存模式？
**问题场景**：
当有大量请求访问内部系统时，如果每个请求都需要操作数据库（例如查询操作），对于那种基本不变化的数据来说，每次都去数据库查询会极大地消耗性能。
尤其是在海量数据操作时，如果都从 DB 加载，这是在挑战用户的耐性。
**生活中的例子**：
想象你要去小区里了解某个人在不在家。当没有通讯工具时：
- **没有缓存**：每次都要经过小区保安，再到具体单元楼，最终到这家门口，才知道在不在家。
- **有缓存**：如果换一个优秀的保安，他知道当前小区特定的家里是否有人，直接问保安就知道了，无需跑冤枉路。
这个"优秀保安"就是**缓存**。每次访问时先访问缓存，就能极大提高访问效率和系统性能。
### 4.1 Cache-Aside (旁路缓存) ⭐ 最常用
最常用的模式，由**应用代码**直接控制缓存。
#### 读取流程
```
1. 应用读取缓存
↓ 命中？
├─ 是 → 直接返回数据
└─ 否 → 读取数据库
↓
将数据写入缓存
↓
返回数据
```
**代码示例**：
```python
def get_user(user_id):
# 1. 先查缓存
cached = cache.get(f'user:{user_id}')
if cached:
return cached
# 2. 缓存未命中，查数据库
user = db.query(f'SELECT * FROM users WHERE id = {user_id}')
# 3. 将数据写入缓存
if user:
cache.set(f'user:{user_id}', user, ttl=600)
return user
```
#### 更新流程
```
1. 应用更新数据库
↓
2. 删除缓存（不是更新！）
```
**代码示例**：
```python
def update_user(user_id, new_data):
# 1. 更新数据库
db.execute('UPDATE users SET ... WHERE id = ?', user_id)
# 2. 删除缓存（而不是更新）
cache.delete(f'user:{user_id}')
# 为什么删除而不是更新？
# 因为并发更新时，更新缓存的顺序可能和数据库不一致！
```
**关键点**：
- ✅ **删除而非更新**：避免并发写入导致缓存和数据库不一致
- ✅ **延迟双删**：为了极致一致性，可以在更新前再删一次
- ✅ **最灵活**：应用代码完全控制缓存逻辑
**常见问题：会不会有脏数据？**
场景：一个查询操作发现缓存没数据，准备去查 DB。此时另一个写操作更新了 DB 并删除了缓存，第一个操作从 DB 拿到的还是老数据并写入缓存。
**解答**：这种情况出现的概率极低！
- 写操作需要锁表
- 数据库写入比读取慢
- 同等条件下，查询操作先返回，写操作再返回
### 4.2 Read-Through (读穿透)
由**缓存服务**负责与数据库交互，应用代码只和缓存打交道。
#### 工作原理
```
应用请求 → 缓存服务
↓
缓存命中？
├─ 是 → 直接返回
└─ 否 → 缓存服务自己加载 DB 数据
↓
更新缓存
↓
返回数据
```
**代码示例**：
```python
# 应用代码只需要
user = cache.get(user_id) # 缓存库自动处理数据库查询
# 不需要手写：
# if not cached:
# user = db.query(...)
# cache.set(user_id, user)
```
**对比 Cache-Aside**：
| 特性 | Cache-Aside | Read-Through |
| :------------- | :--------------- | :----------------------- |
| **谁负责加载** | 应用代码 | 缓存服务 |
| **代码复杂度** | 需要手写缓存逻辑 | 简洁，只需调用 get |
| **灵活性** | 高（完全控制） | 低（依赖缓存库实现） |
| **适用场景** | 通用场景 | 读多写少，缓存逻辑标准化 |
**优点**：
- 代码简洁，缓存逻辑对业务透明
- 统一的缓存加载策略
**缺点**：
- 灵活性差，缓存库和数据库强绑定
- 需要特殊的缓存库支持
### 4.3 Write-Through (写穿透)
更新时**同时**写缓存和数据库，由缓存服务负责同步。
#### 工作原理
```
应用写请求 → 缓存服务
↓
更新缓存
↓
同步更新数据库
↓
返回成功
```
**代码示例**：
```python
# 应用代码只需要
cache.set(user_id, user) # 缓存库自动同步到数据库
# 不需要手写：
# db.update(user)
# cache.set(user_id, user)
```
**关键点**：
- 缓存和数据库**同步更新**，强一致性
- 写入性能受数据库影响（相对较慢）
**对比 Cache-Aside**：
| 特性 | Cache-Aside | Write-Through |
| :----------- | :----------------- | :-------------- |
| **写操作** | 先写 DB，再删缓存 | 同时写缓存和 DB |
| **一致性** | 最终一致 | 强一致 |
| **写入性能** | 高（异步删缓存） | 低（同步写 DB） |
| **缓存更新** | 懒加载（读时更新） | 主动更新 |
**优点**：
- 数据一致性最好
- 读取时总能命中缓存
**缺点**：
- 写入延迟高
- 需要特殊的缓存库支持
### 4.4 Write-Behind (异步写回) ⚡ 最快
更新时**只写缓存**，缓存服务异步批量更新数据库。
#### 工作原理
```
应用写请求 → 缓存服务
↓
更新缓存（立即返回）
↓
⚡ 异步批量写数据库（后台进行）
```
**代码示例**：
```python
# 应用代码只需要
cache.set(user_id, user) # 立即返回，不等待数据库
# 缓存服务会在后台批量写入：
# while True:
# batch = cache.get_dirty_entries()
# db.batch_update(batch)
```
**性能对比**：
| 模式 | 写入延迟 | 吞吐量 | 数据一致性 |
| :---------------- | :------- | :----------- | :--------- |
| **直接写 DB** | ~50 ms | ~1000 QPS | 强一致 |
| **Write-Through** | ~50 ms | ~1000 QPS | 强一致 |
| **Cache-Aside** | ~50 ms | ~1000 QPS | 最终一致 |
| **Write-Behind** | ~1 ms | ~100,000 QPS | 可能丢失 |
**优点**：
- ✅ 写入极快（毫秒级响应）
- ✅ 吞吐量极高（十万级 QPS）
- ✅ 减少数据库 IO（批量写入）
**缺点**：
- ❌ 数据可能丢失（缓存崩了，数据就没了）
- ❌ 缓存和数据库不一致（异步延迟）
**适用场景**：
- ✅ 秒杀系统（库存扣减）
- ✅ 点赞数、浏览量（可接受少量丢失）
- ✅ 计数器、统计信息
- ❌ 订单、支付（绝对不能丢）
### 4.5 四种模式对比总结
| 模式 | 谁控制缓存 | 读取策略 | 写入策略 | 一致性 | 性能 | 使用频率 |
| :---------------- | :--------- | :------- | :------------------ | :------- | :--- | :---------------- |
| **Cache-Aside** | 应用代码 | 懒加载 | 先写 DB，删缓存 | 最终一致 | 中 | ⭐⭐⭐⭐⭐ 最常用 |
| **Read-Through** | 缓存服务 | 自动加载 | 先写 DB，删缓存 | 最终一致 | 中 | ⭐⭐ |
| **Write-Through** | 缓存服务 | 自动加载 | 同时写缓存和 DB | 强一致 | 低 | ⭐⭐ |
| **Write-Behind** | 缓存服务 | 自动加载 | 只写缓存，异步写 DB | 可能丢失 | 极高 | ⭐⭐⭐ |
**选择建议**：
- **大多数场景**：使用 **Cache-Aside**，灵活且成熟
- **读多写少**：考虑 **Read-Through**，简化代码
- **强一致性要求**：考虑 **Write-Through**
- **海量写入，可接受丢失**：使用 **Write-Behind**
<CachePatternsDemo />
---
## 5. 缓存的"坑"与解决方案
### 5.1 缓存穿透 (Cache Penetration)
**问题**：查询一个**不存在的数据**（如恶意请求 id=-1），缓存没有，数据库也没有。导致每次请求都直接打到数据库。
**解决方案**：
1. **布隆过滤器 (Bloom Filter)**：
- 在缓存前加一层过滤器，快速判断"这个 id **肯定不存在**"。
- 100% 判断不存在，但可能有**误判**（说不存在实际存在）。
```python
# 布隆过滤器示例
from pybloom_live import BloomFilter
# 预热：把所有有效的 user_id 放进去
bf = BloomFilter(capacity=1000000, error_rate=0.001)
for user_id in all_valid_user_ids:
bf.add(user_id)
def get_user(user_id):
# 第一道防线：布隆过滤器
if user_id not in bf:
return None # 肯定不存在，直接返回
# 第二道防线：缓存
cached = cache.get(f'user:{user_id}')
if cached is not None:
return cached
# 第三道防线：数据库
user = db.get_user(user_id)
if user:
cache.set(f'user:{user_id}', user)
else:
# 即使数据库没有，也缓存一个空值（防止穿透）
cache.set(f'user:{user_id}', NULL, ttl=60)
return user
```
2. **缓存空对象**：
- 查询不存在时，缓存一个 NULL 值（TTL 设置短一点，如 5 分钟）。
### 5.2 缓存击穿 (Cache Breakdown)
**问题**：某个**热点数据**过期（如微博热搜），瞬间几百万请求同时打到数据库。
**解决方案**：
1. **互斥锁 (Mutex Lock)**：
- 只允许一个线程查数据库，其他线程等待。
```python
import threading
lock = threading.Lock()
def get_user(user_id):
cached = cache.get(f'user:{user_id}')
if cached:
return cached
# 缓存未命中，尝试获取锁
if lock.acquire(blocking=False):
try:
# 只有拿到锁的线程才查数据库
user = db.get_user(user_id)
cache.set(f'user:{user_id}', user, ttl=600)
return user
finally:
lock.release()
else:
# 没拿到锁，等待一下再重试
time.sleep(0.01)
return get_user(user_id) # 递归重试
```
2. **逻辑过期 (Logical Expiration)**：
- 不设置 TTL，而是在 value 里存一个过期时间字段。
- 查询时发现"逻辑过期"，异步更新缓存，同时返回旧数据。
### 5.3 缓存雪崩 (Cache Avalanche)
**问题**：大量缓存**同时过期**（如系统重启后，所有缓存都在 00:00:00 过期），数据库瞬间被打爆。
**解决方案**：
1. **随机 TTL**：
- 避免同时过期，TTL 加上随机值。
```python
import random
ttl = 600 + random.randint(-60, 60) # 600 ± 60 秒
cache.set(f'user:{user_id}', user, ttl=ttl)
```
2. **缓存预热**：
- 系统启动时，主动加载热点数据到缓存。
- 使用定时任务，提前刷新即将过期的热点数据。
3. **熔断降级**：
- 当数据库压力过大时，暂时停止更新缓存，直接返回降级数据（如"系统繁忙，请稍后再试"）。
<CacheProblemsDemo />
---
## 6. 缓存的一致性策略
缓存是副本，副本和主本（数据库）可能不一致。如何保证一致性？
### 6.1 数据更新流程
假设你要更新用户信息：
```python
# 方案 1：先更新数据库，再更新缓存
db.update(user)
cache.set(user) # ⚠️ 问题：如果缓存更新失败，就不一致了
# 方案 2：先删除缓存，再更新数据库
cache.delete(user)
db.update(user) # ⚠️ 问题：删除和更新之间，有并发读，读到了旧数据并写回缓存
# 方案 3：先更新数据库，再删除缓存（推荐）
db.update(user)
cache.delete(user) # ✅ 最佳实践
```
**为什么删除而不是更新？**
假设两个线程同时更新：
| 时间 | 线程 A | 线程 B | 数据库 | 缓存 |
| :--- | :--------------- | :--------------- | :----- | :---- |
| 1 | 读 user (age=20) | | 20 | 20 |
| 2 | | 读 user (age=20) | 20 | 20 |
| 3 | 更新 age=25 | | 25 | 20 |
| 4 | | 更新 age=30 | 30 | 20 |
| 5 | 写缓存 (age=25) | | 30 | 25 ❌ |
| 6 | | 写缓存 (age=30) | 30 | 30 ✅ |
如果是**删除缓存**，则不存在这个问题。
### 6.2 延迟双删 (Delayed Double Deletion)
为了极致一致性，可以在更新数据库前后都删除缓存：
```python
def update_user(user_id, new_data):
# 1. 第一次删除缓存
cache.delete(f'user:{user_id}')
# 2. 更新数据库
db.update(user_id, new_data)
# 3. 延迟几百毫秒后，再次删除缓存
# （为了删除在步骤 1-2 之间被写入的旧数据）
time.sleep(0.5)
cache.delete(f'user:{user_id}')
```
### 6.3 订阅 Binlog (Canal / Debezium)
最完美的方案：**把缓存更新从应用代码中剥离**。
- 监听 MySQL 的 Binlog（变更日志）。
- 数据库更新后，异步消费 Binlog，更新/删除缓存。
- **优点**：代码解耦，最终一致性保证。
<CacheConsistencyDemo />
---
## 7. 实战：设计一个高性能缓存系统
### 7.1 需求分析
我们要设计一个"商品详情页"的缓存系统：
- **读多写少**：100 次浏览，1 次编辑。
- **热点集中**：20% 的商品占 80% 的访问。
- **可接受短时不一致**：价格延迟 1 秒更新没问题。
### 7.2 架构设计
```
客户端
↓
[本地缓存: Caffeine]
- 容量: 1000 个商品
- TTL: 30 秒
- 用途: 极热点商品（如秒杀活动）
↓ (未命中)
[分布式缓存: Redis Cluster]
- 容量: 100 万个商品
- TTL: 5 分钟
- 用途: 所有商品数据
↓ (未命中)
[数据库: MySQL]
- 持久化存储
```
### 7.3 代码实现
```java
@Service
public class ProductService {
// 本地缓存
private final Cache<String, Product> localCache;
// Redis 客户端
@Autowired
private RedisTemplate<String, Product> redisTemplate;
// 数据库
@Autowired
private ProductMapper productMapper;
/**
* 三级缓存查询
*/
public Product getProduct(String productId) {
// L1: 本地缓存
Product product = localCache.getIfPresent(productId);
if (product != null) {
return product;
}
// L2: Redis 缓存
product = redisTemplate.opsForValue().get("product:" + productId);
if (product != null) {
localCache.put(productId, product); // 回填本地缓存
return product;
}
// L3: 数据库
synchronized (this) { // 防止缓存击穿
// 双重检查
product = redisTemplate.opsForValue().get("product:" + productId);
if (product != null) {
return product;
}
// 查数据库
product = productMapper.selectById(productId);
if (product == null) {
// 缓存空对象（防止缓存穿透）
redisTemplate.opsForValue().set(
"product:" + productId,
NULL_PRODUCT,
5,
TimeUnit.MINUTES
);
return null;
}
// 写入缓存（带随机 TTL，防止雪崩）
int ttl = 300 + ThreadLocalRandom.current().nextInt(-30, 30);
redisTemplate.opsForValue().set("product:" + productId, product, ttl, TimeUnit.SECONDS);
localCache.put(productId, product);
return product;
}
}
/**
* 更新商品（Cache-Aside 模式）
*/
public void updateProduct(Product product) {
// 1. 更新数据库
productMapper.updateById(product);
// 2. 删除缓存（而不是更新）
redisTemplate.delete("product:" + product.getId());
localCache.invalidate(product.getId());
// 3. （可选）延迟双删
CompletableFuture.runAsync(() -> {
try {
Thread.sleep(500);
redisTemplate.delete("product:" + product.getId());
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
});
}
}
```
### 7.4 监控与调优
```java
@RestController
public class CacheMetricsController {
@Autowired
private Cache localCache;
@GetMapping("/cache/stats")
public Map<String, Object> getCacheStats() {
CacheStats stats = localCache.stats();
return Map.of(
"hitRate", stats.hitRate(), // 命中率（目标: > 90%）
"hitCount", stats.hitCount(), // 命中次数
"missCount", stats.missCount(), // 未命中次数
"evictionCount", stats.evictionCount(), // 淘汰次数
"averageLoadPenalty", stats.averageLoadPenalty() // 平均加载耗时 (ns)
);
}
}
```
**关键指标**：
- **命中率 (Hit Rate)**：> 90% 为优秀。
- **平均加载耗时 (Average Load Penalty)**：未命中时加载数据的平均时间，越小越好。
- **淘汰次数 (Eviction Count)**：过高说明缓存容量不足。
<ProductCacheDemo />
---
## 8. 总结与学习路线
缓存设计是后端系统的"核心技能"，掌握它能让你的系统性能提升 **10-100 倍**。
### 8.1 核心知识点
| 知识点 | 重要程度 | 难度 | 实战频率 |
| :--------------------- | :--------- | :--- | :------- |
| **多级缓存架构** | ⭐⭐⭐⭐⭐ | 中 | 极高 |
| **Cache-Aside 模式** | ⭐⭐⭐⭐⭐ | 低 | 极高 |
| **缓存穿透/击穿/雪崩** | ⭐⭐⭐⭐⭐ | 高 | 高 |
| **布隆过滤器** | ⭐⭐⭐⭐ | 中 | 中 |
| **缓存一致性** | ⭐⭐⭐⭐ | 高 | 高 |
| **分布式锁** | ⭐⭐⭐⭐ | 中 | 中 |
| **缓存监控与调优** | ⭐⭐⭐⭐ | 中 | 高 |
### 8.2 学习路线
1. **入门**（1-2 天）：
- 理解缓存的本质和局部性原理。
- 使用 Redis 做简单的键值缓存。
- 掌握 Cache-Aside 模式。
2. **进阶**（1 周）：
- 实现多级缓存（本地缓存 + Redis）。
- 解决缓存三大问题（穿透、击穿、雪崩）。
- 学习布隆过滤器、分布式锁。
3. **实战**（2-4 周）：
- 设计一个高并发的商品详情页缓存系统。
- 接入监控系统，实时观测缓存命中率。
- 压测验证性能提升。
4. **深入**（持续）：
- 学习 Redis 高可用（哨兵、集群）。
- 研究热点数据的自动识别与预热。
- 探索一致性哈希、缓存分片算法。
### 8.3 推荐资源
- **书籍**：
- 《Redis 设计与实现》（Huangz）
- 《高性能 MySQL》（第 5 章：缓存）
- **文章**：
- Redis 官方文档: https://redis.io/docs/
- Google 的《缓存设计指南》
- **工具**：
- Redis Desktop Manager (Redis 可视化)
- JMeter (压测工具)
---
## 9. 名词速查表 (Glossary)
| 名词 | 全称 | 解释 |
| :--------------------- | :------------------ | :------------------------------------------------------------------------------- |
| **Cache** | - | **缓存**。存储数据副本的快速存储层，用于加速访问。 |
| **Hit Ratio** | - | **命中率**。缓存命中的请求数占总请求数的比例（目标: > 90%）。 |
| **TTL** | Time To Live | **生存时间**。缓存条目的过期时间。 |
| **Cache Penetration** | - | **缓存穿透**。查询不存在的数据，导致请求直接打到数据库。 |
| **Cache Breakdown** | - | **缓存击穿**。热点数据过期，瞬间大量请求打到数据库。 |
| **Cache Avalanche** | - | **缓存雪崩**。大量缓存同时过期，数据库压力骤增。 |
| **Bloom Filter** | - | **布隆过滤器**。空间效率高的概率型数据结构，用于判断"一个元素是否在一个集合中"。 |
| **Eviction** | - | **淘汰**。缓存满了时，删除旧数据为新数据腾空间。 |
| **LRU** | Least Recently Used | **最近最少使用**。常见的缓存淘汰策略。 |
| **Cache-Aside** | - | **旁路缓存**。应用代码直接操作缓存和数据库的模式。 |
| **Read-Through** | - | **读穿透**。缓存库自动从数据库加载数据。 |
| **Write-Through** | - | **写穿透**。写入缓存时同步写入数据库。 |
| **Write-Behind** | - | **异步写回**。写入缓存后异步批量写数据库，性能高但可能丢失数据。 |
| **Consistent Hashing** | - | **一致性哈希**。分布式缓存中用于数据分片的算法。 |
| **Local Cache** | - | **本地缓存**。与应用在同一进程内的缓存（如 Caffeine）。 |
| **Distributed Cache** | - | **分布式缓存**。独立服务，通过网络访问（如 Redis）。 |
Reference in New Issue Copy Permalink