通用三层缓存架构背后的架构思维
架构到底是设计些什么？为什么别人一聊架构，就是一套一套的，说个没完。但是到你聊架构了，就只是加机器，重启试试，然后就没词了？其实核心问题不是你的技术不行，而是你还没有掌握架构思维。
关于架构思维，这是一个很抽象的词。一方面，架构一定是有技术门槛的。你必须有足够的技术支撑，才能想象出后续怎么落地，架构方案才能成型。另一方面。架构又是非常抽象的。他没有固定的技术栈，甚至没有固定的方法，所有设计，都是要根据业务灵活变动的。另外，架构也是非常主观的。没有万能的架构，只有合适的架构。而这个合适，就一定包含了叫故事的主观理解。但最后，架构又一定是有一些规律的。就像你做任何事情都会形成习惯一样，架构问题处理多了也会形成一些独特的习惯。
那么这次，我就通过缓存这个场景来给你介绍一个我的习惯，三级缓存架构。另外也准备了大量的技术资料，带你更全面的理解架构思维。希望通过这个分享，能够帮助你形成自己的架构思维。不管是工作，还是面试，都能更顺利，更自信。
点赞、关注、我们技术走起。
一、扫清障碍：布隆过滤器的 3 个“真相”
以大家非常熟悉的布隆过滤器为例，其实在布隆过滤器的背后，就经常隐藏着三个常见的误解。而真正理解这些误解，是你打开架构思维的第一步。
误解一：”黑名单校验功能简单，MySQL够用了，布隆过滤器多此一举“ 这里借用某位主播的观点，黑名单校验就是单条数据的检索，MySQL加上索引，轻松5000+的QPS，完全够绝大部分企业用了。真相是：布隆过滤器不只是完成业务，更重要的是分担压力。黑名单不是简单的做登录判断。大部分的业务，黑名单的作用就是要快速过滤掉大部分的非法请求。比如支付系统禁止黑名单用户转账，这是要在海量的请求中去过滤掉那些黑名单请求。这些被过滤掉的请求，是没有任何业务价值的。放到压力本来就大的数据库里去判断，这放在高并发的场景下，就属于 土豪请客-不拿家产当回事了。
误解二：“布隆过滤器有误判，所以不能做黑名单？” 误判这个事，确实不够完美，但就因为这一个缺点，就把布隆过滤器给判死刑了，这就有点太过草率了。 真相是：布隆过滤器带来的性能收益是完全可以覆盖他的误判成本的！ 布隆过滤器的定位是“前置挡板”。它的职责是用极低的成本，过滤掉 99% 绝对安全的请求。剩下那 1% 哪怕误判了，我们还有数据库在后面兜底做二次校验啊！这相比于全部用数据库来做校验，已经是很大的进步了。架构设计讲究的是“分层配合”，从来不是让一个组件单打独斗。
误解三：“黑名单要存封禁时间、理由，布隆过滤器只存 ID，没用？” 兄弟，你这是把”过滤器“当数据库来用了。 真相是： 布隆过滤器只负责回答“在不在”，不负责回答“是什么”。它就是一张快速通行证。至于你是被封了 3 天还是永久封禁，那是数据库该存的事儿。别强人所难，让保安干法官的活儿。
还有一个最大的误解就是：”谁没事天天高并发啊？“。这里我就再次回应一下：项目可以菜，但你不能真的菜。就像凤凰传奇里的曾毅，他可以不唱，但不能真的不会唱！我的观点是，现在程序员就得要有造飞机的本事，才能去争取到一个拧螺丝的工作。而且，现在有AI加持，学会造飞机其实并没有那么难。而且，现在确实很多引入AI的企业是这么想的。比如，你应该听说过前段时间，美团的前端要求全部转全栈了。你要是作为一个后端程序员，写后端服务还干不过一个前端，那你说，不淘汰你，淘汰谁？
好，地基打牢了，接下来咱们进入正题：为什么要搞这神秘兮兮的“三级缓存架构”？他到底是怎么一步步进化出来的？
二、核心推演：从单表到三级缓存的进化史
咱们还是以“黑名单校验”这个业务为例。
阶段 1：裸奔时代 —— MySQL 单表硬扛 ：
你的项目刚上线，用户量几万，QPS 几百，这时候完全不需要考虑缓存什么的。
这个阶段的做法就可以很简单。请求来了，直接查 MySQL 黑名单表。
这时候简单用用没问题。但数据库始终是你系统的性能瓶颈。一旦搞个活动，流量翻倍，数据库连接池瞬间被打满，磁盘 I/O 报警。
阶段 2：第一道防线 —— L1 本地内存布隆过滤器
(场景)：用户量到了百万级，QPS 上万。你发现，80% 的请求都是正常的，只有极少数是黑名单用户。
(思考)：这时候，为了这极少数的黑名单，让所有请求都去查一次数据库，甚至查一次 Redis，都太奢侈了。因为网络 I/O 是有开销的。
(做法)：我们在应用服务的JVM 内存里，加一层本地缓存，比如 Guava BloomFilter。这时有几个细节需要注意：
- 存什么数据？ 全量吗？内存宝贵，划不来。我们可以只存“热点黑名单” 比如最近 7 天活跃的违规用户。
- 数据怎么同步？ 黑名单数据库一更新，发个 MQ 广播，所有应用实例收到消息，更新自己的本地缓存。这一层，能兵不血刃地拦截掉 80% 的请求，而且响应时间是微秒级，连网络都不用走！
阶段 3：全量兜底 —— L2 Redis 分布式布隆过滤器
(场景)：并发继续涨，而且你发现本地内存有限，存不下几亿个黑名单 ID，或者有些冷门黑名单本地没命中，漏下去了。 这时候，我们就需要一个能存全量数据，且支持分布式共享的地方 —— 比如：Redis。这时需要注意的事情是：
- 选型：建议使用 Redis 中现成的
布隆过滤器，如果黑名单需要频繁删除，也可以使用布谷鸟过滤器，这比自己维护BitMap靠谱多了。。 - 数据一致性（重点）：Redis中需要保存全量的黑名单数据，这里可以用 Canal 监听 MySQL 的 Binlog。只要数据库一变，Canal 自动把变更同步到 Redis。这样能保证 Redis 里永远是全量的、相对新鲜的数据。当然，对数据一致性的细节分析，永远是面试中的重难点，更多方案就不展开说了。
(效果)：有了这一层防护，本地漏过来的非法请求，Redis 再拦住 19%。此时，99% 的请求已经被处理完了。
阶段 4：最后防线 —— L3 MySQL 数据库
(场景)：经过前两层的筛选，只剩下不到 1% 的请求了。
(做法)：这 1% 的请求，要么是布隆过滤器误判了（它说你在，其实你不在），要么是真的黑名单用户，需要获取封禁详情。
(效果)：这时候查数据库，压力已经极小了。这时候直接交给数据库负责“兜底”和“精准校验” 就好了。
(总结)： 看懂了吗？ L1 本地内存拼速度（挡 80%） -> L2 Redis 拼容量（挡 19%） -> L3 数据库拼准确（处理 1%）。 这就是形成了一套基础的三层缓存架构
三、举一反三：实战案例深度解析
这套 L1 本地 + L2 分布式 + L3 数据库 的思路，学会了就是通杀，很多类似的场景，都可以套用这一套缓存思路。我给你们举两个最典型的真实案例，一定要听懂，面试再被问到，绝对拿捏。
案例一：电商大促，商品详情页访问会异常频繁 这是经典的秒杀场景
(痛点)：双 11 零点，几百万人同时点开 iPhone 的商品详情页。注意，这时候大家看的都是同一个商品。如果你让这几百万请求都去查MySQL，那直接拉出去枪毙。就算是都去查 Redis，Redis 的单分片热点 Key 也会被打挂！ 那怎么套用这个三级缓存架构？
- L1-本地缓存：我们在应用层引入 Caffeine 或 Guava Cache。把Top 1000 的热点商品（比如 iPhone、茅台）的详情数据，直接缓存在本地。这样用户请求来了，应用服务器直接从自己内存里拿数据返回，根本不出服务器，性能是最高的。
- L2-Redis 缓存：存全量商品的详情。本地没命中的冷门商品，再来查 Redis。
- L3-数据库：作为数据源头，负责数据的持久化和强一致性。
(价值)：这叫“热点本地化”。大促的时候，让多级缓存一起分担流量，而不是把压力全部扔给Redis。
案例二：短视频推荐系统，去重场景
(痛点)：你刷短视频的时候，系统绝对不能给你推重复的视频。但是，你可能已经看过 5000 个视频了，系统怎么在毫秒级内，判断这一个新视频你有没有看过？ 如果你去查数据库，那数据库早崩了。 这又怎么套用这个三级缓存的架构呢？
L1-本地布隆：存用户“最近 1 小时”看过的视频 ID。推荐流里最容易重复的，就是刚看过的。这层能快速过滤掉刚刷过去的视频。
L2-Redis 布隆：存用户“最近 7 天”看过的全量视频 ID。本地没拦住，去 Redis 查。Redis 内存大，能存更多。
L3-数据库，通常推荐HBase：存用户“这辈子”看过的所有视频记录。只有极少数情况需要查这里。
这样既保证了用户体验（不重复），又保护了后端存储，这就是分层架构的魅力。
四、核心原则：三级缓存的底层逻辑
讲了这么多案例，这套架构的底层逻辑，其实就三句话。大家把这三句话刻在脑子里，以后做任何设计都能用得上：
第一：职责分层（Layering） L1 负责“快”，L2 负责“全”，L3 负责“准”。 不要试图用一个组件解决所有问题。让内存做内存的事，让磁盘做磁盘的事。
第二：压力递减（Funnel） 高并发系统的防御体系，一定是一个漏斗。 就像防洪大坝，上层拦截大部分“洪水”（流量），下层只处理核心请求。如果你的数据库压力比 Redis 还大，那你的架构一定设计错了。
第三：灵活扩展（Scalability） 每一层都可以独立扩容。 L1 不够？加应用实例； L2 不够？给 Redis 切片扩容； L3 不够？分库分表。 这种“解耦”的能力，才是系统能演进到亿级流量的关键。
五、总结与升华：架构即人生
回到开场的问题：架构设计到底在设计什么？ 它设计的是代码怎么写吗？不是！是组合哪些中间件吗？也不是。甚至是怎么才能做好这个项目吗？还不是。很多问题并没有标准答案。我觉得，架构设计的是“思想”。 是在混乱的、变化的业务中，建立一条高效、有序的思维模式。让整个团队处理问题，有法可依，而不是所有问题都要临时决策。
而这套“三级缓存架构”，其实也不仅仅是一套架构思维，也同样可以是一套人生理念。
L1 是你的直觉和习惯：处理生活中 80% 的琐事，要快，要不假思索，比如早起刷牙、通勤路线，不要让这些事情消耗你的核心能量。
L2 是你的知识库和工具：处理工作中 19% 的专业问题，要全，要能随时调用，比如你的编程经验、你的技术视野。
L3 是你的价值观和深度思考：处理那 1% 最关键的人生抉择，要准，要深思熟虑，比如未来怎么规划，是要放弃，还是躺平，或者是奋起一搏。
千万不要让L1的琐事去击穿你的L3深度思考，也不要用L1的直觉去草率决定你的L3人生大事。
我是楼兰，关注我， IT路上一起进步！