企业官网建设流程全解析

五一前有个同学问我，说项目里 Redis 用得稀里糊涂，缓存、分布式锁、消息队列全用 Redis 扛，出问题又不知道从哪排查，想用一个整天把 Redis 系统过一遍。我跟他讲，一天速通 Redis 完全可行，但前提是别按官方文档从头刷到尾，也别上来就啃源码。速通的本质是先把主干长出来：数据结构怎么选、持久化怎么配、缓存三个经典事故怎么防、分布式锁怎么写才对。这四条线打通，Redis 的骨架就有了，剩下的细节是你以后踩坑时再补的。

这篇文章就把我当时给他画的路线原样整理出来，按"上午-下午-晚上"三个时间段展开。适合两类人：一类是写过几年代码但一直把 Redis 当黑盒的开发者，另一类是项目里 Redis 出了事故需要快速建立排查体系的同学。看完你会得到一个可执行的一天学习清单，也能直接带走一批生产环境验证过的方法。

1. 先回答最扎心的问题：Redis 到底能不能一天速通

1.1 一天速通的真正边界

能速通的东西，是 Redis 的核心心智模型：它是一台跑在内存里的单线程数据结构服务器。这句话你记住，后面所有命令、性能、原子性相关的疑惑都能用它推导。

单线程意味着什么？意味着所有操作都是串行执行的，所以单个命令天然原子。这也是为什么 Redis 能用来做分布式锁、做计数器，因为同一时刻只有一个命令在跑，不会出现两个线程同时改一个 key 的竞争问题。你不需要去理解复杂的并发控制。

但它同时也是瓶颈：如果有慢命令（比如一次keys *、一个大集合的smembers），后续所有命令都会排队等它执行完。所以我在生产环境几乎不用keys *，而是用scan分批遍历。这个习惯你速通时就要养成。

一天速通做不到的事情我也直说：你不可能一天内把 Redis 的源码级优化、集群运维、内存调优全部吃透。这些需要实际问题驱动。但你可以做到：拿到任何业务需求，能判断出该用五种数据结构里的哪一种；Redis 出现卡顿或丢数据，你能从持久化配置、过期策略、bigkey 三条线去排查；面试或技术评审时，分布式锁、缓存穿透这些经典话题你能说出原理和方案。

1.2 把一天拆成三块的执行地图

我的建议是把一天分成三个大块，每块三到四小时，中间留出动手敲命令的时间。

上午（约3.5小时）：数据结构与命令。这一块是地基。别急着敲命令，先想清楚每种数据结构的"形状"和"典型生活场景"：字符串是一个盒子，哈希是一个对象，列表是一条管道，集合是一个袋子，有序集合是一个带分数的排行榜。脑子里有这些画面，命令就记住了大半。

下午（约4小时）：持久化与缓存策略。这阶段解决两个生产环境最常见的问题：数据会不会丢、缓存会不会把数据库打死。RDB 和 AOF 怎么选、缓存穿透/击穿/雪崩怎么防，全部在这块讲透。

晚上（约3小时）：分布式场景与查漏补缺。分布式锁、事务、Lua 脚本、Pipeline，这些是面试高频区，也是你在真正项目中拉开差距的地方。最后留一小时，用我说的例子自己动手跑一遍。

提示：我说的"一天"是按可以连续拿出约10小时估算的。如果你只能碎片化学习，那建议把上面的三块拆成三天，顺序不要乱。

2. 上午重头戏：五大数据结构才是 Redis 的立身之本

2.1 字符串 String：不只是缓存键值

字符串是最简单的结构，但很多人用不精。除了最常见的缓存对象（把 JSON 序列化后扔进去），还有三个高频场景你应该立刻记住。

计数器。INCR命令能把 key 对应的值加一，这个操作是原子的。秒杀库存、文章浏览量、接口限流都可以用它。我之前做过一个每日签到系统，就是用INCR加EXPIRE实现的：签到一次INCR user:sign:{userId}，然后设置当天凌晨过期。代码量极少，还很稳。

分布式 ID。有些场景不需要 Snowflake 那么重，直接用INCR生成自增 ID 就够。注意它递增的起始值可以设置，所以能模拟出业务需要的起始编号。

限流/Sliding Window。SETNX配合过期时间可以做最简限流。说实话生产环境我更喜欢用 Redis 模块或者 Lua 脚本来做更精确的滑动窗口，但面试和入门阶段，INCR+EXPIRE的计数器限流方案必须能徒手写出来。

命令不多，核心就是SET、GET、MSET/MGET、INCR/DECR、SETNX、SETEX/EXPIRE。还有一个有点反直觉的：GETSET，先取旧值再写新值，在分布式锁续期、状态轮询场景里很实用。

2.2 哈希 Hash：对象存储的正确姿势

假设要缓存一个用户信息，用字符串你得把整个对象序列化成 JSON。但很多时候你只想更新这个用户的一个字段，比如改昵称。用字符串就是"整存整取"，你得先取出来反序列化，改完再序列化存回去。用哈希就是"存一个对象，字段级操作"。

具体操作：HSET user:1001 name "张三" age 26，只更新一个字段就HSET user:1001 age 27，不用动其他字段。读取也灵活，HGETALL拿全部，HGET拿单个。如果你把哈希的 key 设计成对象类型:ID，value 是字段集合，那就是一个非常自然的内存对象映射。

哈希还有一个容易交智商税的点：小哈希的内部编码是 ziplist，内存占用极低。也就是说，几百个字段的对象放进哈希里，比拆成几百个字符串要省内存得多。做缓存时如果追求极致内存效率，哈希通常优于字符串。

但哈希不是万能的。它没办法对单个字段设置过期时间，所以如果一个对象里需要不同字段不同过期策略，哈希就不好使，这时候要么拆 key，要么用字符串存整体。

2.3 列表 List：别只拿来当队列

列表的底层是双向链表（严格说是 quicklist），两头都能压入和弹出。最常见的用法是两个：消息队列和时间线/最新列表。

做简单消息队列时，LPUSH从左边塞，BRPOP从右边阻塞弹出。BRPOP的阻塞特性是精华：没有消息时它不会空转轮询，而是挂在那里等，有消息来立刻返回，还能设置超时时间。我在一些日活不高的内部系统里用它做过异步通知队列，省掉了引入专业 MQ 的成本。但注意，这种队列没有确认机制：消息弹出去消费者挂了，这条消息就丢了。真正要求不丢消息的场景，得引入专业消息队列，或者用 Redis Stream，这是你要记住的边界。

最新列表场景：比如一个资讯 App 的首页 feed，用户进来要看到最近几十条。用LPUSH把新内容推左边，然后用LRANGE key 0 49取前 50 条。配合LTRIM key 0 99，可以顺手把列表裁剪到最近 100 条，防止它无限膨胀。这个模式非常经典。

列表的另一个身份是栈：LPUSH+LPOP就是后进先出。撤销操作、浏览历史回退，都能用列表模拟。

2.4 集合 Set 与有序集合 ZSet

集合是无序去重的，天生适合做"人在不在这个圈子里"的判断。典型场景：抽奖去重、标签系统、共同好友。命令SADD往集合里加元素，SISMEMBER判断存在性，SCARD看集合大小，SINTER求交集（共同好友就是这个命令）。

有序集合 ZSet 是 Redis 里我最偏爱的结构，它等于集合去重 + 排序 + 分值更新。每个元素带一个 score，用ZADD写入，ZRANGEBYSCORE按分数区间取数据，ZREVRANGE按分数从高到低取。最经典的场景无需多言：排行榜。游戏日活榜、积分榜、热销榜，全是 ZSet。

它还藏着两个容易被忽略的玩法。

第一个是延时队列：把任务执行时间戳当作 score，用ZADD塞进 ZSet，消费者轮询ZRANGEBYSCORE key -inf 当前时间戳，取出来处理。取到一条就ZREM掉，所以同一个任务不会被重复取出。这个模式我用了很多次，比 List 做延时队列优雅得多。

第二个是滑动窗口限流：时间戳当 score，每次请求往窗口里加入当前时间，用ZREMRANGEBYSCORE把窗口外的旧数据清掉，再ZCARD看窗口内请求数是否超阈值。这个方案比INCR + EXPIRE精确，能精确控制"过去 60 秒内最多 100 次"，而不是"这一秒内最多 100 次"。

2.5 高级结构：看一眼就够的补充包

一天速通不用把高级结构全练熟，但几个名字和适用场景得有个印象。

• HyperLogLog：做 UV 去重统计，误差约 0.81%，固定占用 12KB 内存。用字符串存几百万个用户 ID 去重可能几十 MB，它只要 12KB。代价是只能判断存在与否，取不出具体元素。
• Bitmap：位图，适合做签到记录、在线状态。一个人一个 bit，几千万用户也就几 MB。
• Geo：地理坐标存储，算附近的人、距离排序。底层是 ZSet 实现，所以你可以用 ZSet 命令操作它。
• Stream：Redis 5.0 引入的专业消息队列，支持消费者组和消息确认。如果公司就是不想引 Kafaka，Stream 是一个还行的替代方案。

我的建议是前三个结构当天把命令跑一遍，Stream 留到真正需要时再系统学，一天内不用深究。

3. 下午第一站：持久化 RDB 与 AOF，别再凭感觉选了

如果说数据结构是上午的主线，下午第一个主菜就是持久化。Redis 是内存数据库，但你不能让它变成"重启即失忆"，所以要把数据落地到磁盘。

3.1 RDB 快照：压缩包与它的代价

RDB 是把某一时刻的内存数据全量打成压缩包存盘，恢复时相当于解压覆盖。优点是恢复极快，文件体积比 AOF 小，特别适合做备份和灾难恢复。

但 RDB 有个绕不开的短板：持久化之间有数据丢失窗口。它靠save/bgsave触发快照，save是阻塞式的，生产环境没人敢用；bgsave通过 fork 子进程做快照，主进程还能继续处理命令。但两次快照之间写入的数据，如果 Redis 崩溃了，这部分就没了。比如每 5 分钟做一次快照，那最后一次快照后 4 分钟写入的数据全部丢失。

bgsave的 fork 瞬间虽然不阻塞主进程太久，但大实例 fork 时内存会短暂翻倍，如果机器内存紧张，可能触发 swap，拖垮所有命令。这是我在生产环境真实碰到过的：一个 8GB 的实例，做bgsave时 fork 耗时接近一秒，监控面板明显看到延迟尖刺。所以大实例上 RDB 快照频率不能太高。

3.2 AOF 日志：每一步都有迹可循

AOF 记录的是写指令本身，以追加日志的方式存盘。你把SET name redis执行了，这条命令就会被追加到 AOF 文件。到 Redis 重放 AOF 文件，就相当于重放一遍历史写操作，数据自然恢复。

AOF 有三个刷盘策略：always（每条写命令都刷盘）、everysec（每秒刷一次）、no（交给操作系统决定）。三者数据安全性递减，性能递增。我个人的生产建议：默认用 everysec。它最多丢一秒的数据，但性能跟no差别不大。always数据绝对安全，但写入性能下降明显，只适合对数据安全要求极高的场景，比如存支付关键数据，而这种场景通常也不只靠 Redis 保底。

AOF 文件会无限增长，所以 Redis 有 AOF 重写机制：把最终状态压缩成最小的指令集合。比如你先SET k 1又SET k 2，重写后只剩一条SET k 2。重写由bgrewriteaof触发，也是 fork 子进程来做，所以它对主进程的影响和bgsave类似。

3.3 混合持久化：生产环境常用的实际选择

从 Redis 4.0 开始有了混合持久化：AOF 重写时，把当前内存数据写成 RDB 格式作为 AOF 文件的头部，新写入的增量指令继续以 AOF 格式追加。这样恢复时先加载 RDB 格式的数据，再重放少量增量命令，既有 RDB 的恢复速度，又有 AOF 的数据安全性。配置项是aof-use-rdb-preamble yes，Redis 5.0 之后默认开启。

到我写这篇的时间，我见过的大多数生产实例配置方式是：AOF 开启，刷盘 everysec，混合持久化开启，同时定期在低峰期做 RDB 备份。这样重启秒级恢复，崩溃最多丢一秒数据，还有 RDB 备份文件兜底做归档。

注意：不少云厂商的托管 Redis 默认配置跟标准的 Redis 不一样，有的默认只开 RDB，有的默认 AOF。上生产前你必须确认实例的持久化配置，不能想当然。我在排查一次"重启后丢了大半天数据"的事故时，最后发现就是某云实例默认只开 RDB、快照间隔又长，重启落在两次快照之间。

4. 下午第二站：缓存三兄弟——穿透、击穿、雪崩的攻防

这一节是全篇含金量最高的部分，因为我几乎每次帮人排查缓存事故，最后都会落到这三个问题上。

4.1 缓存穿透：查一个根本不存在的数据

场景是这样的：请求一个 key，缓存里没有，于是去查数据库，数据库也没有，于是什么都没写回缓存。下一次同样的请求来了，继续穿透到数据库。如果有攻击者故意请求大量不存在的 ID，数据库会被这些空查询压垮。

两个主流方案。

缓存空值：查不到也把一个空值缓存起来，比如存一个特殊标记，过期时间设短一点（一分钟）。这样相同请求在短时间内在缓存就命中了，不再打到数据库。这个方案简单粗暴，但要注意：恶意请求可能构造无限多个不同的不存在 ID，缓存空值会占大量内存。所以还得配合下面第二个方案。

布隆过滤器：一个很省内存的"存在性判断器"，它只能告诉你"一定不存在"或"可能存在"。把数据库里所有主键 ID 预加载进布隆过滤器，请求进来先问过滤器，说"不存在"就直接返回，说"可能存在"才放行去查缓存和数据库。布隆过滤器只是存在性过滤器，它说"可能存在"时实际上可能不存在（假阳性），所以它拦截的是"肯定不存在"的请求，但这一拦就挡住了绝大多数攻击流量。在大厂的数据链路里，布隆过滤器经常作为第一道防线。

说句实在话，多数中小团队最常用的是缓存空值，成本最低，业务逻辑也直白。布隆过滤器更省内存、更彻底，但需要额外维护一套数据同步逻辑。我的建议是：先看你的流量规模和 key 空间大小，小规模直接空值缓存，规模大到内存告急再上布隆过滤器。

4.2 缓存击穿：热点 key 过期的一瞬间

"击穿"和"穿透"长得像，但完全不同。击穿指一个非常热的 key 在过期瞬间，大量并发请求同时打向数据库。比如一个爆款商品的详情页，几千上万人同时刷新，缓存在某一刻过期了，所有请求都穿透到数据库。

两个经典解法。

互斥锁（Mutex）：发现缓存没有时，不直接查库，而是先去 Redis 里抢一把锁（SET key value NX EX）。抢到锁的线程才去查数据库，查到后写回缓存再释放锁。其余抢不到锁的线程短暂等待后重新读缓存，此时缓存通常已经由第一个线程重建了。这个方案实时性好，保证了只有一份请求打到数据库，但引入了加锁的复杂度，要小心死锁和锁过期。

逻辑过期（提前续期）：缓存里的 value 不止存数据，还带一个逻辑过期时间。数据过期后不清除，而是发现逻辑过期后返回旧值，同时异步后台线程去更新缓存。这是很多大厂在极端热点场景下的选择，因为"用旧值顶一下"比"大家排队等新值"的体验更好。实现上有讲究：需要保证只有一个后台线程去更新，否则还是会有多个请求同时查库，又变回击穿了。

我个人在电商大促期间更多用逻辑过期。因为互斥锁在极高并发下会让部分请求等待几十毫秒甚至上百毫秒，用户可感知。逻辑过期配合异步更新，用户几乎无感，代价是实现逻辑要严谨。

4.3 缓存雪崩：大面积过期引发的连锁反应

如果说击穿是"一个 key 过期",雪崩就是"大量 key 同时过期"。比如你的缓存统一设置过期时间是 10 分钟，那么某个整点，上一波写入的 key 集体到期，所有请求同时穿透到数据库，数据库直接被打爆。

解法有四个层次。

第一，过期时间加随机值。这是最简单也最有效的：SETEX key 600 + random(0, 300)，让每个 key 的过期时间错开。这是我在所有缓存写入逻辑里的默认操作，几行代码，效果立竿见影。

第二，多级缓存。Redis 之上再加一层本地缓存（比如进程内 Caffeine），Redis 大面积过期时，本地缓存还能顶住大部分读请求。代价是数据一致性更难保证，需要处理好本地缓存的失效问题。

第三，服务降级/熔断。真实大促系统中，数据库真的被打挂了，与其继续放流量进去，不如直接返回降级页或者默认数据。这属于高可用设计的兜底方案，不是缓存本身的问题，但和雪崩是配套的。

第四，持久化兜底。如果 Redis 本身崩溃重启导致缓存整体清空，这算另一种雪崩。物理上的恢复速度取决于持久化策略，所以上节讲的持久化配置这时候就看出了价值。

这三个"穿透、击穿、雪崩"是面试必考，也是你排查线上事故时的三个预设方向。我的习惯是面试考概念时一定把"为什么这三个问题分不开"讲清楚：穿透是数据不存在，击穿是单点过期，雪崩是批量过期，三者成因不同，防线也不同。

5. 晚上进阶：分布式锁、事务与管道，面试高频区

白天的主线把 Redis 的单机核心能力覆盖了，晚上的内容要往"分布式环境"走。你在这个项目里引入 Redis，通常不是单机玩具，而是面向多个服务实例共享数据。

5.1 分布式锁：从 setnx 到 Redisson 的演进之路

分布式锁大概是 Redis 被问得最多的话题。我不绕圈子，直接按代码演进给你讲。

第一版，很多人会犯的错误：

SETNX lock_key 1 // 执行业务逻辑 DEL lock_key

问题显而易见：SETNX和DEL之间业务代码如果异常退出，锁永远不释放。于是加过期时间：

SETNX lock_key 1 EXPIRE lock_key 30 // 执行业务逻辑 DEL lock_key

这版的问题是两个命令非原子：SETNX之后 Redis 崩溃，EXPIRE根本没执行，锁还是永不过期。正确做法是 Redis 官方后来支持的原子命令：

SET lock_key unique_value NX EX 30 // 执行业务逻辑 DEL lock_key

NX保证只有不存在时才设置成功，EX 30设置 30 秒过期，一个命令完成两件事。到这里，锁的基本安全性有了。但马上会遇到下一个问题：业务逻辑执行超过 30 秒怎么办？锁自动过期了，另一个线程拿到了锁，两个线程同时进临界区，锁形同虚设；或者等第一个线程执行完，直接DEL锁，但此时锁已经是别人的了。

解法一是给DEL加校验：删除前先比对 value 是不是自己当时写的那个唯一值。于是有了 Lua 脚本：

if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end

解法二是看门狗自动续期。这就是 Redisson 客户端干的事：拿到锁之后，后台线程每 10 秒（锁默认 30 秒有效期的一半）检查一次锁是否还在持有，如果还在就自动续期到下一个 30 秒。这样只要线程活着，锁就一直有效；线程死了，锁也活不过 30 秒，不会死锁。

我完整经历过从SETNX手写锁到 Redisson 的演进。结论是：能用成熟客户端就不要自己手写分布式锁，尤其是续期、重入这些边缘问题，手写 bug 率极高。但面试时你还是要能徒手写出SET命令加 Lua 脚本校验删除这条链路，因为很多面试官想确认的是你是否理解问题的本质。

补充一个争议点：Redis 分布式锁在极端场景下不满足绝对可靠，因为主节点故障切换时可能丢失锁记录。于是有 RedLock 算法，但它也存在争议。我的个人观点：大多数业务场景的锁不需要绝对可靠，REDIS 分布式锁结合过期时间、幂等接口设计，已经能满足 99% 的场景。真要求绝对安全，请往 ZooKeeper/etcd 这类带强一致性的协调服务走。

5.2 事务与 Lua：理解 Redis 的原子性边界

Redis 的事务是MULTI、EXEC、DISCARD、WATCH这一套。MULTI之后多条命令入队，EXEC一并执行。它跟数据库事务最不一样的点是：Redis 事务不支持回滚。如果一条命令语法错误，整体不执行；但如果是运行时错误（比如对字符串类型执行集合操作），这条命令失败，其他命令照常执行。这个特性让很多从关系数据库过来的人大跌眼镜。

真正用得多的其实是Lua 脚本。Redis 支持把一段 Lua 脚本作为单个原子性操作执行，脚本里可以包含逻辑判断、多个读写命令。之前的"删除前比对 value"就是典型案例。又比如我需要"扣库存后判断库存是否小于 0，小于就回滚"，用 Lua 写就是：

local stock = tonumber(redis.call('get', KEYS[1])) if stock <= 0 then return -1 end redis.call('decrby', KEYS[1], ARGV[1]) return stock - tonumber(ARGV[1])

这段脚本整体作为一个命令执行，中途不会被别的命令打断。你理解"Redis 单线程 + Lua 原子性"，很多分布式竞争问题就都有了简便解法。

注意 Lua 脚本不能太长，尽量控制在几 KB 以内，因为它是整段传过去执行的，过大既拖慢网络传输，也延长阻塞时间。

5.3 管道 Pipeline：把 RTT 省掉的省力杠杆

如果你在一个循环里调用GET key1、GET key2这种几十条命令，Redis 一次执行很快，但网络往返（RTT）累加起来很慢。Pipeline 就是把这几十条命令一次性打包发给 Redis，Redis 执行完一次性返回结果，RTT 从几十次变成一次。

业务上典型的场景是批量查询：给前端返回一个商品列表，每个商品都从 Redis 取详情。一条一条 GET，几百毫秒就出去了；用 Pipeline，十几毫秒搞定。我在做导出报表时就大量用过 Pipeline，几千个 key 的查询能在百毫秒内完成。

但 Pipeline 有个边界要记牢：它只是把命令打包发送，并不保证原子执行。对端 Redis 仍然是逐个执行这些命令，中间可能穿插其他客户端命令。如果你要求这批命令中间不被插入任何操作，那还是得上 Lua 脚本。

6. 一天结束前的最后两小时：查漏补缺与实战验证

到这里，白天和晚上的知识其实已经够实战了。最后两小时别急着学新东西，我建议你按下面的方式收尾，把零散的知识串成体系。

6.1 用一个真实业务场景串联所有知识点

你找一个自己最熟悉的业务，比如电商秒杀、论坛热帖、IM 离线消息，把白天学的东西全部套进去。我这里拿"秒杀"举个例子，你看是不是每个环节都踩到了前面讲的知识点：

• 秒杀商品详情缓存：String 存 JSON，加过期时间随机值防雪崩；
• 库存扣减：DECRBY原子操作，配合 Lua 脚本判断库存非负；
• 限流/防刷：INCR + EXPIRE做每用户每秒请求次数控制；
• 排行榜：ZSet 按秒杀热度排序；
• 用户是否已参与：Set 去重，秒杀前SADD判断；
• 分布式锁：防止多个服务实例重复处理同一个订单，用SET NX EX+ Lua 释放锁。

白天学的所有东西，在这一个场景里全部能用上。你能把上面这张表在脑子里过一遍，甚至动手在本地 Redis 里跑一遍命令，那这天的学习就真的落地了。

6.2 今天应该主动跳过什么

速通要有边界感，知道自己暂时不必碰什么，才能学得更高效。以下几点我建议你放到"待办清单"但不要放进今天：

Redis Cluster 的运维细节。集群模式、槽迁移、resharding、故障转移，这些内容很庞大。速通当天你只需要知道"Redis Cluster 是官方的集群方案，靠 16384 个槽分配 key"，具体运维踩坑留给真正的集群环境去练。

内存淘汰策略的细节调参。maxmemory-policy的几个选项（volatile-lru、allkeys-lfu等）需要知道有这回事，但不用今天把每个策略的源码机制抠清楚。真到内存吃紧那一步，你回去翻文档就行。

Redis 性能压测。redis-benchmark可以跑，但不要花时间研究各种压测姿势，这是线上调优时才需要的能力。

手写客户端/协议解析。这是极客玩具，不属于速通范围。

我现在回头看，当初在 Redis 上花的最值的一段时间，恰恰是这一天把所有核心概念串成一条主线的时候。以前每个知识点都见过，但都是碎片，真正理解了"Redis 是单线程的数据结构服务器"这句话，许多问题都会自动归位：为什么KEYS不能乱用、为什么 Lua 能保证原子性、为什么分布式锁要靠过期时间兜底。建议你按这条路线走完，周末找个下午把 Redis 装到本地（或者用云厂商的免费实例），按我的例子敲一遍命令，再回头看生产环境里那些"Redis 偶尔卡一下""锁好像没生效"的旧问题，思路会清晰很多。