Redis实战全解析：缓存治理、分布式锁与高可用集群搭建指南

服务器这东西，一旦上了生产环境，你总会遇到一个绕不开的名字：Redis。不管是扛高并发读多写少的缓存、做分布式锁、还是临时计数器和排行榜，Redis几乎是后端服务器里最常见的“基础设施”之一。这篇博文，我就结合自己多年摆弄服务器和Redis的经验，把从安装配置、数据类型、缓存治理、分布式锁到主从集群和常见报错排查的思路完整捋一遍。既给新手一份可以照着做的实操清单，也希望能给已经上路的朋友一点排查问题的方向。

我默认你手头有一台能登录的Linux服务器，或者一台能开Docker的机器。东西不复杂，但坑不少，咱们一个坑一个坑地过。

1. 服务器架构里的Redis到底在扛什么

1.1 它解决了服务器的三个核心痛点

很多初学者容易把Redis理解成“一个能存数据的缓存”，这话没错，但太浅。站在服务器的角度，Redis真正解决的是三个问题：

第一是数据库压力。你的业务一旦有大量读请求，全部打到MySQL或者PostgreSQL上，数据库连接池和磁盘IO根本扛不住，尤其是类似热点新闻、商品详情这种读多写少的场景。Redis把热数据放在内存里，读请求直接命中内存，数据库QPS压力能下降一个数量级。

第二是接口响应时间。磁盘随机读取和网络来回的延迟，通常在几十毫秒甚至上百毫秒，而在内网环境下，Redis的读写往往是亚毫秒级别。这意味着你如果之前查一次详情要80ms，现在Redis命中只要1ms，用户体验的提升是非常直观的。

第三是分布式环境下的协同。单机程序用锁很简单，但上了服务器集群，多台机器要抢同一个资源，就需要一个大家都能访问的协调者。Redis的原生SET NX、INCR、发布订阅等能力，让它很适合做分布式锁、分布式计数器、接口幂等控制这类“中间件”角色。

1.2 为什么选Redis而不是别的

我碰到过很多人在选型时纠结：既然服务器内存有限，为什么不直接用本地缓存？用Memcached不行吗？甚至直接放数据库不行吗？

我把选型逻辑拆开讲。本地缓存比如Guava Cache、Caffeine，速度确实快，因为根本不走网络，但问题是每台服务器各存一份，数据不一致，而且没法做跨实例的失效通知。Memcached也能做分布式缓存，但数据结构只有字符串一种，类型太简单，你想做个排行榜都费劲。数据库虽然安稳，但扛不住高频读。

Redis强在两点：一是数据的结构丰富，String、Hash、List、Set、ZSet五大数据类型，基本覆盖了缓存、计数、队列、去重、排行榜等常见场景；二是生态成熟，客户端多、运维工具多、主从和集群方案现成，从单机到集群的迁移路径很平滑。

注意：Redis虽然带个“数据库”的名字，但它不是万能存储。没有事务回滚、没有强一致的多表关联，把它当MySQL用的大坑，后面我会细说。

1.3 红线场景：什么情况下别硬上Redis

说了这么多优点，也得讲讲哪些场景不要用Redis，这是我踩过坑之后才明白的。

第一，核心业务数据不要只放Redis。比如订单金额、库存扣减最终记录，你可以用Redis做前置校验和防抖，但最终必须以数据库落盘为准。因为Redis的持久化机制（RDB和AOF）在生产实践中可能会丢极少量的数据，不适合当唯一存储。

第二，别拿Redis当重型消息队列。它虽然有List、Stream，能实现简单的任务队列，但缺少消息确认、重试、死信这些成熟消息队列该有的能力。如果业务量上来，你会陷入自己造轮子的泥潭。

第三，不要存大字符串和大集合。Redis是单线程处理命令的，一个几千KB的value，写一次和读一次都要占据事件循环很久。如果某个key特别大，它可能会把整个Redis服务拖慢，这就是后面要聊的“大key”问题。

2. 安装部署：换一台新服务器我会怎么装

2.1 三种安装方式的取舍

在服务器上装Redis，主流有三种方式：包管理器安装、源码编译安装、Docker容器安装。我根据不同环境切换着用，各有取舍。

• 包管理器安装：apt install redis-server 或 yum install redis，适合快速搭一套测试环境。优点是快，缺点是版本往往偏旧，而且配置文件位置和默认参数因发行版而异。
• 源码编译安装：从Redis官网下载稳定版源码，make编译。优点是版本最新、参数可控。缺点是你要自己处理依赖和systemd服务文件。
• Docker安装：docker run redis，一条命令搞定，而且主从集群用compose编排非常方便。前提是你已经接受容器化运维。

我自己在生产环境，倾向于用官方源码编译指定版本，然后配合systemd管理。原因很简单：生产环境不能接受莫名其妙的版本差异和默认配置陷阱，你用什么参数启动、装在哪，心里要门清。测试环境则直接Docker，坏了就删，重建也快。

2.2 配置文件里这七个参数必须理解

Redis默认配置可以直接跑，但直接跑的结果就是裸奔。装好后第一件事，打开redis.conf，逐个调整下面这些参数。

# 绑定地址，0.0.0.0表示所有网卡可访问，建议按实际环境限制 bind 0.0.0.0 # 保护模式，不配置密码时必须开启 protected-mode yes # 端口 port 6379 # 后台运行，如果用systemd管理则建议设为no由systemd托管 daemonize no # 访问密码，生产环境必须设置 requirepass 你的强密码 # 最大内存，根据服务器内存和业务合理分配 maxmemory 2gb # 内存淘汰策略，见下方说明 maxmemory-policy allkeys-lru # 开启AOF持久化 appendonly yes appendfsync everysec

这里最容易忽视的是maxmemory和maxmemory-policy的组合。你如果不设上限，Redis会一直吃内存，直到把服务器内存吃光，触发系统OOM Killer，到时候整个服务直接挂。设了上限之后，还需要回答“内存满了怎么办”，这个由淘汰策略决定。

• volatile-lru：只对设置了过期时间的key做LRU淘汰，适合缓存场景。
• allkeys-lru：对所有key做LRU淘汰，适合你能接受任意key消失的场景。
• noeviction：内存满直接报错不写，适合不能丢数据的场景。

我用得最多的是 allkeys-lru，毕竟Redis主要做缓存，冷了的数据应该被淘汰。

注意：maxmemory不要设置为服务器物理内存的100%，要留出给操作系统、fork子进程以及AOF重写时的内存开销。比如一台16G内存的服务器，我一般分给Redis 10G，剩下的给系统和业务本身。

2.3 用systemd把Redis管起来

很多从源码编译安装的朋友都会卡在这一步：redis-server /path/to/redis.conf 能启动，但重启服务器后Redis没了，也没法用systemctl status查看状态。解决方法是写一个标准的systemd unit文件。

[Unit] Description=Redis Server After=network.target [Service] Type=simple User=redis Group=redis ExecStart=/usr/local/bin/redis-server /etc/redis/redis.conf ExecReload=/bin/kill -USR2 $MAINPID Restart=on-failure RestartSec=5s LimitNOFILE=65535 [Install] WantedBy=multi-user.target

把这个文件放到 /etc/systemd/system/redis.service，然后执行：

systemctl daemon-reload systemctl enable redis systemctl start redis systemctl status redis

这里有个服务器运维中特别容易踩的细节：如果Redis进程是root启动的，出于安全考虑我强烈建议单独建一个redis用户来运行。你可以用 useradd -r -s /sbin/nologin redis 创建，然后把 /var/lib/redis 和 /etc/redis 的属主改成 redis。这样做的好处是，即使Redis被利用，攻击者拿到的也不是root权限，服务器不会被一锅端。

2.4 装完先跑一次体检

装好之后先别急着接业务，在命令行敲几个命令确认状态。

# 登录并验证密码 redis-cli -a 你的密码 # 看基本信息 info server # 看内存情况 info memory # 看客户端连接数 info clients # 跑一遍读写验证 set hello world get hello

这些命令不是让你看一眼就算了。info output里的 used_memory、connected_clients、uptime_in_days 这些指标，建议心里有个数，后续监控告警都是从这里取值。如果配置了密码，redis-cli 会提示 warning，加 --no-auth-warning 可以关掉提示，脚本里尤其需要这个参数，否则 cron 日志会被刷屏。

3. 数据类型实战：别把Redis用成高级Map

3.1 五大数据类型和它们的战场

很多新手觉得Redis就是 set/get 字符串，完全忽略另外四种类型。等你真正做排行榜、做关注列表、做去重的时候，就会知道用错数据类型的代价有多大。

举个例子。你要存用户信息，假设用户有昵称、头像、年龄三个字段。如果你用String，就会搞出 user:1001:name、user:1001:avatar、user:1001:age 三个key，浪费内存还难管理。用Hash的话，一条 HSET user:1001 name "张三" avatar "/a.jpg" age 25 就搞定了，后续只查某个字段还能节省带宽，命令也会优雅很多。

再比如排行榜，如果用数据库做 ORDER BY 然后再算出名次，数据量一大准卡。而ZSet天生就是干这个的，score就是分数，ZREVRANGE 取Top10是毫秒级操作。

3.2 key设计和序列化的隐形坑

我接手过不少服务器，Redis里存了一堆乱七八糟的key，最大的问题不是数据乱了，而是你根本不知道这个key是干什么的。服务器出了问题想排查，连个线索都没有。

好的key命名一定要有规则，推荐这么设计：业务名:对象名:唯一标识。比如 order:detail:20240101。冒号分割在Redis Desktop Manager里会天然形成目录结构，一眼就知道归属。千万别用没有规则的随机串，也别用下划线糊成一大段。

再说序列化。这也是热词里很多人踩过的“redis序列化”问题。Java业务里最常见、最糟糕的做法是直接把对象用JDK默认序列化塞进Redis。问题有三个：一是体积大，JDK序列化出来的字节数组比JSON大好几倍，浪费内存和带宽；二是二进制不可读，你在命令行里 get key 看到一堆乱码，根本没法排查；三是协议耦合，万一以后换语言，Java序列化的数据其他语言根本读不了。

我的实践是：数据入库Redis之前统一用JSON序列化，特别是Jackson或Fastjson，节省内存且可读性强。如果追求更极致的空间，可以考虑protobuf这类，但牺牲可读性换空间，调试成本会增加，看你的业务取舍。

3.3 大key和热key：服务器上最容易翻车的两个问题

先说“大key”。我定义的大key，是单个key的value超过几百KB，或者是Hash/Set/ZSet里的元素数量超过一万。危害在于：读写大key会产生很大的网络包，占用带宽；删除大key时会阻塞Redis主线程，导致服务在几百毫秒甚至几秒内无法处理其他命令。

排查大key的方法很简单，Redis自带了--bigkeys扫描参数：

redis-cli --bigkeys -a 你的密码 --no-auth-warning

它会扫描整个实例，输出每种数据类型里最大的几个key。扫出来之后，如果是Hash/Set这种大集合，用 HSCAN 分批迭代，然后用 HDEL 或 SREM 分批删，千万不要直接 DEL，否则就是一次线上事故。字符串类型的大value，拆分成多个小key，或者用压缩算法先把内容压一压。

再说“热key”。如果某个key被超高并发读取，比如双十一的秒杀库存，Redis本身单线程处理虽然快，但网络和CPU也会达到瓶颈。简单的雪崩应对方案是给key随机加后缀（比如把 hotkey 变成 hotkey1 到 hotkey10），这样流量就分散到多个key上了。更彻底的办法是在业务机器上加一层本地缓存，或者用Redis Cluster把热点分散到不同节点。

3.4 缓存治理：TTL、淘汰策略、定期扫描

热词里有“redis缓存治理”，这是个很实际的运维主题。缓存治理的核心就三件事：设TTL、定策略、定期盘。

我在实际中遇到过最经典的事故：一个同事插入Redis的缓存key全部没有设置过期时间，三个月后服务器的内存被吃满，OOM直接把Redis进程杀了。治理方案分三步：

• 代码review保证每条缓存业务都设置TTL，通常是几分钟到一小时的业务时延。
• 配置 maxmemory-policy，防止内存满时Redis写不进新的key。
• 每周在低峰期跑一遍 redis-cli --scan --pattern "业务前缀*" 检查key数量增长，或者用 info keyspace 看有没有缓存key只增不减。

这里提一下Redis的过期删除策略，它其实不是定时把所有过期key瞬间删掉，而是懒性删除配合周期删除。所谓懒性删除，就是每次get时如果发现key过期，就删除再返回空；周期删除，就是Redis每隔一段时间主动扫一部分过期key。理解这个机制很重要：如果大量key设置了同一秒过期，那这一秒Redis会疯狂执行删除操作，可能造成瞬间卡顿。所以缓存TTL我一般会加一个随机扰动，比如基础时间600秒，再随机加0到60秒，就是为了避免这种“缓存雪崩”的变体。

4. 生产级玩法：分布式锁和缓存治理细节

4.1 分布式锁的正确姿势，别再踩两个坑

热词里“redis分布式锁”赫然在列，这也确实是服务器集群场景下最常被问到的Redis用法。但网上很多文章的写法过时了，甚至有bug。我先演示错误写法。

第一个坑是两步操作：先用 SETNX 命令抢锁，成功后再 EXPIRE 设过期时间。问题在于如果 SETNX 之后、EXPIRE 之前，进程崩溃了，锁永远不会过期，其他请求就永远拿不到锁。

第二个坑是只判断 SETNX 返回值，忘记在释放锁时校验持有者。假设A拿到锁，执行时间超过了锁的过期时间，锁已经自动失效，B拿到锁开始执行。这时候A执行完，直接 DEL 把B的锁删了，就出大事了。

正确的写法是Redis官方推荐的原子操作：

# 获取锁，value用唯一标识，比如UUID SET lock:order:1001 uuid_value NX EX 30 # 释放锁，先校验是持有者，再删除 if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end

上面用Lua脚本保证“判断+删除”的原子性。如果你用的是Java的Redisson客户端，它已经把看门狗机制封装好了：获取锁时默认30秒过期，但是只要业务一直执行，后台线程会一直给锁续期，直到业务执行完释放锁。这比手动设一个死长的过期时间要安全得多。

至于RedLock那种多实例加锁方案，我个人的看法是：绝大多数业务根本用不到。实现复杂，而且学术界对它也有争议。只要你的Redis不是单点，比如主从加哨兵，普通的SET NX EX加Redisson就足够应对绝大部分场景了。

4.2 缓存三大坑：穿透、击穿、雪崩

这三个词是所有面试题和真实事故里的常客，也是“Redis做中间件”绕不开的话题。

缓存穿透：请求的key在缓存里不存在，数据库里也不存在，于是每次请求都直接打到数据库。攻击者可以构造一堆不存在的ID来打库。解决思路有三个：一是缓存空值并设置短TTL，二是用布隆过滤器先把不存在的key过滤掉，三是对无法修正的恶意请求做接口限流。

缓存击穿：某个热点key在缓存过期的那一瞬间，大量并发请求同时查询数据库。解决思路：一是热点key不设TTL；二是用互斥锁，让只有一个请求去刷新缓存，其他请求先等一下再读；三是上面说的逻辑过期方案。

缓存雪崩：大量key同一时间过期，导致一大批请求打到数据库。解决思路：TTL加随机扰动，让过期时间分散开；多级缓存，本地加Redis两层；提前压测评估数据库能否扛住冲击。

这里给一个快速对比表：

4.3 缓存与数据库的一致性怎么保证

这个问题的标准答案是：大多数业务场景，只需要做到最终一致性，别追求强一致，否则性能和复杂度都不划算。

我实践下来最稳妥的套路是“Cache Aside”（旁路缓存）加“延迟双删”。流程是：读请求先读缓存，没命中就读数据库，然后回填缓存；写请求先更新数据库，然后删除缓存。为什么要删除缓存而不是更新缓存？因为更新缓存存在并发问题：两个请求同时写数据库，后写的数据库是最终值，但如果先更新的线程后完成缓存更新，缓存里就存了一个旧值。删除缓存就简单了，下次读的时候会从数据库拿最新数据回填。

“延迟双删”处理的是更极端的并发场景：线程A更新数据库，删缓存；线程B这时读了一个旧值回填了缓存；A等了一小段时间后再次删除缓存。这个延迟一般几百毫秒，主要看业务容忍度。

强一致性场景怎么办？我的建议是：别缓存。库存、余额这种涉及钱的强一致数据，老老实实走数据库事务，Redis顶多做前置的预检和限流。

5. 高可用与集群：单机Redis注定撑不了太久

5.1 用Docker快速搭一套主从复制

单机Redis一旦服务器宕机，整个业务缓存全部丢失。生产环境至少要做主从。主从复制的作用有两个：一是数据冗余，二是主节点挂了可以从节点顶上，实现读写分离。

热词里“docker安装redis主从”是很多人搜过的，确实用Compose搭建最省事。我写一个可以直接用的docker-compose.yml：

version: '3' services: redis-master: image: redis:7.0 container_name: redis-master command: redis-server --requirepass masterpass --appendonly yes ports: - "6379:6379" volumes: - ./master-data:/data redis-slave: image: redis:7.0 container_name: redis-slave command: redis-server --slaveof redis-master 6379 --masterauth masterpass --requirepass slavepass --appendonly yes depends_on: - redis-master ports: - "6380:6379" volumes: - ./slave-data:/data

执行 docker compose up -d，然后进从节点执行 INFO replication 看 role 是否为 slave。主从复制原理不复杂：主节点启动一个后台进程把当前数据生成RDB快照发给从节点，从节点加载完快照后，主节点再把后续的写命令增量传给从节点。这个流程是异步的，所以主从之间天然有极小的数据延迟。

注意：从节点默认是只读的，你在从节点上执行 SET 会报错。这是保护机制，防止主从数据不一致。想开启写操作就得改 replica-read-only no，但我劝你别这么干，会让数据彻底失控。

5.2 哨兵：自动故障切换的守护者

主从解决了数据备份，但主节点宕机时，业务怎么自动把写请求切到从节点？这就需要Sentinel（哨兵）出场。哨兵本身也是一个Redis进程，它的职责是监控主从节点，发现主节点挂了之后，在从节点里选举一个提升为新主节点，并把消息推给客户端。

部署哨兵最少三个节点，这是个典型问题。三个节点互相投票，才能避免“脑裂”——也就是两个节点各自认为自己是主节点，从而产生数据分裂。哨兵配置文件里关键参数是：

sentinel monitor mymaster 127.0.0.1 6379 2 sentinel auth-pass mymaster masterpass sentinel down-after-milliseconds mymaster 5000 sentinel failover-timeout mymaster 10000

其中数字2表示至少需要2个哨兵同意才能判定主节点客观下线。哨兵模式整体的复杂点在于客户端接入，客户端不能直接写死主节点IP，而要通过哨兵接口来获取当前主节点地址。如果你的客户端不原生支持哨兵，那就得在客户端代码里加一层地址发现逻辑。这也是我建议中小业务直接上云托管Redis的原因之一，省掉这些运维复杂度。

5.3 集群：真正解决容量和写入瓶颈

主从加哨兵解决了高可用，但没有解决容量上限。单台服务器内存总是有限的，假设业务数据量超过单台机器的内存，就要考虑Redis Cluster。

Redis Cluster采用分片策略，整个集群有16384个哈希槽，每个key通过CRC16算法算出一个哈希值，映射到其中某个槽位，每个主节点负责一部分槽位。比如三主三从的集群，三个主节点各负责大约5461个槽位。这样数据分散到了多台服务器，自然突破了单机内存限制。

部署集群用官方工具最方便。拿到源码后：

redis-cli --cluster create \ 192.168.1.10:7000 192.168.1.11:7000 192.168.1.12:7000 \ 192.168.1.13:7001 192.168.1.14:7001 192.168.1.15:7001 \ --cluster-replicas 1

后面的 --cluster-replicas 1 表示给每个主节点配一个从节点。集群模式下有一个约束要特别记住：单个命令涉及多个key时，如果key不在同一个哈希槽里就会报错。所以设计key时要有意识地让相关数据挂在相同前缀，比如 user:1001:info 和 user:1001:score 会落在同一个槽位，而 user:1001 和 order:1001 大概率不在一个槽。

5.4 监控和日志不能省

生产环境的Redis，我每天晚上会例行看几样东西：连接数、内存使用率、慢查询日志、持久化失败告警。

连接数突然飙高，大概率是你的应用连接池配置有问题，没释放连接。内存涨得快，要么是缓存没有TTL，要么是某个业务把大对象塞进去了。慢查询的命令，用下面两个方式查：

# 查看当前慢查询阈值，单位微秒，默认10000微秒即10ms CONFIG GET slowlog-log-slower-than # 查看最近10条慢命令 SLOWLOG GET 10

如果发现慢命令频繁出现，且都是一些 HGETALL、LRANGE 大范围命令，那就该回去查大key问题了。

日志也是一样。Redis默认日志不太多，但出问题时日志会给出明显提示，比如主从断连、RDB持久化失败、OOM内存超过限制等。日志级别建议设置为 notice，生产环境别开debug，否则日志量能把你磁盘写满。日志文件位置一般在 /var/log/redis/redis.log，自己部署的话在redis.conf里用 logfile 指定。

服务器虚拟化环境还有个值得注意的点：如果Redis运行在虚拟机里，时钟跳跃可能导致过期时间计算异常，进而影响缓存TTL和分布式锁的过期策略。有条件的话用同步时间服务保证时钟一致性，或者直接用容器化部署让时钟问题暴露得更直观、更好排查。

6. 连接工具和客户端选择：运维效率的关键

6.1 从Redis Desktop Manager到Another Redis Desktop Manager

对于不习惯命令行操作的朋友，可视化工具几乎是必需品。老牌的Redis Desktop Manager（RDM）相信大家都听过，界面成熟，但它早期版本对免费用户限制严格，且部分版本需要付费授权。热词里“redis desktop manager”和“another redis desktop manager”同时出现，说明大家确实在找替代品。

我目前主力用的是Another Redis Desktop Manager，简称ARDM。它免费开源，跨平台，功能上甚至比老牌RDM更顺手。几个我常用的功能：

• 支持Redis Cluster和哨兵模式的连接管理。
• 支持SSH隧道连接，服务器Redis不暴露公网端口时，通过跳板机连过去很方便。
• 支持命令行面板，可以直接敲redis命令调试Lua脚本。
• 可以按key前缀过滤扫描，大key在GUI里能一眼看出来。

在配置连接时，如果你用密码认证，填密码就行。但如果Redis部署在Docker或者K8s里，端口映射和网络模式需要注意，GUI连不上很多时候不是密码问题，而是bind地址和容器端口映射没弄对。

6.2 命令行下的几个高能技巧

就算有了GUI，我也建议任何时候都掌握几个比较好用的命令行技巧。特别是服务器上排查问题时，可视化工具不一定装得上，命令行是最后一道防线。

# 实时查看命令统计，观察哪些命令被大量执行 redis-cli --stat # 重新启动就报错：Address already in use # 大概率是旧的redis进程没退出 ss -lntp | grep 6379 ps -ef | grep redis # 批量删除某个前缀的所有key，用SCAN而不是KEYS redis-cli --scan --pattern "user:*" | xargs -r -n 100 redis-cli DEL

务必记住：生产环境别用 KEYS *。这个命令会遍历所有key，数据量大时直接阻塞Redis主线程几秒钟，线上立马连锁反应。想遍历就用SCAN，它是游标式分批返回，不阻塞。

7. 常见问题与Redis面试真题实战

7.1 redis command timed out怎么排查

热词里有一条非常具体：“redis command timed out; nested exception is io.lettuce.core.rediscommandtimeout”。这是Java项目里使用Spring Data Redis（底层是Lettuce客户端）时非常经典的报错。字面意思就是Redis命令执行超时了。

常见的诱因有这么几个，按排查优先级排序：

• 大key阻塞：Redis主线程在做一个耗时操作，比如删一个大key，或者执行了一次全量KEYS扫描，所有命令都排队超时。
• 网络问题：Redis部署在另一台服务器，服务器之间网络抖动、防火墙限制，或者跨机房访问延迟过高。
• 连接池耗尽：Lettuce使用共享连接，线程一多，请求在客户端本地排队，也会表现为命令超时。
• Redis自身负载：CPU达到瓶颈，文件系统IO有问题，AOF每秒钟同步磁盘都可能卡住。

排查路径是：先看 Redis 服务端慢日志SLOWLOG GET，确认是不是有大命令拖慢了服务；再看 Redis 的 info clients 和连接数，确认连接没有堆积；最后 ping 一下确认网络延迟。如果Redis完全正常，那就是客户端配置问题，Spring里调高 lettuce 的超时配置只能是权宜之计，治本还是要扫大key。

7.2 从日志和内存里读出问题

排查问题的经验告诉我，先看日志，再看内存，别瞎猜。Redis日志里如果出现 "Disk is full" 或者写AOF失败，基本就是磁盘空间干满了。出现 "Cannot allocate memory"，就是服务器内存不足，Redis无法分配内存。出现 "Misbehaving client"，可能是客户端发了一堆畸形命令。

内存方面，info memory有三个关键指标：

• used_memory：当前实际占用的内存。
• used_memory_rss：Redis进程占用的物理内存。
• mem_fragmentation_ratio：RSS与used_memory的比值，正常在1左右，如果超过1.5说明存在内存碎片，可以考虑重启或开启自动整理。

当 mem_fragmentation_ratio 长期很高时，可考虑设置activedefrag yes，让Redis在空闲时自动整理碎片。

7.3 面试里常问的几个点这么答

热词里出现了“redis面试题”，也顺便把这部分讲了。我的经验是面试官问Redis，主要考察三个方面：底层原理、场景应用、踩坑经验。

面试不是背书，关键是能把每个方案背后的为什么讲清楚。比如Redis为什么快，往深处说还要提到 Redis 6.0之后支持的IO多线程，以及单线程模型下删除大key的代价，这一层深度是很多人没准备到的。

7.4 扩展思路：Redis做中间件还能玩什么

除了缓存和锁，我在实际项目中还用Redis做过几类“中间件”角色，简单分享两个思路。一个是接口幂等，用 SETNX 做一个幂等键，同一个请求号在几十秒内只能成功一次，配合数据库唯一索引做双重保障。另一个是滑动窗口限流，用ZSet记录请求时间戳，统计固定时间窗口内的请求数，超过阈值就拒绝服务。这两个方案在生产中都很实用，代码量也不大。

我觉得在这些场景里，Redis最大的价值不是性能，而是原子操作和数据结构本身。它让分布式系统里原本需要靠数据库锁或者分布式事务才能实现的逻辑，变得非常简单直接。当你理解了这些，再看各种技术文章里“Redis做中间件”的说法，就不会觉得是个空泛的概念了。

最后说点真心话。Redis这东西，表面上看就是 set/get 不到一百条命令，但真正用好的关键在于理解它的线程模型和内存特性。我见过太多服务器被几个大key拖垮、被忘了设TTL的缓存吃满内存、被错误分布式锁搞到数据错乱的案例，全都是栽在“会命令但不会用”上。希望大家把这一套从装到调、从单机到集群的路子走一遍，踩过的坑自然就是你的经验。如果后面有时间，我再聊聊Redis 7新增的底层数据结构优化，以及多线程IO模式下运维指标的变化，这些又是另一个坑位了。