一、前言：为什么高并发系统必须做缓存架构？
在秒杀、短视频、电商大促、资讯流量等高并发场景下，MySQL磁盘IO极限QPS仅一两万，完全扛不住十万、百万级流量冲击。
Redis基于纯内存IO、单线程模型、非阻塞多路复用，单机可轻松支撑10W+ QPS，是整个互联网高并发架构的流量护城河。
但很多项目仅仅是简单“套一层Redis”，最终引发：缓存雪崩、数据库打爆、热点Key宕机、大Key阻塞、数据不一致、集群抖动等线上事故。
真正的高并发缓存，不是简单读写Key，而是一套完整的架构体系 + 防护体系 + 性能调优体系。
二、高并发标准多级缓存架构（企业通用）
主流互联网高并发架构采用三级缓存架构，层层拦截流量，最大限度降低Redis与DB压力。
2.1 三级缓存架构链路
用户请求 → Nginx静态缓存 → 本地缓存(Caffeine) → Redis分布式缓存 → MySQL数据库
一级缓存：Nginx/CDN：拦截静态资源、页面缓存，抵御超大流量
二级缓存：本地内存缓存（Caffeine）：JVM级别缓存，无网络IO，毫秒级响应
三级缓存：Redis分布式缓存：统一缓存中心，支撑分布式多实例共享数据
2.2 多级缓存核心价值
规避Redis集群单点压力，大量请求在前置层级被拦截
大幅降低网络IO，提升接口吞吐量与响应速度
Redis宕机时，本地缓存可兜底，避免服务彻底雪崩
三、高并发缓存三大致命问题（穿透/击穿/雪崩）
所有Redis线上高并发事故，90%都源于这三类问题，必须架构层面彻底防护。
3.1 缓存穿透（查无数据，直达DB）
现象：查询数据库与缓存都不存在的数据（恶意参数、负数ID、随机Key），请求直接穿透到DB，压垮数据库。
生产解决方案：
接口参数校验：非法参数直接拦截
空值缓存：查询为空缓存空Key，短期过期（30s~5min）
布隆过滤器：前置拦截所有不存在的业务Key，超高并发最优方案
3.1.1 布隆过滤器核心原理、优缺点详解
1、核心原理
布隆过滤器（Bloom Filter）是一种空间极致节省、基于二进制位图的概率型去重、判断存在性的数据结构，专门用于解决「海量数据存在性判定」场景。
底层由一个超长二进制bit数组+多个不同哈希函数组成，核心逻辑：
存入数据：一个Key经过多个哈希函数计算，得到多个bit数组下标，将对应bit位全部置为1；
判断存在：再次对Key哈希取位，若所有bit位均为1，则判定数据大概率存在；任意一个bit位为0，数据一定不存在；
核心特性：不存在绝对准确，不存在一定不存在。
试用场景:数据命中不高、 数据相对固定、 实时性低（通常是数据集较大） 的应用场景
2、核心优点（生产首选原因）
占用内存极小：基于bit位图存储，存储海量ID仅需极少内存，远优于Set、数据库查询；
查询/插入速度极快：多次哈希计算，时间复杂度 O(1)，支持百万、千万级高并发拦截；
无存储上限压力：适合商品ID、用户ID、订单号等海量数据存在性校验；
完美防穿透：恶意非法ID、随机请求可在过滤器层直接拦截，不进缓存、不打DB。
3、致命缺点（生产必须规避）
存在误判（核心短板）：不同Key哈希可能碰撞，导致「原本不存在的数据，误判为存在」，只能做到大概率存在，无法100%精准；
不支持删除数据：多个Key共用bit位，删除某一个Key会清空对应bit位，导致其他Key判定失效，天然不支持删除操作；
数据动态更新不友好：业务新增大量数据后，误判率会上升，需要定期重建过滤器；
初始化成本高：系统冷启动时需要全量加载历史数据，否则会出现大量误拦截。
4、生产落地优化方案
使用Redis布隆过滤器或Guava布隆过滤器，预设合理容量与误判率，降低哈希碰撞概率；
采用定时异步重建机制，解决数据新增导致的误判率升高问题；
搭配空值缓存兜底，完美解决少量误判场景，彻底根治缓存穿透。
3.2 缓存击穿（热点Key过期，瞬时打爆DB）
现象：超级热点Key（首页商品、活动秒杀）统一过期，海量并发瞬间击穿缓存，直达数据库。
解决方案：
热点Key永不过期，后台异步更新
过期时间随机打散，避免批量同时失效
分布式锁互斥更新，单线程更新缓存
3.3 缓存雪崩（大量Key失效/Redis宕机）
现象：大批量缓存同时过期、或Redis集群宕机，流量全部落库，引发级联雪崩。
解决方案：
过期时间随机偏移，杜绝集中过期
Redis高可用集群（哨兵/Cluster）杜绝单点宕机
服务熔断、降级、限流兜底
多级缓存兜底，本地缓存扛住突发流量
四、Redis高可用架构选型
不同并发量级对应不同部署架构，选错架构必然导致性能瓶颈与线上故障。
4.1 单机模式
特点：部署简单、无同步开销、性能最高
缺陷：单点故障、无备份、容量有限
适用：测试环境、低并发小型项目
4.2 主从复制模式
特点：一主多从、读写分离、数据多副本
缺陷：无自动故障转移、写单点瓶颈、异步复制丢数风险
适用：读多写少、无需高可用自动切换场景
4.3 哨兵模式（Sentinel）——中小厂生产标配
特点：监控、自动故障转移、客户端自动切换主节点
优势：高可用、运维简单、稳定性高
短板：不支持分片，写能力无法扩容
适用：绝大多数中小型互联网业务
4.4 Cluster集群模式——高并发大数据标配
原理：16384哈希槽分片、多主多从、横向扩容
优势：读写均可扩容、容量无上限、单节点故障不影响全局
适用：秒杀、大促、海量数据、百万级并发场景
五、全方位Redis性能优化
5.1 大Key、热Key专项优化（线上故障TOP1）
大Key危害：主线程阻塞、超时、集群倾斜、内存暴涨
优化方案：
大Key拆分：大Hash拆分为多个小Hash
分页查询：避免一次性获取全量数据
定期巡检清理过期冗余Key
热Key危害：单节点流量打爆、CPU飙升
优化方案：
本地缓存兜底，拦截热点流量
热点Key多副本分担、读写分离
热点数据永不过期、异步更新
5.2 持久化性能调优
纯内存性能最高，但极易丢数，生产必须开启混合持久化（RDB+AOF）
AOF刷盘策略：appendfsync everysec（性能与安全平衡）
开启aof重写、RDB压缩，减少磁盘IO
规避fork频繁耗时，降低持久化对主线程影响
5.5 连接与网络优化
使用连接池，避免频繁创建销毁连接
合理设置最大连接数、超时时间，避免连接耗尽
内网部署，禁止跨机房、公网访问，降低网络延迟
六、高并发真实生产实战案例
前面讲解的理论优化、架构方案最终需要落地业务。本节带来两个大厂高频线上实战案例：热点Key缓存重建并发优化、缓存数据库双写不一致优化，完美解决大促、秒杀核心线上问题，适配生产落地与面试手撕场景。
6.1 实战案例一：热点缓存Key过期重建并发优化
6.1.1 线上事故背景
电商首页、活动秒杀、爆款商品属于典型超级热点Key，QPS可达数万。传统固定过期缓存方案存在严重隐患：当热点Key统一过期瞬间，海量并发请求全部穿透到数据库，MySQL CPU瞬间打满、接口超时、页面雪崩，是大促高频高发事故。
6.1.2 原始问题代码漏洞
常规伪代码逻辑：查询缓存→缓存失效→查询DB→写入缓存，该逻辑在热点Key场景下会出现并发击穿，无数线程同时查库、更新缓存，不仅压垮DB，还会造成缓存频繁被重复覆盖，浪费IO资源。
6.1.3 生产终极优化方案（分布式锁+异步更新）
针对热点Key场景，摒弃固定过期主动重建模式，采用「永不过期+分布式锁单线程重建+后台异步兜底更新」方案，彻底杜绝击穿问题。
核心设计思路：
热点商品、活动数据缓存设置永不过期，从根源杜绝集中过期击穿；
数据更新不依赖缓存过期触发，通过业务事件主动触发更新；
极端缓存为空场景，使用Redisson分布式锁，全局仅单线程查询DB重建缓存，其余线程直接命中旧缓存兜底；
新增定时任务异步兜底，定时刷新热点缓存，保证数据最终一致性。
6.1.4 完整执行流程
用户请求访问热点数据，优先查询Redis缓存；
缓存存在，直接返回数据，无DB请求；
缓存不存在（首次上线、手动清空），尝试抢占分布式锁；
抢锁成功：查询最新DB数据，写入Redis，释放锁；
抢锁失败：不阻塞、不查库，短暂自旋后读取已有缓存数据；
日常数据变更后，通过MQ异步更新热点缓存，无需依赖过期重建。
6.1.5 方案优势
彻底解决热点Key过期雪崩、缓存击穿问题；
极大降低DB查询压力，数万并发仅单线程落库；
读写性能拉满，接口响应稳定无抖动；
兼容数据实时更新，兼顾高可用与一致性。
6.2 实战案例二：缓存与数据库双写不一致问题优化
6.2.1 问题背景
高并发更新业务（商品价格修改、库存变动、用户信息更新）中，缓存与数据库数据不一致是高频疑难问题。很多项目因读写策略错误、并发更新冲突、删除缓存失败，导致用户查询到旧数据，引发业务纠纷。
6.2.2 错误方案踩坑解析
错误1：先更新缓存，后更新数据库
并发场景下，后更新DB的请求会覆盖先更新请求，出现新缓存+旧数据库永久脏数据；
错误2：先删除缓存，后更新数据库
删缓存后、更新DB前，高并发读请求会查询旧DB数据重新写入缓存，永久脏数据，无法自动恢复；
结论：以上两种方案均无法用于生产高并发场景，必然出现数据不一致。
6.2.3 生产标准方案：先更新数据库，后异步删除缓存
互联网大厂统一采用「先更库、后删缓存」策略，是兼顾性能与一致性的最优基础方案。
核心流程：
业务更新数据，首先执行数据库UPDATE操作，保证底层数据准确；
DB更新成功后，立即删除对应业务缓存；
后续用户查询请求自动重新加载最新DB数据，写入缓存；
DB更新失败则不操作缓存，保证数据统一。
6.2.4 极致优化：MQ异步重试兜底（解决删除失败）
同步删除缓存存在短板：网络抖动、Redis超时会导致删缓存失败，依旧产生脏数据。针对核心业务，新增MQ异步重试机制兜底。
最终落地流程：
事务内更新MySQL数据库；
发送缓存删除消息至MQ；
消费者消费消息，异步删除Redis缓存；
删除失败自动重试3次，彻底杜绝删缓存失效问题；
配合定时巡检任务，定时比对DB与缓存数据，兜底清理脏数据。
6.2.5 高并发极致强一致方案
针对金融、价格、库存等零容忍不一致场景，叠加Redisson分布式读写锁：
更新操作与查询操作抢占同一把业务锁；
保证读写与写写的时候按照顺序执行,读读相当于无锁；
彻底杜绝并发读写导致的数据错乱，实现毫秒级强一致。
6.2.6 方案选型总结
普通业务（低一致）：先更库、后删缓存，简单高效；
核心业务（中高一致）：同步删缓存 + MQ异步重试兜底；
金融核心业务（强一致）：分布式锁 + MQ重试 + 定时巡检三重保障。
七、实践总结
架构层面：优先多级缓存 + Cluster集群高可用，杜绝单点故障
防护层面：穿透、击穿、雪崩三重防护，流量层层兜底
性能层面：批量操作、精简命令、优化编码、治理大Key热Key
安全层面：混合持久化、内网隔离、密码认证、禁用高危命令
一致性层面：先改库后删缓存，核心业务MQ重试兜底,分布式锁完成强一致性要求
