一、缓存架构总览：券商交易系统为什么需要缓存？
各位同学好，我是老张。在券商系统里摸爬滚打了十几年，今天咱们聊聊缓存。
说实话，我刚入行那会儿，对缓存的理解就是“存点数据，快一点”。直到有一次生产事故——行情推送延迟了3秒，客户直接炸了锅。那一刻我才真正明白：在交易系统里，缓存不是锦上添花，而是保命符。
1.1 交易系统的性能瓶颈在哪？
先看一个典型的交易链路：
客户端 → 接入网关 → 交易核心 → 风控引擎 → 清算系统 → 数据库
这条链路上，最慢的环节永远是数据库。你想想看，一个高频交易客户每秒可能发几十笔订单，如果每笔都去查数据库，磁盘IO、锁竞争、事务日志……系统不崩才怪。
我在项目中遇到过最夸张的情况：某券商在做大促活动时，数据库连接池被打满，所有交易请求排队等待。最后怎么解决的？靠缓存扛住了90%的读请求。
核心矛盾：交易系统要求毫秒级响应，但数据库的读写能力存在物理上限。缓存就是在这中间搭一座“快车道”。
1.2 缓存到底解决了什么问题？
说白了，缓存就干三件事：
- 降低延迟：内存读取是纳秒级，磁盘是毫秒级，差了三个数量级
- 减轻数据库压力：把热点数据放在缓存里，数据库只处理写操作和冷数据
- 提升系统吞吐量：同样的硬件，加一层缓存，QPS能翻好几倍
举个例子，证券行情数据。一只股票的实时行情，每秒可能被查询上万次。如果每次都去数据库拉，数据库早挂了。但用Redis缓存，设置5秒过期，数据直接从内存返回，响应时间从50ms降到1ms以内。
我的经验：缓存命中率低于80%的缓存方案，基本是失败的。要么数据模型设计有问题，要么过期策略不合理。
1.3 缓存带来的挑战——别以为加了缓存就万事大吉
嗯，这里要泼点冷水。缓存不是银弹，用不好反而会惹祸。
| 挑战 | 说明 | 我踩过的坑 |
|---|---|---|
| 数据一致性 | 缓存和数据库的数据可能不一致 | 曾经因为缓存没及时更新，客户看到的价格还是5分钟前的，差点被投诉 |
| 缓存穿透 | 查询一个不存在的数据，每次都会穿透到数据库 | 某次爬虫攻击，专门请求不存在的股票代码，数据库直接被打挂 |
| 缓存雪崩 | 大量缓存同时过期，请求全部打到数据库 | 双十一零点，所有行情缓存同时失效，数据库瞬间爆了 |
| 缓存击穿 | 热点key过期，高并发请求直接打到数据库 | 某龙头股突发利好，缓存刚好过期，瞬间几十万查询涌向数据库 |
避坑指南：我曾经因为没做缓存预热，系统上线后前10分钟所有请求都穿透到数据库，导致服务不可用。现在我的习惯是：上线前先跑一遍预热脚本，把热点数据提前加载到缓存。
1.4 券商交易系统的缓存分层架构
一个成熟的交易系统，缓存不是单层的，而是分层的。我习惯把它画成下面这样：
这张图我画了很多遍。每一层缓存都有它的职责：
- 客户端缓存：减少网络请求，适合不常变的数据
- 接入层缓存：挡掉大部分重复请求，保护后端服务
- 分布式缓存：全局共享，适合跨服务的数据
- 本地堆缓存：速度最快，适合每个服务独有的热点数据
我的习惯：热点数据放本地缓存，共享数据放Redis。比如股票代码表，每个服务启动时加载到本地缓存，查询时连网络开销都省了。
1.5 什么时候不该用缓存？
说了这么多缓存的好处，也得说说它的禁区。我在项目中总结了几种不适合用缓存的场景：
- 强一致性要求的数据：比如资金流水、成交记录，必须实时从数据库读取
- 频繁更新的数据：如果数据每秒都在变，缓存的意义就不大了
- 数据量特别大且访问频率低：比如历史交易日志，存缓存里纯属浪费内存
举个例子，客户的资金余额。虽然我们也会缓存，但设置了非常短的过期时间（比如1秒），而且每次交易完成后会主动失效缓存。为什么？因为资金数据差一分钱都不行。
警告：千万别把缓存当成数据库用。缓存的数据是可以丢的，数据库的数据不能丢。这个原则一定要刻在脑子里。
1.6 总结一下
缓存架构的核心就一句话：用空间换时间，用可控的不一致性换性能。
在券商交易系统里，缓存不是可选项，而是必选项。但怎么用好它，需要你对业务场景有深刻理解。后面几章，我会详细讲每种缓存策略的具体实现和坑点。
记住：没有最好的缓存策略，只有最适合的缓存策略。