Redis 是什么：为什么快、适合做什么、为什么常和 MySQL 一起用

前面几篇一直在讲 MySQL：它负责把业务事实可靠地存下来，靠事务、索引、锁和日志保证数据正确。现在切到 Redis，关注点会变。Redis 当然也能存数据，但它在系统里最常见的位置，不是替代 MySQL 做最终账本，而是站在高频访问路径上，给热点数据加速。

相关基础内容 对 Redis 的定义很明确：Redis 是一个开源的、基于内存的数据库，读写速度非常快，通常用作缓存、消息队列、分布式锁和键值存储数据库。它支持字符串、哈希、列表、集合、有序集合等数据结构，也支持事务、持久化、Lua 脚本、主从复制、哨兵、切片集群、发布订阅、过期删除和内存淘汰机制。

这些能力放在一起，Redis 更像系统里的高速工作台。MySQL 保存完整事实，Redis 保存那些经常被访问、可以加速、可以过期、必要时可以重建的数据。一个稳，一个快。真正用好 Redis，不是把所有查询都塞进去，而是知道哪些路径值得被它接住。

文中把 Redis 的第一个特点写成“基于内存”。这句话很短，却解释了它为什么快。MySQL 这类持久化数据库要考虑磁盘页、索引页、日志刷盘和崩溃恢复；Redis 把主要数据放在内存里，内存访问速度远快于磁盘访问，所以读写延迟天然更低。

这也是为什么缓存是 Redis 最典型的使用场景。比如商品详情、登录态、权限信息、首页推荐、热点文章、配置项，这些数据如果每次都从 MySQL 查，会把数据库压力拉高。放到 Redis 后，大量读请求可以在内存里完成，MySQL 只处理未命中、过期回源和真实写入。

不过，基于内存也意味着容量和成本要认真考虑。Redis 不是无限仓库。缓存什么、缓存多久、key 怎么设计、淘汰策略怎么选，都要和业务访问特征匹配。把低频、巨大、强一致的数据乱塞 Redis，速度优势很快会变成内存压力。

很多人刚开始会把 Redis 理解成 key-value 存储：给一个 key，取一个 value。这个理解能入门，但不够。资料 强调 Redis 支持多种数据结构，包括 String、Hash、List、Set、Zset。后面还提到 BitMap、HyperLogLog、GEO、Stream 等扩展类型。

多数据结构让 Redis 能更贴近业务模型。String 可以缓存对象 JSON，也可以做计数；Hash 可以存对象的多个字段，比如购物车里商品 ID 和数量；List 可以做简单队列；Set 有去重和交集能力，适合点赞、抽奖、共同关注；Zset 带分数排序，适合排行榜、延时任务和按时间排序的列表。

这就是 Redis 比普通缓存更灵活的地方。它不是只把一段文本存进去再取出来，而是用合适的数据结构减少应用层自己维护状态的麻烦。选错数据结构，代码会绕；选对数据结构，很多高频操作可以变得很干净。

文中还提到 Redis 支持原子性操作，也就是一个操作要么执行成功，要么完全不执行。这对并发环境很重要。比如访问次数加一、点赞数加一、库存预扣减、限流计数，如果多个请求同时改同一个值，普通读写很容易出错。

Redis 的命令执行模型让单条命令具有原子性。比如用 String 做计数时，多个请求同时执行递增命令，不需要应用先读值、再加一、再写回。这个过程如果放在应用里做，两个请求可能读到同一个旧值，然后互相覆盖。交给 Redis 的原子命令，冲突会少很多。

分布式锁也是类似思路。资料 在 String 应用场景里提到可以利用 `SETNX` 命令。它的核心是“只有不存在时才设置成功”。多个服务实例竞争同一把锁，只有一个能拿到成功结果。真正生产可用的分布式锁还要考虑过期时间、释放校验、续期和异常场景，但入口概念就是原子设置。

资料 说，虽然 Redis 主要是内存存储系统，但它可以通过快照和日志文件把数据持久化到磁盘，防止数据丢失。后面章节会展开 RDB、AOF 和混合持久化。这里先抓住一个边界：Redis 有持久化能力，不代表它就应该替代 MySQL 保存所有核心业务数据。

MySQL 的设计重点是结构化关系、事务一致性、索引查询、崩溃恢复和归档复制。Redis 的优势是低延迟、高并发、多数据结构和灵活的内存操作。它可以保存一些重要状态，也可以通过持久化降低风险，但大多数业务里，最终事实仍然应该落在 MySQL 这类持久化数据库里。

更稳妥的分工是：MySQL 保存用户、订单、支付、库存这类权威数据；Redis 保存热点缓存、短期状态、计数、队列、排行榜、会话和锁。Redis 中的数据最好能过期、能重建、能被 MySQL 或业务流程校正。

资料 对这个问题给了三个方向：高性能、高并发和丰富数据结构。Redis 读写非常快，对于频繁读写的数据，尤其缓存数据，性能优势很明显。把常用、频繁访问的数据放到 Redis，可以有效减轻 MySQL 等持久化数据库的压力。

高并发场景下，这个差异会更明显。假设一个活动页突然来了大量请求，大家都在查同一批活动配置、商品信息和库存展示值。如果每个请求都查 MySQL，数据库连接、查询执行和磁盘读取都会被放大。Redis 站在前面承接热点读取，可以让大量重复请求在内存里结束。

另外，Redis 的数据结构能直接表达一些 MySQL 不擅长的高频状态。排行榜用 Zset，去重集合用 Set，购物车字段用 Hash，消息排队用 List 或 Stream，访问计数用 String。MySQL 也能做这些，但在高频、低延迟、临时状态场景下，Redis 通常更顺手。

Redis 常被说成单线程，但这句话容易被误解。文中专门强调，Redis 单线程指的是网络请求模块使用单线程处理，其他模块仍会使用多个线程，Redis 程序本身并不是只有一个线程。

例如 Redis 2.6 会启动后台线程处理关闭文件、AOF 刷盘这类任务；Redis 4.0 之后增加 lazyfree 线程，用来异步释放内存。资料 解释原因也很直接：关闭文件、AOF 刷盘、释放内存这些任务都可能耗时，如果放在主线程里处理，主线程就容易阻塞，后续请求也会受影响。

Redis 6.0 之后，为了提高网络 I/O 并行度，还可以使用多个 I/O 线程处理网络请求。但命令执行仍然使用单线程处理。这样既能提升网络处理能力，又能保持命令执行模型相对简单。说 Redis 单线程，准确说法应该是：核心命令执行主要是单线程，不等于所有后台工作都只有一个线程。

资料 对这个问题总结了四点。第一，基于内存存储。数据放在内存里，读写速度远快于磁盘。第二，非阻塞单线程。单线程命令执行减少了多线程上下文切换，也避免了大量锁竞争和同步成本。

第三，高效的数据结构。Redis 专门设计了 String、List、Hash 等数据结构，不同操作能依赖合适的数据结构提升读写效率。第四，I/O 多路复用。Redis 可以同时监听多个 Socket，内核发现连接请求或数据请求后，再通知 Redis 处理对应事件。这样一个 Redis 线程也能处理多个 I/O 流。

这几条合起来，才是 Redis 快的原因。只说“因为它是内存数据库”不完整；只说“因为它单线程”也不完整。Redis 的快，是内存、事件模型、命令执行方式和数据结构一起作用的结果。

第一类是缓存。把热点对象、热点列表、配置、权限、会话这类频繁读取的数据放进 Redis，减少 MySQL 压力。第二类是计数。访问次数、点赞数、转发数、库存预扣减都可以借助 Redis 的原子操作。

第三类是分布式锁。多个应用实例抢同一个资源时，可以用 Redis 原子命令做互斥入口。第四类是共享 Session。文中提到，多台服务器都去同一个 Redis 获取 Session 信息，可以解决分布式系统下 Session 存储问题。

第五类是消息队列，List 和 Stream 都可以承接一些队列场景。第六类是排行榜，Zset 可以按分数排序，适合游戏积分、播放量、销售量、热度榜。先把这些场景和数据结构对应起来，再深入命令会更容易。

Redis 很快，所以容易被滥用。应用中最常见的问题不是不会 `get`、`set`，而是把 Redis 放错位置。强一致、长期保存、需要复杂关系查询的数据，应该优先回到 MySQL；热点读取、短期状态、可重建数据、高频计数，才更适合 Redis。

另一个问题是只考虑命中，不考虑失效。缓存什么时候过期，数据更新后删缓存还是改缓存，缓存没命中是否允许回源，Redis 故障时业务是否能降级，这些都要设计。没有失效策略的缓存，很容易变成旧数据的传播器。

所以学习 Redis 的第一篇，先记住一句话：Redis 是高速访问层，不是万能数据库。它和 MySQL 搭配得好，系统会又稳又快；边界混了，问题也会来得很快。