feat: add interactive demos for AI history, Auth design, and Git intro
This commit is contained in:
sanbuphy
@@ -6,26 +6,181 @@
|
||||
|
||||
## 0. 引言：看不见的"加速器"
|
||||
|
||||
你刷朋友圈时，为什么几秒钟就能加载出几百张图片？
|
||||
你查询订单时，为什么瞬间就能看到几个月前的数据？
|
||||
你有没有想过这些问题：
|
||||
|
||||
- 刷朋友圈时，为什么几秒钟就能加载出几百张图片？
|
||||
- 查询订单时，为什么瞬间就能看到几个月前的数据？
|
||||
- 刷新短视频时，为什么视频几乎瞬间就能播放？
|
||||
|
||||
这背后都有一个功臣：**缓存 (Cache)**。
|
||||
|
||||
如果数据库是"仓库"，那缓存就是"柜台"。
|
||||
常用的商品（热数据）放在柜台上，随拿随用；不常用的商品才需要去仓库里找。
|
||||
### 0.1 什么是缓存？用生活化的例子理解
|
||||
|
||||
### 0.1 为什么要缓存？
|
||||
想象一下你在家里的场景：
|
||||
|
||||
**场景 1：没有缓存的日子**
|
||||
|
||||
每次想喝水，你都要：
|
||||
1. 走到厨房（相当于访问数据库）
|
||||
2. 打开柜子
|
||||
3. 拿出水壶
|
||||
4. 倒水
|
||||
5. 回到客厅
|
||||
|
||||
即使你一小时内要喝 10 次水，每次都要重复这个过程。很累对吧？
|
||||
|
||||
**场景 2：有了缓存**
|
||||
|
||||
你在客厅的茶几上放了一个水杯（这就是缓存！）：
|
||||
- 第一次喝水：你还是要去厨房倒水，但把水杯留在茶几上
|
||||
- 之后每次喝水：直接拿起茶几上的水杯喝就行
|
||||
|
||||
**这就是缓存的核心思想**：把常用的东西放在触手可及的地方，避免每次都"跑远路"。
|
||||
|
||||
回到计算机世界：
|
||||
|
||||
| 生活中的例子 | 计算机中的对应 |
|
||||
| :--- | :--- |
|
||||
| **茶几上的水杯** | **内存缓存**（速度快，但容量小） |
|
||||
| **厨房的水壶** | **数据库**（速度慢，但容量大） |
|
||||
| **"我刚才用过这个水杯"** | **时间局部性**（刚用过的数据，很可能还会用） |
|
||||
| **"把这些常用的都放在茶几上"** | **空间局部性**（用过的数据附近的数据，也可能用到） |
|
||||
|
||||
### 0.2 为什么要缓存？
|
||||
|
||||
只有一个理由：**快**。
|
||||
|
||||
| 存储介质 | 访问延迟 | 吞吐量 | 典型用途 |
|
||||
| :--------------- | :------- | :----- | :------------- |
|
||||
| **L1 CPU 缓存** | ~1 ns | 极高 | 寄存器、变量 |
|
||||
| **内存 (Redis)** | ~100 ns | 高 | 热点数据、会话 |
|
||||
| **SSD 数据库** | ~1 ms | 中 | 持久化存储 |
|
||||
| **HDD 数据库** | ~10 ms | 低 | 归档存储 |
|
||||
但有多快呢？我们用个形象的比喻：
|
||||
|
||||
**关键点**：缓存的本质是**用空间换时间**，通过在更快的存储介质中保留数据副本，减少访问慢速存储的次数。
|
||||
| 存储介质 | 访问时间 | 生活类比 | 能做什么 |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
| **L1 CPU 缓存** | ~1 纳秒 | 眨一下眼睛（1/10秒）的 **十亿分之一** | CPU 执行一条指令 |
|
||||
| **内存 (Redis)** | ~100 纳秒 | 眨一下眼睛的 **千万分之一** | 存储热点数据 |
|
||||
| **SSD 数据库** | ~1 毫秒 | 眨一下眼睛 | 读写文件 |
|
||||
| **HDD 数据库** | ~10 毫秒 | 眨 10 下眼睛 | 传统硬盘操作 |
|
||||
|
||||
**换个角度理解**：
|
||||
- 从内存读数据 = 从茶几拿水杯
|
||||
- 从 SSD 读数据 = 从厨房拿水壶
|
||||
- 从 HDD 读数据 = 从楼下便利店买水
|
||||
|
||||
**关键点**：缓存的本质是**用空间换时间**——多准备几份"副本"放在快速的地方，节省每次都去"慢速地方"取数据的时间。
|
||||
|
||||
### 0.3 缓存的真实案例
|
||||
|
||||
**案例 1：淘宝商品详情页**
|
||||
|
||||
当你打开一个商品页面时：
|
||||
- **商品基本信息**（价格、标题）：从 Redis 缓存读取（~5 毫秒）
|
||||
- **商品大图**：从 CDN 缓存读取（~20 毫秒）
|
||||
- **用户浏览历史**：从本地缓存读取（~1 毫秒）
|
||||
|
||||
如果这些都不用缓存，全部查数据库：
|
||||
- 查询时间可能从 **5 毫秒** 变成 **200 毫秒**
|
||||
- 数据库要同时处理几百万人的请求，直接"累垮"
|
||||
|
||||
**案例 2：微信朋友圈**
|
||||
|
||||
你刷朋友圈时：
|
||||
- **图片**：之前看过的图片，都在手机本地缓存里
|
||||
- **好友列表**：第一次加载后缓存在内存里
|
||||
- **点赞数据**：热点数据在 Redis 缓存中
|
||||
|
||||
没有缓存的话：每次刷新都要重新下载所有内容，流量和速度都受不了。
|
||||
|
||||
---
|
||||
|
||||
## 🗺️ 全局观：缓存知识地图
|
||||
|
||||
在深入细节之前，让我们先看看缓存设计的"全貌"。就像旅游前先看地图一样，这样你不会迷路。
|
||||
|
||||
### 核心目标（一句话概括）
|
||||
|
||||
**让数据访问更快、系统更强，同时保证数据不出错。**
|
||||
|
||||
### 知识体系地图
|
||||
|
||||
```
|
||||
缓存设计
|
||||
│
|
||||
├─ 📦 基础概念（为什么需要缓存？）
|
||||
│ ├─ 局部性原理（时间局部性、空间局部性）
|
||||
│ ├─ 缓存生命周期（写入 → 命中 → 过期 → 淘汰）
|
||||
│ └─ 性能对比（内存 vs 数据库：快 100 倍）
|
||||
│
|
||||
├─ 🏗️ 架构选型（用什么缓存？）
|
||||
│ ├─ 本地缓存（单机快，但容量小）
|
||||
│ ├─ 分布式缓存（容量大，但稍慢）
|
||||
│ └─ 多级缓存（组合使用，最佳方案）
|
||||
│ ├─ 浏览器缓存（用户本地）
|
||||
│ ├─ CDN 缓存（离用户近）
|
||||
│ ├─ 应用本地缓存（极速）
|
||||
│ ├─ Redis 缓存（高容量）
|
||||
│ └─ 数据库（兜底）
|
||||
│
|
||||
├─ 🎯 设计模式（怎么用缓存？）
|
||||
│ ├─ Cache-Aside（最常用，手动控制）
|
||||
│ ├─ Read-Through（缓存自己加载）
|
||||
│ ├─ Write-Through（同步写缓存和数据库）
|
||||
│ └─ Write-Behind（异步写，最快但可能丢数据）
|
||||
│
|
||||
├─ ⚠️ 常见问题（缓存会出什么错？）
|
||||
│ ├─ 缓存穿透（查不存在数据，数据库压力大）
|
||||
│ ├─ 缓存击穿（热点数据过期，瞬间高并发）
|
||||
│ └─ 缓存雪崩（大量数据同时过期）
|
||||
│
|
||||
├─ 🔒 一致性保证（缓存和数据库不一致怎么办？）
|
||||
│ ├─ 更新策略（先更数据库，再删缓存）
|
||||
│ ├─ 延迟双删（极致一致性）
|
||||
│ └─ Binlog 订阅（异步解耦）
|
||||
│
|
||||
└─ 🛠️ 实战技巧（工程中怎么做？）
|
||||
├─ 布隆过滤器（快速判断数据是否存在）
|
||||
├─ 分布式锁（防止缓存击穿）
|
||||
├─ 随机 TTL（防止雪崩）
|
||||
├─ 缓存预热（启动时加载热点数据）
|
||||
└─ 监控调优（命中率要 > 90%）
|
||||
```
|
||||
|
||||
### 学习路径建议（0基础小白版）
|
||||
|
||||
**第一步：理解核心概念**（1-2 天）
|
||||
- 理解"为什么需要缓存"（茶几 vs 厨房的例子）
|
||||
- 记住性能数据：内存比数据库快 100 倍
|
||||
- 了解缓存的生命周期（写入 → 命中 → 过期 → 淘汰）
|
||||
|
||||
**第二步：掌握最常用的模式**（2-3 天）
|
||||
- 重点学习 **Cache-Aside 模式**（90% 的场景都用这个）
|
||||
- 动手写代码：用 Redis 做简单的键值缓存
|
||||
- 理解"为什么删缓存而不是更新缓存"
|
||||
|
||||
**第三步：学习多级缓存**（3-5 天）
|
||||
- 理解为什么需要"多层防御"（浏览器 → CDN → 本地 → Redis → 数据库）
|
||||
- 掌握每一层的用途和特点
|
||||
- 动手实践：给自己的项目加一层缓存
|
||||
|
||||
**第四步：解决常见问题**（1 周）
|
||||
- 理解缓存三大问题（穿透、击穿、雪崩）
|
||||
- 学习解决方案（布隆过滤器、分布式锁、随机 TTL）
|
||||
- 实战演练：模拟高并发场景，看缓存如何保护数据库
|
||||
|
||||
**第五步：深入一致性**（1-2 周）
|
||||
- 理解缓存和数据库可能不一致的场景
|
||||
- 掌握"先更数据库，再删缓存"的最佳实践
|
||||
- 进阶：学习 Binlog 订阅方案
|
||||
|
||||
**第六步：实战项目**（2-4 周）
|
||||
- 设计一个完整的缓存系统（如商品详情页缓存）
|
||||
- 搭建监控系统，实时查看缓存命中率
|
||||
- 压测验证：看看性能提升了多少倍
|
||||
|
||||
### 关键指标（学完后你要能回答）
|
||||
|
||||
- 缓存的**命中率**是多少？（优秀：> 90%）
|
||||
- 缓存能**提升多少性能**？（10-100 倍）
|
||||
- 如何解决缓存**三大问题**？（穿透、击穿、雪崩）
|
||||
- 缓存和数据库**不一致**怎么办？（先更库，再删缓存）
|
||||
- **多级缓存**的顺序是什么？（浏览器 → CDN → 本地 → Redis → 数据库）
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user