缓存数据库通过内存读写缓解主库压力的基本原理
缓存数据库的本质，是用一块高速内存层，把高频读请求从主库磁盘上“截胡”，让主库只处理写操作和少量读漏，多数互联网业务的读请求占比超过80%，这一层内存缓冲能直接挡住大多数请求，主库的CPU和磁盘I/O压力自然降下来。
整套机制的核心逻辑并不复杂：业务请求先走缓存，缓存有数据就直接返回，没有数据才让请求落到主库，主库查完后，把结果回填给缓存，下一次同样的请求就直接从缓存走，这个“先查缓存、再查主库、最后回填”的路径，是Redis、Memcached等缓存系统最常见的用法。
内存读写比磁盘快在哪些地方
内存和磁盘的读写延迟不在一个数量级上。内存随机读写的延迟通常在纳秒到微秒级，而磁盘随机读写的延迟在毫秒级，两者相差几百倍甚至上千倍，更关键的是，磁盘在高并发下存在寻道和排队延迟，一旦并发线程数上来，响应时间会急剧劣化，内存没有机械寻道过程，数据通过总线直接访问,吞吐量远高于普通磁盘。
MySQL这类关系型数据库，数据最终落在磁盘上，即便是SSD，并发写入时也要面对刷脏页、WAL日志落盘、redo/undo维护等开销，主库的磁盘I/O一旦达到瓶颈，整体查询延迟随之升高，缓存数据库把“热数据”长期驻留在内存里，大部分读请求根本不触达磁盘，主库的磁盘I/O压力就只来自写操作和缓存未命中的读请求。
命中率是缓存能够缓解主库压力的前提
缓存数据库不是万能药，它的效果取决于一个核心指标缓存命中率，命中率越高，打到主库的请求越少,缓解压力的效果越明显。
行业共识认为，命中率在90%以上，主库压力能降低一个量级；命中率低于70%，缓存的意义就大打折扣,影响命中率的主要因素有三个：
- 数据热度集中度：电商商品、新闻热点、用户会话天然符合“少数数据被多数请求访问”的幂律分布,适合做缓存。
- 缓存容量与淘汰策略：Redis默认的LRU（最近最少使用）淘汰策略，能够在缓存空间不足时，优先淘汰最久未被访问的数据,保留热点数据。
- 过期时间设计：过期时间设置太短，缓存频繁失效导致缓存穿透；设置太长,数据更新后客户端迟迟读不到新值。
缓存预热提升命中率
系统刚启动或大促前，缓存是空的，此时大量请求会直接打到主库，称为缓存冷启动，解决办法是
缓存预热：把常用数据预先加载到缓存中。
大促场景下，运营活动开始前几小时，工程团队会跑批任务把商品详情、库存数量提前写入Redis，这在秒杀系统中是标准操作，没有预热直接上线,缓存和主库都会被打穿。
缓存数据库和MySQL主库如何配合
大多数业务系统的存储架构，是将MySQL作为最终数据归属地，Redis作为MySQL的“挡箭牌”,具体配合流程如下：
- 读请求到达时，先查Redis,命中则直接返回。
- 未命中时，查询MySQL，查询成功后把结果写入Redis,并且设置合理的过期时间。
- 下次相同请求，从Redis读取,不再触达MySQL。
这个流程在登录会话、商品详情、配置中心等场景下非常实用，核心数据以MySQL为准,Redis只是短暂保存一份副本。
写请求的数据一致性处理
写操作是缓存与主库配合中最容易出问题的地方，常用的方案有Cache Aside旁路缓存策略：
| 步骤 | 操作 | 说明 |
|---|---|---|
| 1 | 先更新MySQL | 以数据库数据为准 |
| 2 | 再删除Redis缓存 | 不是更新缓存，而是删除缓存 |
| 3 | 下次读请求未命中 | 从MySQL读最新数据并回填Redis |
很多团队纠结“先更库还是先更缓存”，经验答案是更新数据库后删除缓存，而不是直接改缓存，因为直接改缓存存在并发问题：两个线程同时改缓存和数据库，后写的可能覆盖先写的，导致最终缓存里的数据不是最新值，删除缓存则让下一次读请求从库里拉取最新数据,天然规避了这个问题。
延迟双删方案
高并发场景下，线程A更新完数据库删除缓存后，线程B刚好在删除前读到旧数据并把旧值写回缓存，针对这个问题，常见做法是延迟双删：先删除缓存，再更新数据库，结束之后短暂等待几百毫秒，再次删除缓存,确保无残留旧数据。
这个方案在数据一致性要求极高的场景下使用,操作耗时也相应变长。
Redis缓存数据库与MySQL数据不一致怎么处理
缓存和主库的数据不一致，是Redis缓存数据库与MySQL数据不一致这个问题的高频搜索词，也是工程面试常问点，不一致的根源在于两个存储系统的写入时机天然交错,没有事务能同时保证两边原子提交。
解决思路不是消灭不一致，而是控制不一致的时间窗口,让数据尽快趋于一致。
过期时间兜底策略
Redis给每个Key设置一个合理的过期时间，过期时间一到，缓存自动清除，业务自行回源MySQL,从而修复不一致状态。
过期时间的选择有讲究，太短导致命中率下降，主库压力回升；太长则业务长时间读到旧数据，一般业务数据的过期时间设置在半小时到两小时之间,频繁变化的库存类数据控制在几秒以内。
binlog订阅异步刷新
更彻底的方案是监听MySQL的binlog变更日志，当数据库有数据更新时，通过Canal等中间件把变更信息同步出去,然后主动刷新Redis中的对应缓存。
这个方案比延迟双删更可靠，缺点是增加了系统复杂度，需要维护一套binlog解析和消息队列组件，一般用于配置类、商品类等变更频次不高但一致性要求高的数据。
电商秒杀场景下缓存怎么扛住流量峰值
电商秒杀是缓存数据库最极端的落地场景，也是网上“电商秒杀场景redis缓存怎么设计”这类搜索词最集中的话题，秒杀业务的特点是瞬时并发极高、读写比极端不平衡、热点Key集中在一个商品上。
秒杀场景的常见设计方案
- 三级缓存架构：浏览器/CDN层面缓存静态页面，应用本地进程内缓存兜底,Redis缓存承载库存和预热数据。
- Redis预减库存：秒杀开始时，把库存数量先写入Redis，用户请求先对Redis库存做预扣减，扣减成功才生成订单,MySQL只负责持久化最终订单。
- 热Key打散：把同一个商品的库存拆分成多个子Key分散在Redis集群的不同节点上,避免单个热Key的集中访问压力。
缓存击穿与雪崩防护
秒杀场景中，热点商品的缓存刚好过期，同时大量请求过来，这会导致缓存击穿，请求全部落到MySQL，秒杀结束,应对措施包括：
- 热点Key的过期时间不设置,改为手动更新。
- 互斥锁控制回源：Redis没有命中时，只有拿到锁的线程可以查MySQL,其他线程自旋等待。
- 过期时间加上随机偏移量,避免同一时刻大量缓存集中失效引发雪崩。
自建Redis和云数据库Redis怎么选
缓存数据库的部署方式直接关系到成本，自建Redis需要关注租用服务器、内存和带宽成本，还要考虑运维人员的时间投入，一台16GB内存的云主机，在北京或上海机房，
每月租用成本相当于一个初级运维工程师半天工资，但对于中小企业来说,多一台机器就多一份运维负担。
云数据库Redis的优势在于开箱即用、免运维、支持自动故障切换，按实例付费，规格从几GB到上百GB可选，与业务量匹配，价格上，云数据库Redis通常比自建方式贵30%-50%，但省下的运维时间和高可用保障更划算，对于大多数中小型业务，直接购买云数据库Redis是最稳妥的选择，华东地区企业通常选择上海或杭州节点，网络延迟比华南、华北低10毫秒以上。
选型要点
- 缓存数据量：建议按业务热数据总容量的1.5倍预留Redis内存。
- 并发峰值：QPS超过10万时，单机Redis已吃紧，需要考虑Redis Cluster集群模式。
- 持久化需求：单纯热数据缓存，关闭AOF持久化，性能更高；奖金发放、订单状态等不可丢失场景，开启AOF且设置appendfsync everysec。
- 地域选择：选用与MySQL同地域的云Redis，跨地域访问的网络开销一般超过5-10毫秒。
常见问题解答
缓存数据库会丢失数据吗？
Redis默认启用RDB快照和AOF日志持久化机制，RDB定期把内存数据写入磁盘，AOF记录每条写命令，即使实例重启，通过AOF重放也能恢复大部分数据，云数据库Redis会同步保存多份数据副本，在单节点故障时，主从切换后数据依然存在，发生单节点故障,多数情况下不会丢失数据。
缓存穿透怎么防止？
缓存穿透是指查询一个根本不存在的数据，缓存没有、数据库也没有，每次请求都打到数据库，常规做法有两种：对空结果也做缓存，设置较短的过期时间；或者使用布隆过滤器，在查询缓存之前先过滤掉不存在的Key，这两种手段结合起来，绝大多数穿透流量在到达MySQL前就被拦截,数据库本身承载的无效查询能够减少相当一部分。
缓存和数据库的性能差距到底有多大？
高性能硬件条件下，Redis单实例读性能通常能达每秒十万次以上，而MySQL单实例简单查询通常每秒数千次，从延迟上看，内存读取大多在微秒级别，而磁盘随机读在毫秒级别，两者的吞吐量差距可能达到两个数量级，缓存数据库承担了大多数高频读请求后，主库只需要处理写操作和少数读请求，磁盘I/O和CPU占用率都会明显回落,整体业务响应时间变得稳定。