一、缓存策略概述：分布式交易系统为什么需要缓存？
大家好，我是老张。在金融交易系统这个行当摸爬滚打了十几年，今天咱们来聊聊缓存。
你想想看，一个交易系统每秒要处理几万笔订单，每笔订单要查账户、查行情、查风控规则。如果每次都去数据库里捞数据，那数据库早就挂了。我见过不少团队，一开始没重视缓存，结果系统上线第一天就被压垮了。
1.1 交易系统的性能瓶颈在哪？
说白了，交易系统最怕两件事：慢和挂。
- 慢：一笔订单处理超过100毫秒，用户就骂娘了。高频交易场景下，1微秒的延迟都可能造成巨大损失。
- 挂：数据库连接池被打满，请求排队，最终雪崩。我经历过一次，那叫一个惨烈。
为什么会这样？因为数据库的读写速度跟内存比，差了几个数量级。
| 存储介质 | 延迟（近似） | 吞吐量（近似） |
|---|---|---|
| CPU L1缓存 | 1 ns | 极高 |
| 内存（Redis） | 100 ns - 1 μs | 10万+ QPS |
| SSD磁盘 | 100 μs | 几千 QPS |
| 传统数据库（MySQL） | 1 ms - 10 ms | 几百 QPS |
你看，内存比磁盘快了一千倍。这就是缓存存在的根本原因——用空间换时间。
1.2 缓存的核心价值
我个人习惯把缓存的价值总结为三点：
- 降低延迟：热点数据放内存里，查询时间从毫秒级降到微秒级。
- 提升吞吐：单机Redis能扛10万+ QPS，数据库只能扛几百。缓存扛住了，数据库就轻松了。
- 保护后端：缓存是数据库的「缓冲垫」。突发流量来了，缓存先顶住，数据库不至于被打死。
我遇到过的一个案例：某券商行情系统，开盘瞬间涌入100倍正常流量。如果没有缓存层，数据库直接挂了。我们当时用Redis缓存了前10分钟的行情快照，扛住了峰值，数据库只承受了正常负载。
1.3 缓存带来的挑战
嗯，这里要注意。缓存不是银弹，用不好反而会惹祸。
挑战一：数据一致性
缓存里的数据跟数据库里的数据，怎么保证一致？这是最头疼的问题。
- 更新数据库后，缓存没更新——用户读到脏数据。
- 缓存过期了，大量请求同时穿透到数据库——缓存雪崩。
挑战二：缓存穿透
查询一个根本不存在的数据。缓存里没有，数据库里也没有。每次请求都穿透到数据库。如果有人恶意攻击，数据库直接被打爆。
挑战三：缓存雪崩
大量缓存同时过期，或者Redis挂了。所有请求直接打到数据库。我见过一个交易系统，因为缓存统一设置了1小时过期，整点一到，数据库瞬间被压垮。
挑战四：缓存击穿
某个热点key突然失效，大量并发请求同时去数据库查询。比如某个热门股票行情，缓存过期瞬间，成千上万个请求同时涌入。
我曾经踩过的坑：有一次上线前，我图省事，给所有缓存key设置了相同的过期时间。结果凌晨3点，缓存集体失效，数据库CPU直接飙到100%。那晚我陪着运维一起通宵，从此再也不敢这么干了。
1.4 交易系统缓存的特殊要求
金融交易系统跟普通互联网系统不一样，它对缓存有更苛刻的要求：
| 要求 | 说明 | 我的做法 |
|---|---|---|
| 强一致性 | 账户余额、持仓数据不能有偏差 | 这类数据不缓存，或者用「读写锁」+「延迟双删」 |
| 高可用 | 缓存挂了不能影响交易 | Redis集群+本地缓存兜底 |
| 低延迟 | 微秒级响应 | 热点数据常驻内存，避免序列化开销 |
| 防雪崩 | 缓存失效不能打垮数据库 | 布隆过滤器+限流+熔断 |
1.5 本章知识体系总览
下面这张图，是我梳理的缓存策略核心逻辑。你看一眼，心里就有谱了。
我的建议：刚开始接触缓存，别想着一步到位。先把「为什么需要缓存」想清楚，再考虑「怎么用」。很多团队一上来就搞Redis集群、哨兵模式，结果连最基本的缓存穿透都没防住。先打好基础，后面几章我们会逐个击破。
好了，这一章就到这里。缓存这东西，用好了是神器，用不好是灾难。下一章我们聊聊具体的缓存策略——本地缓存 vs 分布式缓存，什么时候该用哪个，我会结合实战案例来讲。