热点数据放缓存、全量数据留关系库，这是当前互联网架构应对高并发读取的主流答案。缓存数据库（如Redis）和关系型数据库（如MySQL）不是替代关系，而是分工协作，缓存扛住流量峰值，关系库保证数据最终一致，二者组成双层结构,是目前性价比最高的热点数据解决方案。
为什么单靠关系库扛不住热点流量
关系型数据库的设计初衷是保证事务的ACID特性，它的数据存储在磁盘上，每次查询都要经过SQL解析、执行计划生成、磁盘I/O等完整流程。单机MySQL的QPS（每秒查询数）通常在1000到3000左右，这个数字在业务量小时完全够用，但一旦出现热点事件比如秒杀商品、爆款新闻、明星八卦流量可能瞬间冲到每秒几万次甚至几十万次读请求。
关系库面对这种流量会怎样？连接池被打满、慢查询堆积、CPU飙升，最终结果就是整个服务不可用。你不可能靠给MySQL加机器来解决这个问题，因为热点数据的读流量是突发性的，不是线性的，买一堆机器只为应对偶尔几秒的峰值,成本上完全划不来。
缓存数据库解决了这个痛点，Redis把数据放在内存里，单实例QPS可以轻松达到10万以上，是MySQL的几十倍，而且Redis支持分布式集群，可以线性扩展，这就是双层结构存在的基础：把读多写少的数据提前放入缓存，让大多数请求直接打在内存上，不给关系库添麻烦。
双层结构的核心分工与合作模式
缓存层做什么
缓存层只负责一件事：提供极速读取，它不关心事务，不关心持久化（或只做简单的RDB/AOF兜底），不关心复杂的关联查询，它的数据形态是KV结构，value可以是字符串、Hash、List、Set、ZSet等。
在热点数据场景下，缓存层只存与热点相关的信息，举个具体例子：一个电商系统的商品详情页，包含商品名称、价格、库存、描述、销售数据等信息，这些数据分散在MySQL的多个表里，如果每次请求都做多表关联查询，响应时间可能在几十毫秒以上，但如果提前把这几个表的数据组装成一个JSON串放入Redis，读取时间会缩短到1毫秒以内,体验完全不同。
关系库做什么
关系库承担数据最终落盘和事务型操作，用户下单、支付、库存扣减、订单状态更新，这些涉及资金和数据一致性的操作，必须由关系库来完成，缓存库在这个环节只做辅助比如用Redis的原子操作做库存预扣减,但真正的数据变更最终还是写回MySQL。
关系库还是缓存重建的数据源
，缓存中的数据不是凭空产生的，它从MySQL里查出来，序列化后塞进Redis，缓存过期或被删除后，下一次请求触发缓存重建，依然要从MySQL拉取数据，没有关系库做底,缓存就成了无源之水。
两者之间的协作流程
以一个典型的读请求为例：
- 请求到达应用层，先查询Redis
- Redis命中，直接返回缓存数据，流程结束
- Redis未命中，应用层查询MySQL
- MySQL返回数据后，应用层将数据写入Redis，设置过期时间
- 返回数据给调用方
写请求的路径略有不同：应用层先更新MySQL，再删除或更新Redis中的对应缓存，这个顺序非常重要先更新缓存再更新数据库在绝大多数场景下都是错误的，因为一旦数据库更新失败，缓存里就是脏数据,而且很难自动纠正。
如何判断哪些数据值得放入缓存层
不是所有数据都适合进缓存。缓存的价值在于命中率，如果缓存命中率低于60%，这个缓存设计就有问题，业内专家指出，一般建议命中率保持在90%以上才算健康。
适合放入缓存层的数据有以下特征：
- 读频率远大于写频率，读写比至少在10:1以上
- 数据量可控，不超过内存容量
- 对一致性的容忍度在秒级或分钟级
- 单条数据的组装成本较高，比如需要多表关联或复杂计算
不适合放缓存的数据包括：频繁变动的库存超卖数据（一致性要求极高）、用户私密信息（出于安全合规考虑）、超大文本内容（如全文检索结果，更适合用搜索引擎）。
用ZSet或Hash结构玩转热点榜单场景
Redis的丰富数据结构让热点数据的处理变得更加灵活，比如电商平台首页的“热卖排行”，如果用关系库来做，需要写复杂的分组聚合SQL，而且随着数据量增加，查询会越来越慢，用Redis的ZSet（有序集合）就非常合适。
思路是这样的：商品id作为member，销量或浏览量的加权值作为score，每次产生一次浏览或购买，就用ZINCRBY命令对对应商品的score做自增，查询排行榜时用ZREVRANGE取前N名即可，耗时微秒级,同时避免了关系库的实时计算压力。
热点数据通常时效性很强，今日热榜”需要在每天零点重置，可以用两个key轮换（比如hot_today和hot_tomorrow），在临近零点时提前切换，避免数据突变，或者给key设置合理的过期时间,通过Redis的过期机制自动清理。
缓存穿透、击穿、雪崩的应对策略
做双层架构时，最常见的坑不是Redis性能不够，而是三个经典问题,这里以热点数据场景一一拆解。
缓存穿透：查了一个不存在的key
一个恶意请求反复查询一个不存在的数据（比如一个不存在的商品id），Redis查不到，请求打了MySQL，如果有大量这种请求，MySQL直接被打挂,这就是缓存穿透。
最常见的应对方案是做空值缓存MySQL查出数据为空时，也把这个key写入Redis，value设置为空值或特殊标识，过期时间设置短一些（比如30到60秒），这样后续同样的请求就会命中空值缓存，放过了关系库，另外一个方案是使用布隆过滤器，把所有可能的热点id预先存入过滤器，请求先过过滤器,如果id根本不存在就直接返回。
缓存击穿：热点key瞬间失效
某个热点key过期的那一瞬间，大量请求同时发现缓存缺失，同时去查MySQL，后果非常严重，这不是量大的问题,而是时间点集中。
常见做法有两种：互斥锁和逻辑过期，互斥锁的做法是，缓存缺失后先获取一个分布式锁（比如用Redis的SETNX命令），只有一个线程能抢到锁去查询MySQL重建缓存，其他线程等待片刻后重新查询缓存，逻辑过期则是给缓存数据增加一个逻辑上的过期字段，实际key永不过期,但判断逻辑过期后异步重建缓存。
缓存雪崩：大量key同时失效
如果大量热点key的过期时间相同，它们会在同一时刻集体失效，请求全部压到MySQL。解决方案很直接：把过期时间设置成不同的随机值，错峰失效，比如基础过期时间是10分钟，加上一个0到60秒的随机偏移量，或者做多级缓存本地缓存（如Caffeine）作为Redis的二级缓存，即使Redis集群整体不可用,进程内缓存还能撑过一段时间。
缓存与关系库的双写一致性实践
业内共识认为，缓存和关系库的强一致是非常难做到的，实际工程中追求的是最终一致性,下面这套流程是多数团队采用的折中方案：
- 更新MySQL数据
- 删除Redis中的对应key（不是更新,而是删除）
- 下次读取时触发缓存重建
为什么是删除而不是更新？因为更新需要知道缓存中value的完整结构，业务耦合度高，而且并发情况下容易产生脏写，删除则干脆利落,让数据在下次读取时自然重建。
在并发较高时，上述流程有一个隐患：某个线程更新完MySQL后删除Redis，但在删除之前，另一个线程读到了旧缓存并重建了新缓存，导致旧数据被“复活”，业界针对这种情况有两个优化方向：
延迟双删更新MySQL后先删除缓存，等待几百毫秒，再次删除缓存，保证旧的缓存数据被彻底清走；或者基于binlog订阅（如canal）实现异步删除，由MySQL主从同步的binlog事件触发缓存清理,彻底解耦业务逻辑。
双层结构的成本控制与选型参考
Redis虽然性能强劲，但内存是昂贵的资源。集群模式下，Redis的存储成本大约是MySQL的5到10倍，因此只能存热点数据,全量数据留在关系库中和磁盘为伴。
成本控制的关键在于识别真正的热点数据,可以通过以下几方面来判断：
- 接口访问日志中筛选TOP N的请求路径
- 分析关系库慢查询日志，找到被频繁读取的表和查询
- 在应用层埋点统计key的访问频率
一个常见误区是“把整个MySQL表同步到Redis”，多数情况下这是不必要的，因为一条记录可能包含几十个字段，但热点业务可能只需要其中几个字段的组合结构。对原始数据做精简、聚合处理后存入缓存，既省内存又提高读取效率。
如果你的访问量没有到达一定级别，其实不建议上Cache-Aside架构，业务初期数据量小、并发不高时，直接在MySQL上加索引、建好从库，也能支持百万量级的数据存储和几千QPS的读取。双层结构的意义在于让扩展有梯度，当关系库达到瓶颈时，你能平滑地引入缓存层,而不是推翻重来。
热点数据双层结构常见场景问答
如何保证缓存和数据库的数据最终一致
业界通用的方案是Cache-Aside模式，查询时先读缓存，不命中则读数据库并回写缓存；更新时先写数据库，成功后删除对应缓存key，对一致性要求高的场景可增加延迟双删或订阅MySQL binlog进行异步缓存清理,两者都能有效降低数据不一致窗口。
Redis缓存数据库和MySQL性能差距到底有多大
单个Redis实例的读QPS可以达到10万以上，单次读取延迟通常在亚毫秒级，MySQL单实例在配置合理的情况下，QPS大约在1000到3000，读取延迟一般在1到10毫秒，两者的差距不是几倍，而是几个数量级,这就是为什么高并发场景必须让Redis挡在MySQL前面。
构建热点缓存层选择Redis还是Memcached
如果数据是简单的KV结构，不需要持久化，Memcached即可满足要求，但多数业务场景需要Redis提供的丰富数据结构（如ZSet用于排行榜，Hash用于存储对象），还需要持久化来应对重启场景，因此Redis是当前更主流的选择,社区活跃度和周边工具链也更为成熟。