Redis核心应用场景实战：缓存、分布式锁、集群与性能优化

聊到 Redis 核心应用场景，后端的第一反应通常是“缓存”，但缓存只是它能力的入场券。我在前后端都折腾过的这几年，Redis 在项目里承担过分布式锁、排行榜、附近的人、幂等记录、队列削峰，甚至临时数据结构中转站，几乎没有哪个项目能完全绕开它。这篇文章没有教科书式的罗列，而是把 Redis 从安装落地到实际场景的整个路径走一遍，你会看到每个方案背后的取舍，也会看到我踩过的那些不太体面的坑。适合刚上手 Redis 的开发者，也适合准备把它用到生产环境的团队。

很多人会背 Redis 面试八股文，但一落到具体需求就不知道用哪种数据类型；也有人把缓存穿透、缓存雪崩当概念挂在嘴边，真出问题时又分不清是击穿还是穿透。所以我打算从“跑起来”开始，一路讲到缓存治理、分布式锁、持久化、集群和实战排查，最后附上高频命令速查。每个场景我都会给结论、给步骤、给坑，这样你在自己的项目里可以直接照着做。

1. 先让 Redis 跑起来：安装、连接和第一次启动

1.1 不同环境下的安装姿势

很多初学者卡在第一步。Redis 官方其实明确表示不支持 Windows，但开发机是 Windows 又是大多数人的常态。这里我给出三种可行的路线，按我的推荐程度排序。

• Docker 方式最省心。安装 Docker Desktop 后，执行docker run -d --name redis -p 6379:6379 redis:7.2，然后docker exec -it redis redis-cli ping就能看到 PONG。想要带配置启动，就把 redis.conf 挂载进去，docker run -d -p 6379:6379 -v /my/redis.conf:/etc/redis/redis.conf --name redis redis:7.2 redis-server /etc/redis/redis.conf。
• WSL 方式次之。在 Windows 上装好 WSL 后，进 Ubuntu 里执行apt install redis-server或者去 Redis 官网下载源码编译，体验和 Linux 一致。
• 社区版 exe 不建议用于生产。像 redis for windows 5.0.14.1 这类封装版在本地练练手可以，但版本落后，还可能踩到文件句柄和内存映射的坑。Windows 上的 redis windows 下载包很多，真要选，认准官方仓库里由社区维护的版本。

macOS 就简单多了。有 Homebrew 的话，brew install redis装完直接brew services start redis，开机自启也帮你搞定了；不想常驻的话就redis-server /opt/homebrew/etc/redis.conf手动起。Linux 服务器上的安装就更套路：Ubuntu/Debian 用apt install redis-server，CentOS/RHEL 用yum install redis，装好后 systemctl 管理。无论哪种环境，装完第一件事一定是redis-cli ping，能回 PONG 说明服务起来了，后面才能继续聊场景。

这里必须提醒一句：单机版部署虽然最快，但生产环境至少要从主从复制开始考虑。docker 安装 redis 主从也很简单，后面讲高可用时会专门说明，第一步先别急着玩集群。

1.2 可视化客户端选型：从 redis-cli 到桌面管理器

命令行用久了会形成肌肉记忆，但排查线上问题时，尤其要看一堆 key 的分布和过期时间，桌面工具效率高得多。我先后用过三代客户端，可以给你做个参考。

• Redis Insight 是官方出的可视化客户端，免费，界面现代，支持命令面板、慢日志、内存分析，还能看 pub/sub，我最推荐这个。
• Another Redis Desktop Manager 是当初 RDM 收费后大家迁移最多的工具，支持树形展示、多连接管理，扫描大数据量 key 时比较稳，社区活跃度也不错。
• 老牌的 Redis Desktop Manager 目前在 macOS 和 Windows 上很多版本开始收费，能找到的免费版往往旧，不建议再用。

连接工具最常遇到的问题不是配置错误，而是 redis.conf 里bind 127.0.0.1和protected-mode yes的组合把人挡在门外。本地连没问题，远程一连就 timeout。早期我不知道protected-mode这个机制，非要在服务器上开 6379 端口再用桌面端连，结果连不上，后来一看日志才发现是保护模式把外部连接拒绝了。正确做法是：绑内网 IP 或用防火墙控制访问，不要直接裸奔公网；开发环境图省事可以protected-mode no，但生产环境我强烈建议配合 ACL 和密码一起用。

还有一个常见现象是连接工具能连上，但一执行KEYS *就卡死。这通常是线上 key 数量太大，KEYS命令会阻塞 Redis 单线程。用工具打开时要小心，尽量选用扫描方式，后面在“常用命令速查”里再展开说。

1.3 首次启动必做的三件小事：密码、持久化、日志

装好后先别急着写业务代码，把配置基座打稳。

密码这一项，早期的 Redis 配置简化成了requirepass yourpassword，客户端连接后执行AUTH yourpassword。Windows 设置 redis 密码也是改 redis.windows.conf 里的同一个字段，只是重启时要指定配置文件。现在 Redis 6+ 更推荐用 ACL：ACL SETUSER default ON >yourpassword ~* +@all。用 ACL 的好处是可以给不同业务线分配不同权限，比如让某个应用只能访问自己业务前缀的 key。

持久化配置决定了你 Redis 里数据能不能在重启后幸存。第一次使用可以先开 AOF：appendonly yes，再设置appendfsync everysec。同时保留默认的 RDB 快照规则作为兜底。这块后面会单开一章细讲，但起步阶段这两行配置一定不能漏，否则你缓存里存的数据一重启就全没了，到时候排查起来像灵异事件。

日志这一项容易被忽略。默认 Redis 是输出到 stdout 的，用 systemd 或 Docker 能看见，但手动redis-server时最好指定logfile /var/log/redis/redis.log和loglevel notice。真出问题时，redis.log里的信息比客户端报错有用得多，尤其是主从同步和持久化失败，都会先在这里留下痕迹。

2. 数据类型是地基：五大基础类型 + 高级类型的场景映射

2.1 五大数据类型在真实需求里的位置

聊到 Redis 核心应用场景，数据类型必须放在前面。很多人背过 String、Hash、List、Set、ZSet 这五种类型，但背完还是不会选。我的经验是反向思考：先看业务要做什么操作，再挑最省内存和最自然的数据结构。

String 适合单值缓存、计数器、分布式 Session。比如用户登录态可以先序列化 JSON 存进 String；网页浏览数直接INCR article:read:10086。要注意 String 本质是二进制安全的字节数组，能存数字、文本、序列化对象，但别什么对象都往里塞，超过几百 KB 的大 value 就是潜在的 Big Key 隐患。

Hash 是对象模型的好帮手。用户信息存成HSET user:profile:1001 name "zhang" age 18，想改年龄时HINCRBY user:profile:1001 age 1，不用像 String 那样读出整个 JSON 再改回去。缓存数据库一条记录时，很多人习惯直接SET user:1001 "{...}"，但如果热点用户会被频繁改单一字段，Hash 更省流量也更灵活。

List 最常见的用途是简易队列和最新的列表。用LPUSH塞数据，BRPOP阻塞读，就能实现一个生产消费模型。还有“最新评论”这种场景：LPUSH post:comments:2000 "first comment"+LTRIM post:comments:2000 0 99，只保留最近一百条，天然做成了列表页。但 List 做消息队列有个缺点：消费端如果宕机，消息就丢了，可靠场景后面会讲 Stream。

Set 适合去重、标签、抽奖。关注关系：SADD user:1001:follow 2002 2003，判断是否关注用SISMEMBER。抽奖可以用SPOP随机弹出一个，或者SRANDMEMBER只读取不弹出。日活用户也能用 Set 存储，但数据量大时我更倾向用 Bitmap 或 HyperLogLog，内存差距很大。

ZSet 是应用最广的“排行榜神器”。每个成员带着一个 score，天然支持排序。ZADD leaderboard:game1 1000 "userA"，ZREVRANGE leaderboard:game1 0 9就能拿到前十。延迟队列也可以伪装成 ZSet：score 存执行时间戳，轮询时ZRANGEBYSCORE queue:task -inf NOW取出到期任务，再到ZREM删除。还有限流算法中的滑动窗口用 ZSet 实现也很自然，后面统一说。

2.2 高级类型：Bitmap、HyperLogLog、GEO 把冷门场景变成亮点

除了五种基础类型，Redis 里还有几个容易在面试里加分、实战里省内存的类型。

Bitmap 本质是 String 的位操作，适合做布尔状态统计。比如用户签到：SETBIT user:sign:202501 1 1表示 uid 为 1 的用户今天签到，BITCOUNT user:sign:202501就能统计全量签到人数。一万个用户做一万天签到，占用的内存远比 Set 小得多。

HyperLogLog 适合做 UV 统计。PFADD page:view:home "uuid-1" "uuid-2"，PFCOUNT page:view:home直接算出近似去重数量。注意它是有误差的，官方误差在 0.81% 左右，对于 UV 这种量级完全可以接受。你千万别用 Set 去存每个访问用户的 ID，量一大内存就崩了。

GEO 用于位置相关场景。GEOADD nearby:drivers 116.39 39.90 "driver-1"，GEORADIUS nearby:drivers 116.40 39.91 5 km ASC COUNT 20就能拉出附近五公里的司机。它底层其实是个 ZSet，所以只能用 GEO 前缀的命令去操作，别混着用。附近的人、附近门店、货车围栏这些需求都是它的第一现场。

2.3 键设计与过期策略：别让 key 成为事故

用 Redis 时最容易被忽略的是 key 的命名规范。我见过一个项目里有人用user1、u-1001、1001_profile三种风格，导致统计和管理极其混乱。建议统一格式：业务域:对象:ID[:子对象]。例如user:profile:1001、order:list:2001:items。这样在可视化客户端里浏览、用 SCAN 匹配前缀、设置按业务的过期扫描都很清晰。

过期策略一定不能偷懒。内存是有限资源，缓存数据必须有一个明确的 TTL。我用SETEX或EXPIRE时，习惯在业务里统一封装一个时间枚举，比如缓存 5 分钟、1 小时、一天，而不是随手写一个 86400，这样后面调整时好改。另外前面提到的 RDB/AOF 持久化，和 TTL 并不冲突，过期 key 即使被持久化，恢复后依然会按规则失效。

再就是 Big Key 管理。一个 Hash 里有上百万个 field，或者一个 String 有几 MB，Redis 处理这类 key 时会让单线程命令变慢，网络传输也卡顿。我的经验是：先用redis-cli --bigkeys扫一遍，把最大的 key 揪出来；String 大 value 可以压缩后再存，Hash 可以按业务拆成多个小 key，或者考虑直接丢到对象存储里。删除时也要注意，大 key 用DEL会阻塞，Redis 4.0 之后可以用UNLINK异步删除。

3. 缓存治理：穿透、击穿、雪崩，不能只在面试里答得漂亮

3.1 缓存穿透：空值缓存 + 布隆过滤器，哪个更实用

缓存穿透的本质是请求一个缓存和数据库里都不存在的数据。比如用户模块，攻击者拿一排不存在的 uid 直接打过来，每次都会穿透 Redis 打到数据库。这个场景下，缓存形同虚设，数据库压力瞬间被放大。

第一种方案是缓存空值。查数据库发现没有，就在 Redis 里写一个null或特殊标记，比如user:profile:999999，TTL 给个 30~60 秒。但这要求你能区分“空值缓存”和“真实数据”，建议用统一前缀或 JSON 里的一个字段标记。缺点是空数据太多会占内存，而且可能在一小段时间内掩盖了真实数据的写入，但影响不大。

第二种方案是布隆过滤器。先在启动时把存在的 user id 全部 load 到布隆过滤器里，请求来了先查布隆过滤器，如果不存在直接返回 404。布隆过滤器的原理是 bitmap + 多个哈希函数，存在一定的误判率，但不存在的 key 一定不会误判。用 Redis 的 BIT 操作自己实现，或用 Guava 的 BloomFilter 都行；业务规模大时，常见做法是在 Redis 里用 Redisson 的 RBloomFilter。

我的经验是：小规模系统用空值缓存就够了，布隆过滤器反而增加维护成本；但接口要防刷、对性能要求高，布隆过滤器更值得投入。还有一点，穿透不止发生在读不存在的数据，也可能是写偏移量。比如热 key 被恶意传参成负数，这种要在业务层做参数校验，Redis 只是最后一道防线。

3.2 缓存击穿：互斥锁 vs 逻辑过期，实战选哪个

击穿是指一个热点 key 在过期的一瞬间，大量并发请求同时发现缓存失效，然后一起涌向数据库。缓存没有完全崩，但被这一个 key 打垮。

常见解法是互斥锁。在缓存失效后，让第一个请求拿到分布式锁去查数据库回填缓存，其他请求拿不到锁，可以返回旧缓存、sleep 重试或直接等着。用 Redis 实现就是SET cache:rebuild:hotkey owner NX EX 3，拿到锁的线程执行 DB 查询，再SETEX写回缓存，最后释放锁。这个方案逻辑清晰，但会造成少量请求等待，对一致性要求高的场景很合适。

另一派做法是逻辑过期。存进缓存的值不只存业务数据，还带一个expireAt字段。获取缓存时发现逻辑时间已过期，先尝试拿到重建锁；如果拿锁成功，异步去查 DB 重建数据，同时当前线程继续返回旧值。这样可以做到没有线程因为缓存过期而阻塞，但代价是短时间里读到的可能是旧数据。热点活动页这种弱一致场景用逻辑过期很舒服；电商库存这种强一致场景就别图省事。

我在实战中遇到过把互斥锁用在所有 key 上的反面教材，一把全局锁锁住了所有缓存重建，导致吞吐量断崖下降。正确的做法是只对热点 key 加锁，锁粒度精确到这个 key 本身，而不是所有 key 共用一把。判断热点可以用访问量统计、热点预测表或者 Redis 自身的LFU策略辅助。

3.3 缓存雪崩：过期时间打散 + 熔断降级

雪崩是大量 key 在同一时间过期，或者 Redis 节点挂掉，导致请求全部打到数据库。和击穿的区别在于击穿是“一个人引发洪峰”，雪崩是“一群人集体摆烂”。

最简单有效的预防手段是过期时间加随机数。假设你的业务缓存统一设置 1 小时，写代码时别写死EXPIRE 3600，改成3600 + random(0, 600)，让 key 的过期时间在半小时窗口内散开。这样能避免某一时刻集中失效。我之前接手过一个报表系统，每天零点统一刷缓存，加载完就全设 12 小时失效，结果中午 12 点整数据库瞬间被打满。后来把 TTL 改成随机段，问题就消失了。

第二层防护是本地缓存兜底。查询链路变成“本地缓存 -> Redis -> DB”，即便 Redis 出问题，本地缓存能扛一波流量。一致性上要接受短时偏差，可以通过定时刷新或版本号更新。现在 Caffeine 是 JVM 里比较好的选择，配置起来也不复杂。

第三层是服务端的降级和限流。在网关层或业务入口做一个开关，Redis 故障时直接返回默认值或错误，而不是让请求继续压库。这里我在生产环境踩过的坑是：降级开关本身会变成一个新的热点，比如每次请求都去远程配置中心拉开关，配置中心反而被打挂。所以开关一定要有本地缓存，并且支持人工强制关闭。

3.4 Redis 序列化与缓存一致性：乱码和双写不一致怎么解

用 Spring Data Redis 的同学大概率见过这种诡异的 key：\xAC\xED\x00\x05t\x00...。这就是默认 JdkSerializationRedisSerializer 干的好事，Java 序列化后的字节流直接作为 key，当然不可读。

解决办法是自定义 RedisTemplate，key 用StringRedisSerializer，value 可以视情况选Jackson2JsonRedisSerializer或GenericJackson2JsonRedisSerializer。用 JSON 序列化还有个好处，缓存里能直接看到内容，排查问题不用反序列化工具。注意 LocalDateTime 这类类型需要额外配置 JavaTimeModule，否则反序列化时报错是家常便饭。

缓存一致性是另一个大坑。最常见的做法是 Cache Aside Pattern：读的时候先查缓存，没命中再查库，最后回填；写的时候先更新数据库，再删缓存。这个模式理论上没问题，但“先更新 DB，后删缓存”如果删缓存失败，下一次读就会拿到旧值，并重新回填旧缓存。

我的处理习惯是：数据库更新成功后，用可靠通道做删缓存的重试。比如把删除任务投递到本地消息表或 MQ，由消费者去删。还有延迟双删，先删缓存，更新 DB，隔几百毫秒再删一次，解决并发读把旧值回填的问题。这里没有银弹，必须结合业务容忍度选择。订单创建这类场景，即使缓存短时间不一致也能接受，因为缓存本来就不是绝对一致性的来源。

4. 分布式锁：Redis 锁的价值、细节与常见翻车现场

4.1 从一个 setnx 到正确姿势

分布式锁是 Redis 核心应用场景里含金量比较高的一个。Java 的synchronized只能锁单机，多实例部署后必须有个跨进程的协调者。Redis 的SETNX天然适合做这件事。

但注意，千万不要再用两步法：SETNX lock 1然后再EXPIRE lock 30。如果第一步成功了，第二步崩溃，锁就永远不释放。正确姿势是单命令原子设置：SET lock:order:1001 uuid EX 30 NX。这个命令同时实现了“不存在才设置”和“自动过期”。

解锁也需要原子操作。不能先GET判断 value 是不是自己的，再DEL，因为两步之间可能发生锁过期被别的线程抢走的竞态。要用 Lua 脚本保证“检查 value + 删除”是一个整体：

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

value 必须用全局唯一 ID，比如 UUID 或业务 traceId，这能防止误删别人持有的锁。

4.2 锁的续期、可重入和主从切换

基础实现很简单，但生产环境很快会遇到问题：业务执行时间超过锁的过期时间怎么办？锁自动释放后，另一个线程进来了，前面的业务还没干完，等于两个人同时操作临界资源。

Redisson 解决得比较好。它默认给锁 30 秒，然后用一个定时任务周期性续期，每过锁时间的三分之一就自动续一次，这个机制俗称“看门狗”。如果拿锁的客户端崩溃了，看门狗也停了，锁到了过期时间就会释放，不会死锁。

Redisson 的RLock还支持可重入。同一个线程可以多次加锁，底层用 Hash 结构记录重入次数。有些团队自己基于SETNX实现可重入，靠 ThreadLocal 记录持有数，也没问题，但没必要重复造轮子。

还有一个容易被低估的问题：主从切换。假设锁写到了 master，master 宕机，数据还没同步到 replica，客户端 B 从新的主节点上又拿到了同一把锁。严格场景下可以用 RedLock 算法，向多个独立 Redis 节点申请锁，超过半数才算成功。但 RedLock 本身存在争议，工程上很多团队都用单主 + 哨兵模式扛住了绝大多数场景。如果你是金融交易这种极端环境，别自己拍板，宁可多评估一下对一致性的要求。

4.3 锁的粒度与排查笔记

锁的粒度直接影响性能。你要锁的是“用户 1001 对商品 2001 的充值”，那就用lock:recharge:1001:2001，不要图方便用lock:recharge锁住全体用户。我见过因为锁粒度太大，把一个支付接口的并发直接压成串行，业务方还以为是数据库慢。

锁内操作要尽量快。锁的本质是串行化临界区，你在锁里查第三方接口、跑复杂计算、访问远程 RPC，都会让其他线程等更久。更可怕的是，锁内调用自身依赖的另一个 Redis 锁，可能形成环状等待，直接死锁。所以锁内只放必要的写操作，其他事情在拿锁前做好。

我在排查一次偶发超时时，发现有一个定时任务拿锁后执行了十几秒的批量汇总，而锁过期时间只设了 3 秒。相当于锁过期后，另一台机器也进来跑同样的任务，数据被算了两遍。日志里看不出崩溃，因为根本没报错，只是结果对不上。这类问题靠增加过期时间解决是治标不治本，应该通过续期 + 拆批把锁持有时长降下来。

5. 进阶场景：消息队列、排行榜、限流和中间件边界

5.1 Redis 做消息队列：List、Pub/Sub 与 Stream 的取舍

很多团队在消息量不大时，直接用 Redis 顶替 MQ。确实能解决一部分问题，但得选对模型。

List 做队列最简单的是LPUSH+BRPOP。生产者往里塞，消费者阻塞读取。这个模型能实现异步削峰，比如秒杀场景把创建订单请求先塞进队列，消费者批量落库。缺点是没有消费确认，任务处理到一半宕机，消息就丢了，恢复后也没法处理。如果想加强，可以用BRPOPLPUSH把已取出的消息备份到另一个列表，处理成功后再删。

Pub/Sub 适合实时广播。比如通知所有节点的缓存失效：一个节点更新了数据，发一个PUBLISH channel:cache:clear，其他节点订阅后清理本地缓存。但它是“发后即焚”，订阅者没在线，消息就没了，所以别拿它做可靠通知。

Stream 是 Redis 5.0 正式推出的消息队列模型。它支持持久化、消费者组、消息确认，还有一个可视化工具 Redis Insight 能直观看到消息积压。如果团队不想引入 Kafka，业务消息量又在百万级以内，Stream 可以作为正经的轻量 MQ 使用。但真要追求事务、死信、大规模分布式分区，专业 MQ 还是更靠谱。我的原则是：一时翻译场景的项目可以用 Redis，但核心链路要用 RabbitMQ 或 Kafka。

5.2 排行榜、限流、计数器等高频玩法

排行榜场景直接 ZSet。拿直播平台送礼物热度来说，每次送礼ZINCRBY live:rank:room3 100 "userA"，页面端ZREVRANGE live:rank:room3 0 9 WITHSCORES就能展示前十条。排行同分时要注意 ZSet 按 member 字典序排列，不会完全符合业务预期，可以额外维护时间戳因子。

限流场景有两种常见做法。固定窗口：INCR limit:user:1001后判断是否超过阈值，再EXPIRE limit:user:1001 1，秒级限流简单粗暴。滑动窗口：用 ZSet 记录每次请求的时间戳，ZREMRANGEBYSCORE key -inf (now-1s)删除窗口外记录，再ZCARD统计当前窗口请求数。固定窗口有个临界问题：窗口切换的瞬间可能突增双倍流量，滑动窗口更平滑，但内存开销也更大。

计数器就是 String 的天下。日点击量、验证码发送次数、接口调用次数，INCRBY一行搞定。需要注意的是，计数器 key 的过期时间最好在第一次创建时就设好，否则容易变成永不消失的无界 key。配合前面讲过的 TTL 规范，这一块能干净很多。

5.3 Redis 做中间件的定位：哪些场景别硬扛

很多公司把 Redis 当作“万能中间件”：既是缓存，又是数据库，还是消息队列。这个用法在业务量小时没毛病，但到了瓶颈期会非常痛苦。

Redis 本质上是内存存储，内存容量和成本都是瓶颈。如果你把冷数据、历史订单、用户全量资料都往 Redis 里塞，别怪它动不动就 OOM。真正的数据库还是 MySQL、PostgreSQL 或分布式存储，Redis 只放热数据。

消息队列我上面说过，对可靠性和分区扩展有要求就别硬扛。分布式锁不是全局事务的替代品，多个资源要同时一致更新时，用分布式事务或者本地事务消息，不要迷信锁。还有一个容易踩的边界是“资源隔离”：多个业务共用一个 Redis 集群，一个业务的大 Key 或慢命令会把集群搞垮，最好按业务线拆分实例或使用不同 db？其实多 db 不推荐，Redis 非 cluster 模式下 db0~db15 是逻辑隔离，但性能上还是会互相影响。生产我习惯一个业务一套独立 Redis 或至少独立集群。

在我负责过的微服务架构里，Redis 的位置永远是“高速缓冲层 + 协同工具”，它负责让常用数据离 CPU 更近、让跨服务状态能共享、让热点流量先被削掉一层。认清这个边界，比掌握再多命令都重要。

6. 持久化与高可用：RDB、AOF、哨兵、集群一个都不能少

6.1 RDB 和 AOF 怎么选：丢数据 vs 恢复速度的博弈

Redis 持久化有两种套路。RDB 是给整个数据集打快照，恢复速度快，但它只能恢复到上一次快照的时间点。比如每 5 分钟存一次，宕机后最多丢 5 分钟数据。AOF 是追加日志，每秒钟记录写命令，重启后回放日志，最多丢一秒钟数据，但日志文件越来越大，恢复也要慢一些。Redis 4.0 开始支持混合持久化，RDB 做全量、AOF 做增量，重启时先加载 RDB 再补增量，速度和数据安全性得到了平衡。

配置上，RDB 默认是开启的，控制 save 的规则；AOF 默认关闭，需要手动appendonly yes。我推荐生产环境直接开启 AOF，并设置appendfsync everysec，同时保留 RDB，让它在每天凌晨做一次备份。这样即使 AOF 文件损坏，也可以用 RDB 顶一下。

这里有个容易被忽略的点：AOF 文件是会膨胀的，Redis 会自动触发BGREWRITEAOF重写。重写过程由子进程完成，不阻塞主线程，但如果磁盘 IO 很慢，可能造成瞬时卡顿。我在低配云服务器上遇到过重写期间 CPU 飙高、命令延迟变大的情况，换成了更大的磁盘后缓解了不少。

6.2 主从复制与哨兵：从单机版到高可用

单机 Redis 挂了，所有缓存和锁都会失效，生产环境至少要搞主从复制。配置方式是在从节点的 redis.conf 里加一行replicaof master-ip 6379，或直接启动时指定。Docker 里可以这样跑：

docker network create redis-net docker run -d --name redis-master --network redis-net -p 6379:6379 redis:7.2 redis-server --appendonly yes docker run -d --name redis-replica --network redis-net -p 6380:6379 redis:7.2 redis-server --replicaof redis-master 6379 --appendonly yes

主从复制有一个特点：从节点默认只读，读写都打到 master，读压力可以分流到 slave。同步过程先做全量同步，再做增量同步，中途断线了重连会尝试补发增量。

光有主从还不够，master 挂了还是需要人工切换。哨兵（Sentinel）就是来看门的，监控 master 状态，异常时自动把某个 slave 提升成 master。最少要部署三个 Sentinel 节点才能避免脑裂，哨兵之间也要选举。

在 K8s 环境里搭哨兵集群会比较繁琐，推荐直接用 Redis Operator 或 Bitnami 的 Helm chart，它们把 StatefulSet、Service、哨兵配置都封装好了。凡是自己手动在 K8s 上搭 Redis 的，都逃不开存储编排和网络 DNS 的坑，不是不能做，而是耗时成本不低。

6.3 Redis 集群：槽位、扩容、客户端路由

当数据量超过单机内存，或者写并发大到单主扛不住时，就需要 Redis Cluster。Cluster 把 key 空间分成 16384 个槽，通过CRC16(key) % 16384算出槽位，再分配到不同的主节点。客户端访问一个 key 时，如果节点发现槽位不属于自己，会返回 MOVED 错误，聪明一点的客户端会顺着这个信息更新路由表。

最少 3 主 3 从。创建集群的命令大概是redis-cli --cluster create 192.168.1.10:6379 192.168.1.11:6379 ... --cluster-replicas 1。但生产环境我不会手动去搭集群，负载均衡和节点巡检太麻烦，除非是几台机器的私有云。现在 Redis 7 集群运维比早期顺畅很多，槽迁移用redis-cli --cluster reshard就能做，但扩容期间对客户端和监控的要求比较高。

Cluster 模式下要求每个节点尽量无大 key，因为大 key 无法跨槽迁移；多 key 操作也要保证这些 key 在同一个槽，通常用 Hash Tag 算法把多个 key 塞进同一个槽。比如{order:1001}:items和{order:1001}:pay，花括号部分参与哈希计算，这样它们会被路由到同一个节点。这个技巧在实现事务和 Lua 脚本时尤其重要。

6.4 常见连接报错与排查实录

我在走上线环境时最常遇到的一个报错是：

Redis command timed out; nested exception is io.lettuce.core.RedisCommandTimeoutException

这个以 lettuce 为底层客户端的 Spring Boot 应用比较常见。排查顺序我一般是：

• 先看 Redis 端是不是满了：redis-cli INFO看 connected_clients、blocked_clients、used_memory 是否异常高。
• 再看业务代码是不是有慢命令：SLOWLOG GET 10能看到哪些命令执行慢。大 key、KEYS *、频繁连接断开都是元凶。
• 最后看网络：客户端和 Redis 跨云区域时，RTT 很高，超时阈值要调大；连接池配置太小，也会因为等待连接而超时。

另一个让我印象深刻的错误是关于 Docker Desktop 的：

docker search redis request returned 500 internal server error for api route and version http://%2f%2f.%2fpipe%2fdockerdesktoplinuxengine/v1.56/images/search?term=redis, check if the server supports the requested api version

这通常不是 Redis 的问题，而是 Docker Desktop 的 Linux 引擎或 Docker API 版本异常。重启 Docker Desktop，或者升级 Docker 版本一般就能解决。如果还不行，检查 WSL 2 内核版本，老内核和 Docker Desktop 新版有摩擦。

还有连接工具一直转圈、AUTH失败，也别急着怀疑网络。去看redis.log里有没有AUTH <password> called without any password configured，这是典型 redis.conf 没生效的表现。Windows 设置 redis 密码后不重启，或没指定正确的配置文件，就可能出现这个状态。

7. 把八股变成肌肉记忆：高频场景速查与常见面试题

7.1 为什么 Redis 快？单线程和多线程的真相

这个问题几乎是 Redis 面试题里的“第一题”。核心答案可以拆成四层：数据全在内存；IO 多路复用；高效的数据结构设计；命令执行单线程消除锁竞争。

很多人听到“单线程”会惊讶，Redis 6.0 不是有多线程 IO 吗？准确说，Redis 的主命令处理是单线程的，多线程主要用在网络 IO 读写和异步持久化、异步删除上。执行命令的流程依然是单线程串行，所以慢命令会阻塞其他所有命令。这就是为什么KEYS会被嫌弃，O(N)复杂度在大 key 面前是灾难。

了解了这一层，很多面试题的答案就通了：为什么 big key 会导致阻塞？因为单线程处理一个超大 Hash 或重构大 key 时耗时长。为什么可以用UNLINK代替DEL？因为它把释放内存的操作丢给后台线程处理。为什么 Redis Cluster 客户端会有 MOVED？因为是分布式，节点不共享状态。

7.2 核心命令速查表

命令不在多，用对才算数。我整理了一份日常使用频率最高的命令集合，可以当成速查卡。

7.3 从场景反推设计，而不是背命令

面试官最烦的是背答案。与其把“五大数据类型”一字不差背出来，不如让他看到你有场景能力。

比如他问“如何实现一个排行榜”，你应该说 ZSet。score 轮次积分，member 用户 ID。如果分数相同要按时间顺序，就在 score 上做编码，或者额外用一个小 ZSet 存储入场时间。面试官再问“如何实现限流”，你可以分固定窗口和滑动窗口，并指出各自的临界问题和内存消耗。这才是 Redis 核心应用场景该有的解题思路。

再比如“缓存穿透和布隆过滤器”，别只提概念，要能讲清楚误判率对业务的影响，以及空值缓存最省事的适用条件。我面试人时，能主动说出“热点 key 可以提前预热”的人会明显比背八股的更受欢迎。

7.4 我的场景速查清单

最后送你一份直接从实际业务提炼的清单，照着这个去给项目体检，基本不会漏：

• 用户信息缓存：String 或 Hash，业务前缀 + ID，TTL 15 分钟。
• 分布式会话：String 存 Session JSON，TTL 30 分钟，续期逻辑要兜底。
• 接口级限流：固定窗口用 INCR + EXPIRE；精细控速用 ZSet 滑动窗口。
• 排行榜：ZSet，注意同分排序和定期清理过期成员。
• 任务队列：Stream，搭配消费者组做 ACK。
• 附近的人：GEO，省去自己算经纬度距离的麻烦。
• 幂等记录：StringSET idempotent:pay:1001 OK NX EX 3600。
• 缓存穿透：空值缓存 + 极短 TTL；恶意攻击场景加布隆过滤器。
• 缓存击穿：热点 key 用逻辑过期，普通 key 用互斥锁。
• 缓存雪崩：TTL 加随机偏移，本地缓存兜底，Redis 高可用。

写了这么多，说一点我自己的心得：Redis 入门不难，但把它用稳，拼的是对数据结构的理解和故障现场的积累。我踩过最大的坑就是把缓存当数据库用，脏数据一路流到线上报表，才意识到 Redis 一致性治理不是写几个注解就能解决的。如果你刚开始用 Redis，我建议先给自己定三条开发规范：所有 key 必须带业务前缀并设置过期时间；不使用 KEYS 命令；任何缓存 value 都要考虑序列化后的可读性。这三条看起来简单，但真能让你少熬好几个通宵。把缓存、锁、队列、统计这几个核心场景吃透，不管面试还是项目落地都不会慌。