Redis项目设计实战：从角色定位到缓存治理的完整决策链路

接到一个项目要引入Redis，很多人第一反应是先装一个单机实例把缓存跑起来，等到线上出现大Key告警、缓存穿透把数据库打崩、主从切换丢数据之后，才回头去想当初到底该怎么设计。我经历过不止一次这样的重构，坦白讲，Redis本身很简单，难的是围绕它做项目设计的那一套决策链路：角色定位、架构选型、数据建模、缓存治理、部署监控，每一步都直接决定你后续是省心还是救火。

这篇内容就是围绕“Redis的项目设计”这个话题，把我在多个项目里沉淀下来的设计思路、参数依据、踩坑记录完整梳理了一遍。适合正在做技术方案的后端开发、准备晋升答辩的同学，也适合那些Redis已经上了线、但总在出问题想系统治理一遍的团队参考。我会尽量把每个决策背后的“为什么”讲清楚，而不是只给结论。

1. 项目设计中Redis的角色与架构选型

1.1 把Redis当什么用，决定了设计的起点

Redis在项目里到底扮演什么角色，这句话看起来像废话，但我在评审代码时发现，很多设计混乱的根源恰恰是把角色混在一起了。同一个Redis集群里既存了业务缓存，又存了分布式锁，还存了异步队列，最后互相干扰：一个慢查询拖慢了全链路，一次内存淘汰把热数据全清了出去，出了问题你连排查方向都分不清。

所以我做项目设计的第一件事，永远是先明确Redis承担哪几类职责，再按职责去拆分设计。

最常见的角色类型有三类。第一类是纯缓存，这也是最广泛的使用场景，核心特征是数据允许丢失、允许一定延迟不一致，主要价值是把数据库的读压力扛下来。第二类是分布式同步原语，比如分布式锁、分布式信号量、幂等控制，这类数据对一致性要求极高，一旦锁失效或重复获取，会直接引发资损或者业务错乱。第三类是数据结构服务，也就是把Redis当作具备特定数据结构的存储来使用，比如用ZSet做排行榜、用Stream做消息队列、用Set做交集并集运算，这种场景下Redis实际上承担了业务状态存储的责任，数据丢失就是事故。

角色定位清楚了，后面的缓存策略、持久化配置、备份方案都会跟着变得清晰。举个例子，纯缓存场景你完全可以把持久化关掉，或者配置成RDB快照即可，省掉AOF重写的开销；但如果Redis在存业务状态，你不仅要开AOF，还要考虑主从复制和定期备份恢复演练。

我个人的习惯是，在项目设计文档里先画一张表，把每个Redis库或集群对应到具体业务模块、数据量级、访问QPS、允许丢失的时间窗口、对应的一致性要求。这张表填完了，架构选型基本就水到渠成了。

1.2 单机、主从、哨兵、Cluster，怎么选不纠结

选型是Redis项目设计里最容易被拍脑袋决定的一环。很多团队小项目上线时就开了个单机Redis，出了故障直接重启恢复；也有团队过度设计，几千QPS的规模直接上Cluster，结果运维成本翻了几倍，客户端维护复杂度也上来了。

我的判断逻辑其实很简单：先看可用性要求，再看数据量，最后考虑成本。

单机Redis适合什么场景？开发环境、测试环境、内部工具、允许停机半小时以上的低价值业务。它的问题是单点故障，没有自动恢复能力，内存容量受限于单台机器。如果你们的服务是单机部署，Redis单机也就无所谓了，但只要有多个应用实例同时在跑，单机Redis迟早出问题。

主从加哨兵（Redis Sentinel）是目前中小项目的标准配置：一个主节点负责写，一个或多个从节点负责读和备份，Sentinel负责监控主节点的健康状态，主节点挂了会自动把从节点提升为新主。这套方案能解决自动故障转移的问题，读性能还能水平扩展，但对写容量和总数据量没有帮助，适合数据量在单机内存可容纳范围内（比如几十GB以下）、读写比例有明显倾斜的业务。

Redis Cluster则是数据分片方案，它把数据按哈希槽分布在多个主节点上，每个主节点再挂从节点做高可用。Cluster适合单机内存装不下的场景，或者写入QPS已经超过单节点能力的情况。代价是：多Key操作受限于槽位分布（事务、Lua、multi-key操作会变复杂），客户端需要处理MOVED重定向，运维监控面也更大。

我见过不少团队拿着几千的QPS硬上Cluster，然后被跨Slot操作和各种客户端问题折磨。这里我的建议是：QPS在10万以内、数据量能装进一台物理机，优先考虑主从加哨兵；只有数据量或写入吞吐明确超出单机上限，再上Cluster。另外提醒一点，Cluster模式下key的分布和批量操作的约束，要在一开始就同步给所有开发同学，不然后面会出现一堆NowAllowed的运行时错误。

1.3 容量规划与内存预算：先把数据算明白再动手

容量规划是项目设计里最容易被忽略、又最容易被线上故障打脸的一环。Redis是内存数据库，内存即成本，而且内存的增速往往比业务增长更吓人。我一般会在方案阶段做三个估算：数据总量、峰值QPS、内存增长模型。

数据总量的估算要结合业务场景算。假设你要缓存用户基础信息，单条JSON序列化后约1KB，缓存1000万用户就是约10GB原始数据，加上Redis自身的键空间开销、序列化对象的膨胀率、碎片率，内存水位至少要按原始数据的1.5倍到2倍去预留。所以我通常按一条缓存记录加Key的大小，乘以预估记录条数，再乘1.8的安全系数，作为最小内存预算。

QPS估算要分读和写。Redis单实例的读写能力通常能到10万级QPS，但这不等于你可以随便压满。你需要结合实际命令的复杂度来看，比如O(N)的批量命令或大Value的读写，都会显著拉低单实例的吞吐上限。如果在设计阶段预估到某个业务维度的热点Key会出现极高并发（比如秒杀、热点新闻），就要提前设计本地缓存兜底，或者考虑对Key做热点打散。

内存增长模型这块，最容易忽视的是缓存失效和淘汰策略。如果业务采用了TTL过期，内存水位相对可控；如果有些Key没有设置TTL且持续累积，就会出现所谓的“内存泄漏型增长”。我强烈建议在项目上线前，跟业务方确认每一个缓存Key的TTL设计，没有TTL的Key要单独列清单，确认其存在合理性。

2. 数据建模与序列化：最容易返工的一环

2.1 数据类型选型：用得对，效率翻倍；用得错，四处救火

Redis的数据类型是项目设计里最基础也最关键的技术决策。我在代码评审里见过太多“万物皆String”的写法，比如用一个String Key存整个购物车JSON，每次加购都要先读出整个JSON再反序列化、修改、再序列化写回。这种方式在读写并发低时没问题，一旦流量上来，不仅网络开销大、序列化消耗高，还会频繁触发大Key问题。

正确做法是先按业务访问模式选类型。购物车这种需要频繁改字段的，用Hash更合适，每个商品ID作为field，数量作为value，加购就是一条HSET命令，不需要读全量数据。排行榜用ZSet，分数作为排序维度，天然支持按名次区间拉取。标签、好友关系这种集合运算场景用Set，交并集直接由服务端计算，避免数据拉到客户端再算。实时UV统计可以用HyperLogLog，单key消耗内存极低，允许一定误差时是首选。需要按时间线拉取消息或操作流水时用List，或者用Stream做消费者组消息队列。

这里有一个容易踩的坑：很多人会把List当成可靠消息队列用。Redis的List作为简单异步解耦是可以的，但它不是真正的消息队列，消息可能丢失（没有确认机制）、消费进度完全靠客户端维护。如果业务需要可靠投递、消息回溯、消费者组管理，Stream比List可靠得多。如果业务量级大、可靠性和生态要求更高，那就不应该用Redis做消息中间件了，还是交给专业的消息队列产品更稳妥。

数据类型选型我还会建议多想一步：这个Key未来的访问模式会怎么演变。比如一开始你用String存了一个用户的关注列表JSON，后面需求变成了“判断用户A是否关注了用户B”，JSON方案需要全量读取再判断，而Set方案用一个SISMEMBER命令就完成了。数据建模往前多想一步，能减少后面大量的数据迁移工作。

2.2 Key命名规范与序列化方案：越早统一，后面越省心

Key的命名规范在项目设计阶段如果不定下来，后面根本没法治理。我在代码评审里最常看到的问题就是：有的Key用业务名+ID，有的直接用Java对象toString，有的带着随机UUID，完全没办法从Redis里看出这个Key属于哪个模块、缓存的是什么数据。

一套务实的Key命名规范至少要包含三段信息：业务域、模块或场景、唯一标识。比如 user:profile:123456、order:detail:{orderId}、promo:stock:{skuId}。冒号分隔是为了配合Redis的键空间扫描和层级展示，也方便在可视化工具里按前缀过滤。团队内还需要约定最小长度和禁止字符（比如禁止空格、换行），否则排查问题时眼睛先瞎掉。

序列化方案的决定同样要前置。Java后端最常见的问题是直接用JDK原生序列化（Java Object Serialization），Value存进Redis是一坨带类型头的二进制，用可视化客户端一看全是乱码，排查问题全靠猜。更严重的是跨语言互通几乎不可能，后续如果有Python或Go的服务要复用同一份数据，直接抓瞎。

我在项目里一般推荐JSON序列化，配合统一的日期格式和类型信息，可读性好、跨语言友好、排查问题方便。对性能要求极高的大Value可以换MessagePack、Protobuf这类二进制协议，但前提是团队能接受排查时不直观的成本。Key本身我用字符串，Value则根据数据类型做区分：String直接存序列化后的文本或二进制，Hash的field用短字符串，ZSet的score用数值。

序列化还有一个坑是类结构变更。Java侧如果改了字段名或类型，老数据反序列化可能直接报错。所以生产项目的缓存Value建议预留版本字段，比如JSON里加一个 version 字段，反序列化时做兼容处理。这个细节看着小，线上出故障时能帮你避免一次全量缓存失效。

2.3 缓存粒度与TTL策略：不是所有数据都值得塞进Redis

缓存粒度设计决定了你后续的维护成本和一致性复杂度。粗粒度缓存（如整表、整对象）实现简单、命中率高，但任何字段变更都要更新整个缓存，并发更新时很容易出现旧值覆盖新值；细粒度缓存（如单字段、单SKU）更新精准、冲突少，但Key数量膨胀，管理成本和内存占用都会上升。

我的建议是区分读写比例。读多写少、变更频率低的静态数据（如商品基本信息），用粗粒度整对象缓存没问题；读多写也多的数据（如库存、用户积分），必须拆到细粒度，否则更新缓存几乎等于重写一遍业务。还有一种数据不适合进Redis：更新极其频繁且读方可以容忍延迟的，比如实时在线人数，这种更适合直接计数落库，或者用很短TTL搭配异步刷新。

TTL设计是缓存项目设计里最见功底的部分。TTL太长，数据陈旧时间变长，内存压力大；TTL太短，缓存命中率低，数据库压力又上来了。我一般用两个维度来定：数据变更频率和业务容忍的延迟。比如商品价格，后台改价后希望几分钟内生效，TTL可以设10分钟；用户昵称这种低敏感数据，TTL可以放到1小时到1天；配置类数据如果希望秒级生效，就别用缓存，或者用Redis的发布订阅做主动失效。

还有一个TTL的经典坑，就是“缓存雪崩”的诱因之一：大量Key同时设置了相同的过期时间，比如统一缓存某个报表数据，凌晨0点集体失效，瞬间所有请求打穿到数据库。解决方案是过期时间加随机扰动，比如基础TTL 3600秒，再随机加0到300秒偏移，让失效时间分散开。这个设计虽然简单，但真的能救命。

3. 缓存治理：可用性与一致性的攻防设计

3.1 缓存穿透、击穿、雪崩：三种故障模式要分开治理

缓存治理几乎是Redis项目设计里最核心的交付物。面试八股里常说的缓存穿透、击穿、雪崩，到了真实项目里就是实实在在的线上故障。

缓存穿透是指查询一个根本不存在的数据，缓存里没有，数据库里也没有，每次请求都打到数据库，攻击者可以用大量不存在的ID把数据库拖垮。我项目里常用的解法有四层：第一层是接口层参数校验，非法ID直接拦截（比如负数、超大数、格式错误）；第二层是缓存空值，即把不存在的Key也缓存一个空结果，并设置较短的TTL（比如2到5分钟），让查询快速返回；第三层是布隆过滤器，把存在的ID预热进布隆过滤器中，不存在的ID直接挡住，适合数据量巨大、空值缓存压力大的场景；第四层是限流与降级，防止恶意流量把整个系统打挂。

缓存击穿是指某个热点Key在失效的瞬间，大量并发请求同时回源。解决思路核心是“单飞去DB查”：用互斥锁（分布式锁或本地锁）保证只让一个请求去数据库重建缓存，其他请求短暂等待后命中新缓存。还有一个方案是热点Key逻辑过期时间，Value里存一个业务过期时间，发现逻辑过期后异步线程去刷新，同时当前线程先返回旧值，这种方案对一致性要求不高但追求性能的场景很好用。

缓存雪崩除了之前说的同一时间大批Key失效外，还有一层含义是Redis实例宕机导致所有缓存请求穿透。后者靠的是高可用架构（主从哨兵/Cluster），前者靠TTL随机化和多级缓存（本地缓存+Redis）来减压。项目设计时建议把这三类故障放在同一张表里对应治理手段，评审时一目了然。

3.2 数据库与缓存的一致性：不要追求绝对一致，但要定义清楚最终一致

双写一致性是Redis项目设计里最容易被业务方追问、又最需要“讲清楚”的问题。我的立场很明确：缓存和数据库天然有状态差异，任何缓存方案都做不到强一致，除非放弃缓存。我们的设计目标应该是“最终一致”，并把不一致的时间窗口收敛到业务可接受的范围内。

目前业界主流方案是Cache Aside模式，也就是先更新数据库，再删除缓存。这个顺序有个细节要注意：为什么不先删缓存再更新数据库？因为删完缓存再更新数据库的窗口内，其他请求会读到旧数据库值并回填旧缓存，导致后续较长一段时间缓存都是脏的，所以主流方案都是先落库、后删缓存。

但“先更库再删缓存”本身也有一个经典的并发问题：请求A读到旧值准备写缓存，请求B更新了数据库并删除了缓存，请求A接着把旧值写回了缓存。解决手段业内常用“延迟双删”：更新数据库后先删一次缓存，等待一小段时间（比如500毫秒到1秒，具体取决于业务耗时），再删一次缓存，把窗口期里回填的脏数据覆盖掉。这个方案不够优雅但非常实用。

更进一步的设计是订阅数据库变更日志来删除缓存，比如监听Binlog，在事务提交后由独立消费者删除对应Key，这样代码里不用到处手动删缓存，一致性也更有保障。不过要承担额外的中间件运维成本，小型项目不一定值得。不管哪种方案，删除缓存本身可能失败（比如Redis短暂不可用），所以删除动作要带重试机制，或者通过消息队列异步化，最终保证缓存能被删掉。

我特别想强调一点：缓存一致性方案要写入接口设计的验收标准中。项目设计评审时，必须能回答“极端并发下这个接口的不良读比例是多少”，如果回答不上来，那设计方案基本还没想透。

3.3 分布式锁：一知半解最容易出事

分布式锁是Redis项目设计里“看似简单、实则风险极高”的一环。很多人写出来的第一版分布式锁是 SETNX key value 加 EXPIRE key seconds 两条命令分开执行，这其实是一个经典错误：如果SETNX成功却还没执行EXPIRE，进程挂了，锁就永远不释放。正确姿势是单条原子命令：SET key value NX EX seconds，或者用Lua脚本把加锁和设置超时合在一起执行。

另一个高频问题是不解锁别人的锁。进程A拿到锁后超时自动释放，进程B立刻拿到锁，此时进程A执行完业务，直接执行DEL，把进程B的锁给误删了。解决办法是加锁时设置一个唯一标识（比如UUID或业务请求ID），解锁前先用Lua脚本比较这个标识，匹配才允许删除。这里必须用Lua脚本保证“比较+删除”的原子性，单纯GET判断再DEL仍然有竞态窗口。

lua复制-- 解锁脚本，先校验持有者再DEL，避免误删他人锁
if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

还有一个更微妙的问题是“锁过期时间怎么设”。如果业务执行超过锁超时时间，锁先被释放，其他线程进入临界区，导致并发问题。常规解法是续期机制：启动一个守护线程，在锁快要过期时自动续期，直到业务执行完成。Redisson的 watchdog 机制就是干这个的，默认30秒锁超时，每10秒续一次。如果你没有用Redisson而是手写锁，一定要自己实现续期，否则就别把锁超时设得太短。

上了Cluster之后，Redis分布式锁还有一层深入讨论：主从切换时锁可能丢失。Redlock算法的本质是向多个独立节点同时加锁，但它在真实生产环境一直有争议（小概率失效、性能开销、时钟依赖）。我的实践建议是：如果业务并发量巨大且锁失效会造成资损，考虑引入专业的分布式协调组件（比如ZooKeeper或etcd）而不是在Redis层面硬扛；如果并发可控、能容忍极小概率的锁失效，那Redis分布式锁配合官方推荐实现是成本和复杂度最低的平衡点。

3.4 热点Key与大Key：缓存治理里的两个“隐形杀手”

热点Key和大Key是Redis项目设计中极易被忽视、却经常以最惨烈方式呈现的两个问题。我在线上排查慢查询的时候，十个里有八个跟这两者有关。

大Key的定义没有统一标准，但业界通常认为String类型的Value超过10KB、Hash/Set/ZSet的元素数量超过5000个，就要纳入治理范围。大Key的危害是：单次命令耗时变长、网络传输压力大、主从复制时全量同步变慢、删除或过期时Redis主线程可能卡顿。一个几百MB的Hash做一次HGETALL，可能直接把Redis主线程阻塞几百毫秒甚至秒级，全站接口跟着抖。

大Key的治理方式分拆和压缩两种。Hash可以拆成多个子Key，按业务维度、时间维度、ID范围拆；String可以压缩或改成Hash结构。还有一个必须小心的操作是删除大Key，直接用DEL在主线程删除大对象会卡顿，正确做法是用UNLINK命令（异步删除）或者分批删除（HSCAN+HDEL）。这个细节体现了项目设计时的预判能力，因为Redis里删除一个超大集合而把整台实例拖垮的事故，我见过不止一次。

热点Key的表现是某个Key在极端时间内承受了不成比例的流量。比如爆款商品秒杀时，一个商品库存Key可能被每秒数万次请求打穿，Redis单实例单线程处理这个Key时，其他请求全部排队变慢。治理方案有几条路：加本地缓存（JVM Caffeine）挡住大部分读；对Key做热点打散，比如把一个Key复制N份加后缀，读取时随机取其中一个，适合读多写少的场景；对写操作做合并和削峰（比如库存预扣减批量提交）。设计阶段就应该结合运营活动排期，识别哪些Key会在什么时间成为热点，而不是等活动流量真上来了才仓促应对。

在代码里，我对所有Redis操作都建议加慢命令监控和耗时统计，日志里单独记录大Key访问和热点Key访问，这样治理才有数据支撑。一个没有监控数据的缓存治理方案，等于闭着眼睛修水管。

4. 部署、监控与常见问题排查实录

4.1 部署方式与可视化客户端：环境搭得顺，开发效率高

Redis的项目设计不能只停留在代码层面，部署方式直接影响开发调试和运维排障的体验。目前团队常用的部署方式有三类：本地安装、Docker容器、Kubernetes托管，各有适用场景。

本地开发首选包管理器安装：macOS上推荐用Homebrew执行 brew install redis，安装后就可以用 redis-server 启动，redis-cli ping 验证连通。需要注意Apple Silicon（M系列芯片）和Intel芯片的Homebrew路径有差异，配置文件和二进制目录分别在不同架构路径下，如果升级系统后启动找不到配置，多半是路径变了。Windows本地开发推荐用WSL2跑Linux版Redis，或者直接使用Docker，原生Windows版Redis官方并不推荐用于生产。

Docker方式最适合统一开发环境。一条 docker run -d --name redis -p 6379:6379 redis:7-alpine 就能起一个实例，搭配 -v 挂载配置和数据目录，保证容器重启数据不丢。多实例或主从拓扑建议直接用Docker Compose编排，把主从节点、哨兵节点写在一个配置里，一条命令起全套。我在项目设计文档里会明确要求开发环境与生产环境保持相同的Redis主版本，避免本地用Redis 6、线上用Redis 7，一些命令语义和语法差异会让人排查到怀疑人生。

可视化客户端方面，Redis Desktop Manager是很多人的启蒙工具，但它在开源版上停了很久，新版合并进了Redis官方出品的RedisInsight。另一个很火的Another Redis Desktop Manager，界面简洁、跨平台、连接管理方便，对日常调试和Key浏览足够。我的个人习惯是：命令行用 redis-cli -3 和 --scan --pattern 做批量操作和统计，可视化工具用来快速浏览键空间、查看内存分布、执行简单的增删改查。如果项目有敏感环境，可视化工具慎用，建议通过堡垒机或只读账号访问。

4.2 Redis日志、慢查询与监控指标：出了故障才想起看日志就晚了

Redis项目设计里监控方案如果缺位，线上的Redis就是一个黑盒。我现在接手任何项目都会先确认三件事：慢查询日志开了没、内存监控告警配了没、大Key扫描有没有定期任务。

慢查询日志是排查Redis性能问题的第一入口。设计上需要关注两个核心参数：slowlog-log-slower-than 和 slowlog-max-len。前者单位是微秒，默认10000（即10毫秒），我一般会调低到2000到5000微秒，把耗时的命令捞出来；后者是慢查询日志条数上限，建议调大到256以上，防止高并发时日志被快速冲刷。排查时用 SLOWLOG GET 直接查看，能清楚地看到哪条命令耗时多少、什么时间执行、来自哪个客户端。

Redis日志文件记录了启动信息、持久化行为、复制同步状态、主从切换事件等，出现故障时要第一时间去翻。常见做法是配置 logfile 指定日志路径，日志级别生产环境用notice或warning，避免信息量过大。主从和哨兵模式下，切主事件是会打日志的，如果你发现某段时间业务出现大量报错，先查Redis日志里有没有“failover”相关记录。

监控指标里最核心的无非是内存、连接数、命中率、持久化状态。内存和连接数直接决定了Redis当前是否处于危险水位；缓存命中率反映了缓存设计的有效性，长期低命中率说明大量缓存根本没被利用上，需要回去看Key设计和TTL策略。INFO stats、INFO memory、INFO replication 这几组命令要熟，我每次排查问题都是从这里开始。

有一个监控上的小技巧：Redis的 MONITOR 命令可以实时打印所有命令，但生产环境千万不要开着它排障，它会把Redis拖垮。正确做法是短时间开启抓取一小段日志，或者用Keyspace通知（CONFIG SET notify-keyspace-events）监听Key过期和删除事件。我在项目里是用定时任务把慢日志和内存指标推到监控平台，再配上告警规则，这样故障发生前就有预警，而不是业务方反馈才被动去查。

4.3 线上故障实录：Lettuce超时、主从延迟和内存告警都怎么收场

这一节我从实际项目里挑三个高频故障做复盘，每一个都希望你在设计阶段就能预防。

故障一：Spring Boot项目不定时抛 RedisCommandTimeoutException，提示 io.lettuce.core.RedisCommandTimeoutException。 看到这个异常，大部分人的第一反应是调大Lettuce的超时时间配置，比如把 timeout 从2秒调到5秒。但实测下来，这只是把问题后移了，QPS一大照样超时。真正要查的方向，是Lettuce的底层连接模型发生了阻塞。

Lettuce基于Netty，默认多个线程共享同一个连接，它的设计是异步复用连接，目的就是省去频繁建连的开销。但问题恰恰也藏在共享连接上：如果某条命令是慢查询（比如大Key的HGETALL），就会阻塞这个共享连接上的后续命令，队头阻塞，表现就是客户端超时。这个故障的根治方向是：把大Key拆掉、慢查询优化掉，同时考虑切换到Jedis连接池模式或者给Lettuce配置连接池（commons-pool2），让不同线程尽量复用独立连接。调超时时间只是治标，排查源头才是治本。

故障二：主从切换后数据不一致。 这个故障多半出在处理异步复制上。Redis主从复制默认异步，主节点写成功后立即返回客户端，数据同步到从节点有延迟。一旦主节点在数据尚未同步到从节点时就宕机，Sentinel把从节点提升为主节点，这部分数据就丢了。设计上要分清业务对数据可丢失窗口的容忍度，完全不能丢的关键数据要启用WAIT命令等从节点确认，或者直接用强一致存储，而不是指望Redis。

故障三：内存水位告警，排查发现是某个业务Key没有设置TTL，而且每天都在累积新数据。 这类故障在我经历过的项目里几乎成了条件反射：内存告警出现后，先看 INFO memory 的 used_memory 和 maxmemory 水位，再用 redis-cli --bigkeys 扫出最大Key，追到业务方后发现是报表缓存没有设置过期时间。治理手段其实很常规：加TTL、固定最大Key容量、低频数据迁移到别的存储、定期使用内存分析工具扫描。但问题在于，很多项目根本没有建立这个“定期”的机制。

如果你连 --bigkeys 和 MEMORY USAGE key 都没用过，建议上手试试。MEMORY USAGE 可以单独看某个Key占用多少内存，在排查内存问题时非常高效。

4.4 上线前Redis自检清单：照着做，至少避开一半的坑

项目设计文档写得再好，落地上线时还是会有人漏配置、漏场景。我这里整理了一张自检清单，是我在多个项目上反复修补后沉淀下来的，新项目上线前直接照着过一遍，能避开一大半常见问题。

这张表看起来条目多，但其实每一项落实成本都不高。真正重要的不是做成文档锁在Wiki里，而是有人对清单负责，上线评审时逐条确认。

关于Redis的项目设计，我没有讲太深的内核源码或者底层数据结构细节，那些属于“了解”的层面。项目设计真正要交付的是一组决策：Redis在你系统里负责什么、以什么架构运行、数据怎么建模、缓存出问题怎么兜底、线上怎么观察和治理。把这几个问题想透，你的Redis项目就不太可能变成大家口中的“缓存事故重灾区”。

最后再分享一个我个人的小习惯：每次接到新项目，我会先把上面那张自检清单填一遍，哪怕有些项暂时用不上，也标记清楚为什么不用。等技术方案评审完、代码评审完、上线之后，我还会再回头对照一遍，把实际踩到的坑和当初的预估做对账。你会发现，绝大多数线上问题，其实在设计阶段都已经被前人踩过、被文档写清楚了，只是后来的人没看、没走心。把这些经验沉淀下来，比记住什么命令、什么参数都值钱。