MySQL与Redis深度对比：原理、缓存一致性、分布式锁与项目实战

MySQL 和 Redis，一个是关系型数据库的绝对霸主，一个是键值对缓存和数据结构服务器的无冕之王。这两样东西几乎是后端项目、面试、架构设计里绕不开的标配组合。很多人单独用 MySQL 没问题，单独用 Redis 也能跑，但一旦要解释“为什么项目里要同时放着俩”“数据到底该放哪边”“缓存里的数据和数据库不一致了怎么办”就开始含糊了。

这篇文章不讲虚的，直接把这俩从底层原理、核心差异到项目里的真实用法和踩坑点掰开揉碎。无论你是准备面试的候选人、刚接手项目的新人，还是想把自己系统里那块“缓存”用得更明白的开发者，这篇文章都适合你完整读一遍。

1. 核心原理：一个住在磁盘里的老实人，和一个活在内存里的闪电侠

要搞懂 MySQL 和 Redis 为什么长得完全不一样，得从它们各自最底层的“生存方式”说起。

1.1 MySQL：关系型数据库的基石与 ACID 的守护者

MySQL 最核心的身份是关系型数据库管理系统。它的数据模型是“表”，表与表之间通过外键、JOIN 操作建立关系。想象一下 Excel 里的多个 sheet，Sheet1 是用户列表，Sheet2 是订单列表，通过“用户ID”这一列把两个表关联起来。MySQL 干的就是这件事，并且把它做到了极致，支持极其复杂的关联查询、子查询、事务和约束。

它把数据持久化存储在磁盘上。哪怕你突然断电、进程崩溃，只要数据落盘了，重启之后数据依然还在。这背后的核心是 MySQL 的 InnoDB 存储引擎。InnoDB 通过 redo log（重做日志）保证 crash-safe 能力：你在客户端执行一条 UPDATE 语句，InnoDB 会先把“我改了哪一页、怎么改的”顺序写入 redo log，然后再去更新内存中的 Buffer Pool，最后在合适的时机将脏页刷回磁盘。这套机制确保了即使数据库在中途宕机，重启后也能通过重放 redo log 来恢复数据，不会丢已经提交的事务。

另一个常被挂在嘴边的特性是事务的 ACID。A 是原子性，要么全部成功要么全部失败；C 是一致性，事务执行前后数据完整性不被破坏；I 是隔离性，多个事务并发执行互不干扰；D 是持久性，事务一旦提交，结果永久保存。InnoDB 通过 undo log 实现原子性和 MVCC 多版本并发控制，通过锁机制实现隔离性。这也是为什么银行转账、电商下单等强一致性的核心业务，无论如何都离不开 MySQL 这类关系型数据库。它也许不是性能最快的，但它是最稳的。

1.2 Redis：单线程事件循环下的数据结构服务器

Redis 的全称是 Remote Dictionary Server，很多人以为它就是个缓存，其实它是个在内存中运行的数据结构服务器。这句话有两层含义。第一，它所有的数据默认都驻留在内存里；第二，它不仅仅是简单的 key-value，而是支持 String、Hash、List、Set、ZSet（有序集合）、Bitmap、HyperLogLog、Geo 等多种高级数据结构。比如你想做排行榜，直接一个 ZSet，按 score 排序取 Top10，一条命令搞定，在 MySQL 里你可能要写一段带 GROUP BY 和 ORDER BY 的 SQL，还得建索引、优化分页。

Redis 的性能来源不只是“内存快”这一个朴素原因，更深层的是它的单线程模型。这里要先破除一个误区：Redis 6.0 之后虽然引入了多线程 IO，但真正的命令执行模块依然是单线程的。单线程意味着没有锁竞争、没有线程切换的开销，所有命令都是原子性的。一个简单的 INCR 命令之所以能安全地完成自增操作，不需要像 MySQL 那样用 SELECT ... FOR UPDATE 来加锁，核心原因就是因为它是单线程执行的，命令在内存中一个一个排队跑，根本不存在并发修改同一个 key 的问题。

Redis 虽然快，但也有一个绕不开的代价：内存是有限且昂贵的。所以 Redis 提供了持久化机制，通常是 RDB 快照和 AOF 日志。RDB 是定期把内存中的数据全量dump到磁盘，恢复速度快但可能丢失最后一次快照之后的数据；AOF 是以日志形式记录每一次写操作，数据更安全但文件体积大。需要注意的是，Redis 持久化更多是为了快速重启恢复，而不是像 MySQL 那样充当数据安全的最后防线。生产环境里 Redis 的角色定位是缓存和加速层，核心数据最终还是要落在 MySQL 里。

1.3 我必须要说清楚的一个底层逻辑差异

理解 MySQL 和 Redis 区别的钥匙在于数据是否必须持久可靠以及访问模式是随机读写还是极高频读写。

MySQL 的数据量通常可以达到 TB 甚至 PB 级别（通过分库分表），它可以承载海量数据的存储和复杂分析。但因为每次访问都要经过 B+ 树索引查找逻辑、可能涉及磁盘 IO、还要考虑事务和锁，所以单次请求的延迟通常在毫秒到几十毫秒之间，并发量高了之后，数据库连接数和磁盘 IO 会成为瓶颈。

Redis 呢？它的目标就是极致的低延迟，官方数据读写性能是 10 万+ QPS（每秒查询次数），延迟通常在亚毫秒级别。但它的存储成本高、容量受物理内存限制，通常也就几十 GB 到几百 GB。所以你看，它俩根本不是替代关系，而是互补关系。用一句话总结：MySQL 负责“把数据稳稳当当地存好”，Redis 负责“把最热的数据以最快的速度递到用户面前”。

2. 深入对比：MySQL 和 Redis 的六大核心区别

搞清楚了原理，我们就能用一张表把两者的差异讲透。

这张表里最值得展开讲的是数据模型差异带来的思维方式转变。

在 MySQL 里，你要设计表结构，定义字段类型、主键、索引、外键关系。数据必须满足范式要求，不能随便冗余。比如“用户订单”场景，你至少得拆成 user 表和 order 表。如果某天要查询“每个用户最近的 5 条订单”，SQL 可以写得很优雅，通过 JOIN 和窗口函数实现。但这个查询如果并发量特别大，MySQL 扛不住。

在 Redis 里，你首先要问的问题不是“怎么建表”，而是“我该用什么数据结构来表达这个业务”。同样一个“用户最近 5 条订单”的需求，Redis 的做法是给每个用户维护一个 List，每次下单往 List 左侧 LPUSH，查看最近订单用 LRANGE key 0 4。Redis 没有表结构的约束，数据是扁平的 key 和 value，它就适合做这种“按 key 直接定位、操作数据”的读写密集型场景。想把 Redis 当数据库用也行，但没有 SQL 那种灵活性，聚合、排序、关联都设计得不支持，除非你在客户端手动处理。

再聊一个面试高频争议点：MySQL 有事务，Redis 命令也是原子性的，那么 Redis 能替代 MySQL 做交易系统吗？我的观点是，绝对不能。Redis 的事务只是把多个命令打包起来顺序执行，中间不会穿插其他客户端的命令，但它做不到回滚。比如你用 MULTI 开启事务，里面有两条命令，第一条成功了，第二条由于语法错误失败了，Redis 不会把第一条也撤销掉。MySQL 的原子性则是要么全成功、要么全不生效。这种差异在金融场景里是致命的。

3. 项目实战用法：MySQL 和 Redis 是如何共事、分工配合的

原理和区别说完了，接下来是大家最关心的部分——在真实项目里，MySQL 和 Redis 到底是怎么配合的。

3.1 经典分层架构：MySQL 存底，Redis 加速

一个最典型、最被广泛采用的用法是 Cache Aside Pattern，也叫旁路缓存模式。流程是这样的：

1. 读请求过来，先查 Redis。
2. 如果 Redis 里有数据（缓存命中），直接返回，MySQL 根本不参与。
3. 如果 Redis 里没有（缓存未命中），去查 MySQL，查完后把数据写回 Redis，然后返回给客户端。
4. 如果是写请求，先更新 MySQL，然后删除 Redis 里对应的缓存（或者更新缓存）。

这个模式里有非常多的门道。为什么更新数据库后要删除缓存，而不是直接更新缓存？因为更新缓存这个操作不一定是幂等的，而且如果并发场景下有多个线程同时更新，顺序搞错就会导致缓存里的数据和数据库不一致。而删除缓存就简单直接得多，下一次读请求发现缓存不存在，自然会重新从数据库加载最新值。延迟删除还有一个名字叫 lazy loading，这是一种非常符合直觉的设计。

这里要特别提醒一个细节：很多初学者会把缓存写完就结课了，但在高并发下必须考虑“缓存击穿”问题。如果你的某个热点 key 在 Redis 中过期了，而恰好有海量请求同时涌来，这些请求会全部穿透到 MySQL。想象一下双十一零点，商品详情页的缓存突然失效，所有用户同时去数据库查这一个商品，数据库瞬间就被打崩了。解决方案是在查询数据库的代码上加互斥锁，保证同一时刻只能有一个请求去查库并回填缓存，或者对热点数据设置逻辑过期时间，在后台异步刷新缓存。

3.2 Redis 不只是缓存：分布式锁、计数器和排行榜实战

缓存只是 Redis 最基础的应用，真正让它在项目里不可替代的，是那几种高级数据结构衍生出的经典用法。

第一是分布式锁。单体应用时代，多个线程抢资源用 synchronized 就够了。但微服务架构下，多个服务实例可能部署在不同的机器上，JVM 级别的锁根本锁不住其他机器上的线程。这时候需要用 Redis 实现分布式锁：通过 SET key value NX PX 30000 命令，NX 表示只有当 key 不存在时才能设置成功，PX 表示过期时间。哪个服务实例能成功设置这个 key，就相当于抢到了锁。业务流程结束后 DEL key 释放锁。但这个用法有两个大坑：一是锁的过期时间必须大于业务执行时间，否则业务还没跑完锁就自动释放了，另一个线程就会进来造成并发问题；二是释放锁时不能直接 DEL，要先用 Lua 脚本比对 value 是不是自己当初设置的，防止误删了别人后来获取的锁。Redisson 框架里封装了看门狗机制自动续期，生产环境更推荐用成熟的库，不要自己手写。

第二是计数器。比如文章阅读量、商品点赞数、限流用的滑动窗口计数。这类场景有个极其简单的操作：INCR 或 INCRBY。在 MySQL 里做这个操作需要 UPDATE article SET read_count = read_count + 1 WHERE id = ?，虽然 SQL 很简单，但每次修改都要加行锁、记录日志、刷磁盘，并发量大了之后热点行更新会非常痛苦。而 Redis 的 INCR 天然就是原子的，单机轻松支撑几十万 QPS。常规做法是先用 Redis 攒着计数，每隔一段时间（比如 5 分钟）或者累计到一定数量后，批量异步同步到 MySQL 做持久化。

第三是排行榜。ZSet 提供了带权重的有序集合，每个成员有一个 score。玩家得分了，ZADD leaderboard score userId；想看 Top10，ZREVRANGE leaderboard 0 9 WITHSCORES。你甚至不需要做任何额外的排序逻辑。如果这个排行榜功能用 MySQL 实现，虽然 SQL 也能写出来，但每次刷新榜单都要做全表排序，索引再优化也扛不住千万级用户的高频查询。

还有 Bitmap 在位签到场景的应用。一个用户一年的签到状态，在 MySQL 里你得存 365 条记录，在 Redis 里只需要一个 key，初始长度 365 位，也就是不到 50 字节。每天的签到操作是 SETBIT key day 1，查询本月签到次数是 BITCOUNT key。这种空间和速度上的优势是传统关系型数据库无法想象的。

3.3 数据一致性：双写不一致的踩坑与解决方案

项目里最让运维和开发头疼的，永远是 Redis 缓存和 MySQL 数据库的数据不一致问题。根本原因是这两套存储系统之间没有原生的事务机制，你不可能写一个跨 MySQL 和 Redis 的分布式事务把两个操作捆绑在一起。

先分析双写不一致最典型的两个场景。

第一个是更新数据库成功，但删除 Redis 缓存失败。比如网络抖动，DEL 命令没发出去，或者 Redis 临时不可用。这时候缓存里残留的是旧数据，下一次读请求就直接命中了旧数据。解决思路是引入重试机制：把删除失败的 key 扔进消息队列，由消费者异步重试删除，或者使用更成熟的 Canal 监听 MySQL binlog，当检测到数据变更后，由 Canal 客户端主动删除对应缓存，完全不用侵入业务代码。

第二个是并发读写导致的交错问题。线程 A 读缓存未命中，去查数据库得到旧值 v1；线程 B 这时更新了数据库为 v2，并删除了缓存；线程 A 拿着 v1 回填缓存。最终缓存里是旧值 v1，数据库是 v2。这种问题用 Cache Aside 模式依旧无法完全避免。要彻底解决，一种方案是给缓存设置极短的过期时间，让不一致窗口缩短到可接受范围；更严格的方案是对 key 的写操作加分布式锁，串行化读回填和写删除操作。

我的个人经验是，做缓存架构前要想清楚业务能容忍多长的不一致窗口。比如商品名称、用户头像这类非关键信息，缓存 10 分钟不一致毫无问题；但库存、余额这类金额相关的数据，要么不缓存，要么必须用强一致方案，或者直接不引入 Redis 缓存，让请求全部走 MySQL。缓存不是银弹，在某些场景下反而不加缓存是最优设计。

4. 部署与运维要点：从单机安装到主从、集群的坑

理解了原理和用法，还得把环境搭起来才算真正落地。这里讲讲部署时最实用的几个环节和容易埋雷的地方。

4.1 本地环境搭建：Windows/Linux 下的安装细节

Windows 上安装 MySQL 的坑经常出在配置文件和服务注册上。自己解压安装方式，一般要新建一个 my.ini 配置文件，设置 basedir 和 datadir 路径，还要注意路径里的反斜杠要写成双斜杠。初始化数据目录用 mysqld --initialize-insecure，这样 root 账号默认密码为空，方便首次登录。很多新手在这里卡住是因为没有以管理员身份运行命令提示符，导致服务安装时权限不足。

Linux 上用包管理器安装相对省心。比如 CentOS 用 yum 安装，Ubuntu 用 apt，但也要留意版本源的问题。生产环境我更推荐用 Docker 安装，一条命令就能拉起 MySQL。这里要特别提醒数据持久化：一定要配置 -v 参数把容器内的 /var/lib/mysql 挂载到宿主机目录，否则容器一删除数据就全部消失。配置密码时用 MYSQL_ROOT_PASSWORD 环境变量，同时用 --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci 避免中文乱码问题。

Redis 的安装比较轻量。Windows 官方其实不直接支持，虽然有微软维护的移植版，但并不推荐生产环境使用。Linux 下源码编译安装也就是标准的 make && make install 流程。最简单的当然是 Docker：docker run --name redis -p 6379:6379 redis redis-server --appendonly yes，把 appendonly 参数打开就能启用 AOF 持久化。真正到生产阶段，你需要额外关注 protected-mode 的配置，建议设置 requirepass 强密码，并且 bind 内网 IP，绝对不要裸奔在公网上。

4.2 高可用架构：主从复制和哨兵/集群模式的取舍

Redis 的高可用门槛比 MySQL 低很多。最基本的架构是主从复制：一个 master 节点负责写，多个 slave 节点负责读。slave 通过 SYNC 或 PSYNC 命令从 master 同步数据，期间 master 会先把 RDB 快照传给 slave，然后再把后续的写命令通过 backlog 缓存区传给 slave。为了避免主从复制延迟导致读到旧数据，在强一致性要求的读场景中，路由过去时要把 key 的读请求也指向 master 节点。

比主从复制更上一层的是 Redis Sentinel 哨兵模式。Sentinel 是一个独立进程，它监控所有 Redis 节点的健康状态。当 master 挂了，Sentinel 通过投票机制选举一个 slave 提升为新的 master，并通知客户端更新连接地址。整个过程对客户端是基本无感知的。到了数据量更大的阶段，就需要 Redis Cluster。Cluster 把数据自动哈希到 16384 个槽位中，每个节点负责一部分槽位，客户端请求任意节点时，如果 key 不在这个节点，节点会返回 MOVED 错误并告知客户端正确的节点地址。这套架构解决了单机内存上限的问题，但也带来了不少额外复杂度，比如多 key 操作的命令受限、事务只能在同一个 hash slot 内执行。

MySQL 的主从复制和读写分离通常需要配合中间件或业务层路由来实现，架构复杂度和运维成本远高于 Redis。如果你只是想要缓存和性能加速，建议架构规划时不要一开始就引入 MySQL 的分库分表，尽量利用好索引优化和 Redis 扛住读压力，等单库实在扛不住再考虑拆分，否则系统复杂度会指数级上升。

4.3 运维监控与数据安全：运行时你必须持续盯着的指标

这一部分容易忽略，但往往是线上事故的根源。MySQL 方面，最需要盯的是慢查询日志。把 slow_query_log=ON 和 long_query_time=1 打开，所有超过 1 秒的查询都会记录到日志文件里。我一贯的建议是，任何线上接口的数据库查询超过 50ms 都值得分析，超过 1s 则必须立刻处理。另外用 SHOW PROCESSLIST 定期查看当前链接和执行中的 SQL，经常能发现某些 SQL 导致表锁或大量临时文件排序。

Redis 方面的核心监控指标是内存。INFO memory 命令可以看到 used_memory 和 maxmemory 的对比，如果 used_memory 达到峰值，默认情况下 Redis 会开始根据 maxmemory-policy 淘汰 key，默认策略是 noeviction（不淘汰直接报错），很多团队没有修改 maxmemory-policy 就上线，结果内存满了之后所有写请求直接报错，这种故障在日志上会显示为 OOM command not allowed when used memory > maxmemory。通常应该设置成 allkeys-lru，让 Redis 优先淘汰不常用的 key。另一个隐患是慢日志。由于 Redis 单线程处理命令，一条慢命令会阻塞后面所有的请求，导致整站卡顿。常见的慢命令有 KEYS *、HGETALL 大 Hash、SMEMBERS 大 Set。生产环境严禁使用 KEYS 遍历，正确替代是 SCAN 命令游标式遍历。

数据安全层面，Redis 建议开启 AOF 持久化，appendfsync 设置为 everysec，兼顾性能和安全性。MySQL 则一定要定期做全量备份，同时开启 binlog 用于增量备份和时间点恢复。云服务商如果提供了自动备份，也要定期做恢复演练，否则备而不测等于没有备份。

5. 面试与底层追问：几个必须烂熟于心的关键问题

这个话题在面试里出现频率极高，有些问题如果你只是背过八股文答案，被追问两三轮就会露馅。我整理几个常见的追问点，帮你把底层的逻辑链路打通。

5.1 MySQL 为什么用 B+ 树索引而不是红黑树或哈希索引

这几乎是索引章节必问的题目。B+ 树的非叶子节点只存索引key，不存数据，所以每一页能容纳更多的 key，树的高度通常只有 3 到 4 层。也就是说最多三四次磁盘 IO 就能定位到一条记录。而红黑树是二叉树，高度远高于 B+ 树，在数据量大时磁盘 IO 次数会多得多。哈希索引虽然单条查询快，但它没法支持范围查询，比如 WHERE id > 100，哈希完全无能为力。B+ 树的数据全部排在叶子节点，并且叶子节点之间用指针连接，天然支持顺序遍历和范围查询。这就是数据库索引选型背后的物理存储逻辑。

5.2 Redis 为什么快？除了内存还有其他原因吗

只答“因为存在内存里所以快”是一个巨大的减分项。更完整的回答要包含三点。第一，数据在内存，避免磁盘 IO；第二，单线程模型避免了锁竞争和上下文切换开销；第三，使用 IO 多路复用技术，基于 epoll 事件驱动，单线程可以高效处理大量并发连接；第四，Redis 的很多数据结构做了精心优化，比如压缩列表、跳表、整数集合等，在数据量较小时大幅压缩内存占用和访问时间。这四点连起来才是一个有深度的答案。

5.3 缓存穿透、击穿、雪崩三个词怎么区分和应对

这三个词经常被混为一谈，实际场景和解决方案有微妙差异。

缓存穿透是指查询一个一定不存在的数据，缓存和数据中都没有，所以请求总是打到数据库。攻击者可以伪造大量不存在的 ID 发起查询，数据库瞬间被打垮。应对方案是缓存空值并设置较短过期时间，或者使用布隆过滤器在请求缓存之前先过滤掉明显不存在的 key。

缓存击穿是指某个热点 key 过期的瞬间，大量并发请求同时打到数据库。应对方案是设置热点 key 永不过期，或使用互斥锁保证只允许一个线程查询数据库并回填缓存。

缓存雪崩是指大规模 key 在同一时间集中过期，比如缓存预热时所有数据设了相同的过期时间，造成请求瞬间全部落到数据库。预防方案是过期时间加随机数打散，或者使用多级缓存架构，把一部分热点数据放入本地内存缓存作为兜底。

三个问题都发生后系统的表现不一样，解决的侧重点也不一样：穿透重点在过滤不存在的数据，击穿重点在保护热点 key，雪崩重点在分散过期时间。

5.4 分布式锁到底能不能用 Redis SETNX 实现？聊聊 Redlock

简单业务场景下，SETNX 加过期时间确实够用。但面试官可能会追问，如果 master 节点在设置锁成功后、数据同步到 slave 前挂掉了，slave 提升为 master，这时另一个客户端也能成功设置同样的 key，这就导致两个客户端同时获得了锁。Redis 官方提出了 Redlock 算法解决这个问题：向集群中超过半数（N/2+1）的独立 Redis 节点依次尝试加锁，只有大多数节点都加锁成功才算获取锁成功。但这个方案在业界有争议，因为 Redis 的异步复制和故障恢复仍然有微小的窗口期无法彻底解决。普通业务用 SETNX + 看门狗工具类就够了，如果是金融级的强一致锁，建议使用 ZooKeeper 或 etcd，它们基于 Paxos/Raft 共识算法能提供更严格的线性一致性。

5.5 MySQL 事务隔离级别和 MVCC 怎么理解

面试问到事务隔离级别，一定要答清楚默认的 RR（可重复读）和 Oracle/PostgreSQL 默认的 RC（读已提交）之间的差异。InnoDB 的 RR 级别下，通过 MVCC 多版本控制极大减少了锁竞争。每条记录在更新时会生成一个隐藏的 roll_pointer 指向 undo log 里的旧版本，同一个事务内的 SELECT 快照读只能看到事务开始前已提交的版本或者自己修改的版本，从而保证可重复读。RR 级别下还存在一个常见的坑——幻读，InnoDB 通过间隙锁和 next-key lock 来解决，这在范围查询时会对索引记录之间的间隙加锁。理解这个之后，很多死锁问题本质上就清晰了——它就是为了解决幻读带来的锁开销。

6. 项目选型避坑：什么时候该用 Redis，什么时候别硬用

很多业务想引入 Redis。技术热情能理解，但缓存架构要承担额外的数据一致性成本、运维成本和故障风险。分享一下我在实际项目选型时的一套判断思路。

有一种典型的错误认知是，把 Redis 当主数据库，MySQL 只做异步落盘。除非业务对数据丢失容忍度极高，比如用户的实时在线状态、阅读量这种丢了也无所谓的统计，否则不建议这么设计。Redis 的内存注定无法承担海量数据，Redis 的持久化机制也做不到像 MySQL 那样精细到行级崩溃恢复。另外 Redis 的淘汰策略在内存满时会对数据“无差别攻击”，哪怕是正在使用的数据也可能被淘汰。

还有一种情况是团队对缓存一致性处理没有足够经验却草率引入 Redis。比如某些管理后台系统，每天访问量只有几百次，数据库查询本来就几毫秒完成，引入 Redis 后反而要处理缓存更新、穿透、过期，纯粹是给自己找麻烦。

反过来，以下几种场景是 Redis 的“主场”：数据读取量远大于写入量，且读响应时间要求极高的场景；存在复杂计算的高热数据，比如排行榜、在线人数统计；需要跨服务共享状态，比如分布式锁、分布式限流；需要临时存储，比如短信验证码，Redis 的 EXPIRE 自动过期机制天然适合。

选型底层逻辑其实就是算一笔账：引入 Redis 后需要保证数据最终一致性的代价，是否小于直接提升 MySQL 硬件配置或简单加索引的代价？高性能不等于高复杂度，项目里简单直接的技术方案，往往才是长期维护成本最低的。

7. 一个完整的实战案例：用 MySQL + Redis 构建高并发商品详情页

光说理论不过瘾，我们走一遍贴近真实业务的案例，演示如何用 MySQL 存储商品基础数据、Redis 构建商品详情页缓存和热点统计。

7.1 表结构与缓存 Key 设计

假设商品表 product 结构是指定的主键 id、商品标题 title、价格 price、库存 stock、详情描述 detail。同时还有一个统计表 product_views 记录商品浏览量。这是 MySQL 负责的“事实层”。

Redis 这边，我用 Hash 结构缓存商品详情，key 设计为 product:detail:{productId}，field 是 title、price、stock、detail 等字段。之所以用 Hash 而不是直接序列化成 JSON 字符串，是因为 Hash 支持单独更新某个字段，比如库存变化时只 HMSET 一个 stock 字段即可，不必像字符串那样先 GET 整个 JSON 反序列化再重新 SET 回去，能省掉一次大对象读写的开销。

浏览量计数直接用 INCR product:views:{productId}，先累计在 Redis 里，再通过定时任务批量回写 MySQL，避免频繁直接更新商品表的行记录。

7.2 读取链路的完整实现

商品详情读取时，先查询 Redis Hash。实际代码逻辑类似这样（伪代码形式），核心逻辑分为三步走：

text复制1. 根据 productId 拼接缓存 key，尝试 HGETALL 获取 Hash
2. 如果 Hash 非空，说明缓存命中，直接返回结果
3. 如果 Hash 为空，查 MySQL 的 product 表，若记录存在则 HMSET 写入 Redis，设置过期时间 30 分钟，再返回结果

这个流程看似简单，实际生产环境里“缓存穿透”防护是必做的。我习惯是第一步先查布隆过滤器，如果布隆过滤器判断该 productId 不存在，直接返回商品不存在，不再往下走到 Redis 和 MySQL。只有布隆过滤器判断可能存在时才继续查缓存。

7.3 写入链路的库存扣减策略

最简单的方案是在 MySQL 里执行 UPDATE product SET stock = stock - 1 WHERE id = ? AND stock > 0，通过 affected rows 是否大于 0 来判断是否库存充足。这个 SQL 的原子性由数据库行锁保证，不会超卖。

引入了 Redis 后思路要变一下。下单时先在 Redis 端做预扣减，用 DECR product:stock:{productId}，如果扣减后的值小于 0，立即回滚 INCR 并返回 “库存不足”。如果库存足够，再异步发送消息让消费者去更新 MySQL 的库存。这种方案能抗高并发下的秒杀流量，把压力从数据库转移到 Redis。

但要注意，缓存和数据库之间的库存是短暂不一致的，Redis 的库存已经被扣了，而 MySQL 还没更新完成。如果此时 MySQL 更新失败，需要做补偿操作把 Redis 的库存加回来。如果订单超过一定时间未支付，系统会自动取消订单并回补库存，回补时同样先更新 MySQL，再删除 Redis 缓存由后续读取重建。这一步骤的一致性保证要靠消息队列的重试机制来完成，不是简单的同步调用。

7.4 缓存更新策略总结

这个案例中 Redis 只是加速层。基础数据如标题、详情，可以设置 30 分钟自动过期，即使缓存丢失，读取时重新查库回填即可。库存数据相对敏感，需要及时同步。浏览量数据即便延迟 5 分钟写入 MySQL，对业务也没有实质影响。

针对不同业务场景设计不同的缓存时间和更新策略，是架构师的核心考量，而不是简单粗暴地所有数据一律缓存半小时。

8. 写在最后的实战经验与建议

这篇文章的内容到这里已经把 MySQL 和 Redis 的原理差异、项目用法、部署方案、面试要点、实战案例讲透了。最后分享几点我个人多年开发运维下来最深刻的体会。

第一件是警惕滥用 Redis。每当我看到有些团队把所有表数据无脑缓存进 Redis，美其名曰“加速”，实际上数据库和缓存之间的一致性维护已经成为整个系统最不可控的风险点。缓存是架构里的“优化手段”，而不是“必选项”。加缓存前先问：查询真的慢吗？慢是因为没有索引吗？能通过加索引解决吗？如果数据库查询本身只要 5ms，加了缓存虽然能到 1ms，但架构复杂度和一致性风险大幅上升，这 4ms 的收益不值得。

第二件是重视缓存过期时间设置的工程习惯。热点 key 如果集中过期，就会引发雪崩。长期维护下来我的习惯是：所有缓存的过期时间必须加一个随机秒数，比如 TTL = 基础过期时间 + random(0, 300)。这个简单的习惯，省去了很多线上“定时雪崩”的麻烦。

第三件是代码里的缓存逻辑一定要收敛。不要在每个业务代码里直接写 Redis 读写命令，而是封装成一个缓存工具类或者独立的 Cache Service。后续如果要给 Redis 加监控、加清理策略、切换序列化方式，只需要改动一个类。很多项目前面开发很爽，后面维护缓存逻辑时东改一处西改一处，彼时真的会非常痛苦。

MySQL 和 Redis 是后端开发的两条腿，缺了哪一个项目都跑不稳。但理解它们的边界，尊重它们各自的优势，不强行让一个工具去做另一个工具擅长的事，才是真正吃透了这两个技术。希望这篇文章对你有帮助，也欢迎你在实际使用中有不同的心得见解，一起讨论进步。