企业官网建设流程全解析

刚从一次线上事故的复盘会上出来，起因就是一张缓存表在高峰期被击穿，Redis的CPU打到80%，数据库连接池瞬间被占满。这场面在后端圈子里太常见了，而每次复盘到最后，大家都会回到同一个话题：Redis的应用场景到底怎么设计才算合适。

我做了十几年后端，几乎所有上线的系统里都有Redis的影子。缓存、分布式锁、排行榜、计数器、消息队列、签到统计，甚至延迟任务，Redis基本上成了分布式系统里绕不开的中间件。这篇文章，我想把这些年实际项目里用Redis做过的场景梳理一遍，每个场景都讲清楚为什么这么设计、背后踩过哪些坑，而不是给你堆一堆API语法。不管你是刚学Redis的初级开发，还是已经在线上摸爬滚打过的老手，这轮剖析都值得花十分钟看完。

1. 为什么万物皆可Redis：从设计定位看应用场景

1.1 Redis在系统里的真实位置

很多同学会把Redis理解成"一个高级一点的缓存"，这么想不算错，但会严重低估它在系统里的地位。按照官方自己的定位，Redis是一个内存数据结构存储系统，关键词在"数据结构"四个字上。它不像Memcached那样只能存简单字符串，而是内置了String、List、Hash、Set、ZSet、Stream、Bitmap、HyperLogLog这一整套数据形态。

这意味着什么？意味着很多原本需要写一堆业务代码、甚至专门建表的逻辑，在Redis里就是一次原子命令的调用。我在项目里最深的体会是：决定一个功能要不要用Redis，核心看两件事——这个数据是不是被高频读取，以及这个操作需不需要原子性。如果两个条件里中了一个，那Redis通常就是最合适的落点。

但也要泼一盆冷水。Redis不是银弹，它受限于内存，数据是易失的（即便有持久化也无法和磁盘数据库比），单线程模型下某些命令会在特定场景拖垮整个实例。应用场景选对了，它是加速器；选错了，它是事故的起点。后面每一个场景我都会顺便说一句"什么情况不该用"，这一句往往是实战经验里最值钱的部分。

1.2 五种基础数据类型到底对应哪些业务场景

不看场景聊数据类型是耍流氓，我直接用项目里真实用过的案例来拆。

String类型是这个数据库里最基础的形态，我的使用场景是：用户会话Token、接口幂等键、短信验证码、分布式ID的起始种子。Token这类数据，如果在MySQL里建表查，每次请求都得走一次索引，高频场景下这个成本完全没必要；放在Redis里，一次GET就是微秒级。更关键的是可以顺手设置过期时间，登录失效这种逻辑直接交给Redis完成，业务代码不用自己维护定时清理。接口幂等键用的是SETNX的原子性，同一时刻只能有一个请求写入成功，天然支持去重。

List类型在现场用得最频繁的场景是"最新动态列表"和"简易消息队列"。比如资讯App的首页Feed流，用户刷新时不需要从数据库翻几百条记录再排序，而是直接LRANGE取最近20条，新内容用LPUSH往头部插，旧内容用LPOP慢慢淘汰。这个模型在"时间线"类功能里非常好用，我在两个社区类项目里都这么实现了，上线后查询耗时从200多毫秒掉到5毫秒以内。

Hash类型适合存"一个对象的多个字段"，比如用户画像、商品信息、会话详情。我有个直播项目，把主播的在线状态、观看数、推流地址全部塞进一个Hash里，每次更新只需要HSET一个字段，不用像MySQL那样整行UPDATE。更重要的是省内存——Hash内部对小型数据做了压缩存储，比每个字段单独存String省非常多。

Set类型天生就是干"去重和集合运算"的。典型的场景是抽奖活动里的中奖用户去重、电商系统的已购用户判断、社交网络里的共同好友。SADD、SISMEMBER、SINTER这三个命令我在活动类项目里写到手软。举一个真实的例子：运营要拉取"最近7天签到的用户和最近3天活跃的用户交集"，在MySQL里是两个子查询的麻烦事，在Redis里就是SINTERSTORE一条命令。

ZSet是最容易被低估的类型，因为它在"带权重的有序集合"这个模型上做到了极致。排行榜、热搜榜、延时队列、滑动窗口限流，全都适合用它。原理上每个成员绑定一个分数，Redis内部用跳跃表维护顺序，ZADD之后直接ZREVRANGE就能拿到TopN，排名计算不再需要ORDER BY + LIMIT这种数据库重型操作。

2. 缓存场景纵深剖析：穿透、击穿与一致性治理

2.1 三个高频故障场景：缓存穿透、缓存击穿、缓存雪崩

缓存穿透、击穿、雪崩这三兄弟，是Redis缓存应用场景下最容易出现的线上事故，也是面试题里永远翻不了篇的考点。我在正文开头提到的复盘会，问题根源就是缓存击穿。

先说缓存穿透。指的是查询一个数据库中根本不存在的数据，缓存里也没有，每个请求都直接打到数据库。最常见的来源是恶意攻击或者异常调用：拿一个不存在的ID反复刷接口，Redis永远查不到，MySQL被拖垮。解决这个问题有两条路，第一是接口层做参数校验，连格式都不对的请求直接拒绝；更系统化的方案是布隆过滤器——把所有可能存在的主键先存进Bloom Filter里，Redis查不到时先过滤一遍，过滤器说"没有"就直接返回空。我在高流量商品详情页这么做过，拦截率极高。还有一个非常朴素的兜底方案：即使数据库查出来是空结果，也往Redis写一个带短过期时间的空值，让后续请求至少不再穿透到数据库。

缓存击穿和穿透的区别在于：击穿是"缓存里有这个key，但是某一刻正好过期了"，同时有大量请求杀过来，大家全发现查不到，一起去数据库要数据。热点新闻、秒杀商品的详情最容易出这个问题。解决办法有两个主流方向：一是互斥锁，也就是用分布式锁把重建缓存的逻辑锁住，只让一个请求去查数据库，其他请求等缓存被写好后再取；二是逻辑过期，value里存一个逻辑过期时间，请求发现过期后先返回旧数据，再异步去更新缓存。这两个方案我都在生产环境用过，互斥锁的缺点是并发高峰期会有一小批请求在等待锁，逻辑过期方案的优点是无损，但实现复杂度更高，需要额外的后台线程维护更新。

缓存雪崩则是一大批key在同一时间同时过期，或者Redis实例本身挂了，导致所有请求全部砸向数据库。避免批量过期的方式是给过期时间加一个随机偏移量，比如TTL设置在1小时到1小时15分之间随机分布，这样它们就不会"手拉手"一起过期。Redis挂了这块没有捷径，高可用必须靠主从加哨兵，我们生产环境用的是三主三从的集群架构，具体选型我在第6部分展开。

2.2 缓存和数据库的一致性到底怎么保证

这一节可能是大部分系统上线后才开始疼的问题。先给结论：在绝大多数业务场景下，我们追求的不是绝对的强一致，而是最终一致。

目前工业界最主流、也是我用的最多的方案是Cache Aside模式，翻译成人话就是"先更新数据库，再删缓存"。为什么不是"先更新缓存"？因为写缓存和写数据库是两个事务，没有原子性保证，先写缓存的话一旦数据库写失败，缓存里就是一条脏数据，而且会一直存活。反过来先更新数据库、再把缓存删掉，就算删缓存失败，下次读取时发现缓存缺失，会重新从数据库加载，脏数据只存活一小段时间。

但这里有一个经典陷阱：并发场景下，线程A先更新了数据库，线程B读到了旧值，把旧值写进了缓存，之后线程A才去删缓存，删了个寂寞。业界对付这个有一套叫"延迟双删"的手法：线程A更新完数据库后，删一次缓存，等个几百毫秒，再删一次。期间线程B写入的旧值会在第二次删除时被清掉。延迟时间的选择有讲究，宁可略长也别太短，我一般取业务读操作耗时上限的1.5倍左右。

还有个跟一致性强相关的话题：缓存更新方式。热词里有个"redis缓存治理"，很多团队聊治理其实就是解决"缓存数据源头不清晰"的问题。我强烈建议把缓存key的生成规则、TTL时长、更新方式、删除时机全部用文档固定下来，并且在代码中集中管理，别让每个开发凭心情到处定义Redis key。跟着这种混乱治理风格走下去，早晚会出现同一份数据两个key同时存在、两边数据互掐的情况。

2.3 序列化方式与连接工具：最容易被低估的细节

Redis本身不关心你存进去的对象长什么样，它存的只是字节数组。于是序列化方案就成了一个隐形巨坑。Java生态里最省事的是直接用JDK默认序列化，但结果是key和value都能塞进一大堆不可读的转义字符，\xAC\xED这种乱码在Redis客户端里根本没法排查问题。

我在团队里统一过一套规范：对外展示或者需要跨语言读取的数据，一律用JSON字符串存，比如用户信息、订单详情；对内部纯业务运算的数据，可以用Protobuf或者Kryo这类二进制序列化来压内存和带宽。这个选择背后是调试成本和传输效率的权衡，JSON可读性强方便排查问题，二进制序列化性能更好体积更小。对于新项目，我现在的倾向是直接用String + JSON起步，等确认性能瓶颈真的在序列化上再去换，过早优化没有意义。

连接工具这块，热词里的Redis Desktop Manager、Another Redis Desktop Manager、Redis Insight我都用过。个人体验排序是：Redis Insight最好用，官方出品，能看内存分析、慢查询日志、命令耗时统计，非常适合排查问题；Another Redis Desktop Manager开源免费，功能也全，适合团队内部普遍部署；Royal TS等终端客户端就不多说了。建议至少人手装一个可视化客户端，线上出问题时用命令行加可视化双管齐下，效率完全不一样。

3. 分布式锁：Redis应用场景里最烫手的山芋

3.1 分布式锁到底要解决什么问题

为什么单机锁不够用，非要分布式锁？一句话解释是：单机的synchronized或ReentrantLock只锁得住同一个JVM内部的线程，而现代系统部署了多台机器，一个定时任务在三个节点上同时启动，三个JVM各持一把锁，那任务就被执行了三次。

我遇到过的真实案例：订单超时自动关单的任务，因为没加分布式锁，凌晨一点坏掉的那次把同一个订单连续关闭了两遍，给客服制造了一堆售后工单。这就是分布式锁的核心应用场景：跨进程、跨实例互斥。秒杀扣库存、定时任务防重复、多机环境下防止并发写同一个数据文件，这些都是我实际负责过的场景。分布式锁不一定要用Redis实现，ZooKeeper、etcd都行，但Redis因为部署广泛、操作简单，成为大多数团队的首选。

3.2 一把可靠的Redis锁应该长什么样

很多人写的第一个分布式锁是这么来的：SETNX尝试设置一个key，设置成功的人获得了锁，用完再DEL掉。这个版本在低并发下好像没什么问题，但一旦并发上来全是漏洞。

第一处是原子性陷阱。SETNX之后如果在设置过期时间前程序崩溃了，锁永远不释放，所有线程全部锁死。正确姿势是用一条命令完成加锁和过期时间设置：SET lock_key unique_value NX PX 30000。NX表示只有key不存在时才设置，PX设置毫秒级过期时间，这一整条是原子的。

第二处是误删锁的问题。线程A获得锁后业务处理超时，锁自动过期了，线程B拿走了锁开始干活，此时线程A终于执行完，直接DEL锁——它把线程B的锁删掉了。正确做法是在value里放一个唯一标识，比如UUID，删除前用Lua脚本比较value是否一致，一致才删。我写过一个标准脚本，大概长这样：

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

第三处是锁过期时间该怎么设。设太短，业务没跑完锁就过期了；设太长，一旦持有锁的节点真挂了，其他节点要等很久。我这个场景的做法是给锁加个"看门狗"续期机制，开一个后台线程每过三分之一过期时间就自动续期一次，业务结束时主动释放。这个逻辑看起来不复杂，但自己实现容易在边缘场景翻车，所以我会直接建议用Redisson框架，它的watchdog机制就是干这个的。

3.3 Redisson、Redlock与主从切换的权衡

说句掏心窝的话，生产环境我首选Redisson的分布式锁，它内部已经把可重入、看门狗续期、公平锁、红锁这些能力都实现了，没有必要自己去造轮子。Redisson的看门狗默认续期为锁的leaseTime的三分之一，只要客户端进程活着，锁就不会因为业务执行太久而自动释放，有效避免了我前面说的"锁超时自动过期"的尴尬。

Redlock是Redis作者提出的一种多节点容错锁算法，核心思路是在5个独立Redis实例上依次加锁，超过半数成功才视为抢锁成功。但关于Redlock是否值得在生产上使用，业内争议非常大，包括著名分布式系统专家Martin Kleppmann都写过文章反驳它。我自己的判断是：如果你的系统允许短暂的不一致，单点Redis锁足够；如果必须强一致，那更靠谱的方案是etcd或ZooKeeper，而不是去追求Redlock那点理论上的"更可靠"。真正把锁用出问题的场景，往往不是锁算法本身，而是业务逻辑对锁临界区的定义不清晰。锁里面干了太多耗时的操作，再好的锁都救不了你。

4. 消息队列与异步削峰：Redis的另类战场

4.1 List做队列：经典但有限

Redis在很多系统里还扮演着轻量级消息队列的角色，热词里那个"redis做中间件"就是这么来的。用List做队列的核心逻辑就是LPUSH往左边塞消息，RPOP从右边消费消息，阻塞版本BRPOP还能让消费者在没有消息时挂起等待，省掉写轮询的麻烦。

这种做法的优势极其明显：零额外组件、消息不丢失、天然支持简单的生产消费模型。我在一个内部工单系统里就用它做过异步通知队列，运营提交一个批量任务后，后台服务把任务ID塞进List，一个独立的消费者线程组从List里取任务慢慢执行，用户接口不用等批处理完成，体验提升极其明显。这种场景下List用得挺舒服。

但它有硬伤：不支持多消费者组的概念，每条消息被一个消费者抢走之后就没了，不能像Kafka那样每个消费者组都拿到一份完整消息；也没有ACL权限体系、没有消息确认机制。尤其要注意的是，RPOP取出消息后，如果消费者进程在业务处理时崩溃了，这条消息就彻底丢了。我的经验是：异步通知、日志收集这类"丢了影响不大"的场景可以用List；订单状态流转、支付回调这种一条都不能丢的，老老实实换专业MQ或者用Stream。

4.2 Stream类型是正儿八经的消息应用场景

Redis 5.0引入的Stream类型，是官方为消息队列专门设计的答案。它和Kafka的模型很接近：消息会有自己的ID，可以持久化，支持消费者组、ACK确认、待处理消息列表这些重要能力。XADD往Stream里写消息，XREADGROUP可以让多个消费者分别消费不同消息，消费完用XACK确认。

我在一个日志采集系统里实践过Stream方案，来替代原先用List实现的日志管道。改进后最大的收获是：消费者崩溃了，消息还在PEL（Pending Entries List）里，重启之后可以再次领取处理，真正做到了不丢消息。配合MAXLEN参数把Stream长度限制住，几亿条日志也不会撑爆内存。如果团队不想引入Kafka那么重的依赖，Stream是一个相当均衡的折中方案，它既保留了Redis的部署便利，又补上了List队列最缺的可靠性。

4.3 基于ZSet的延迟队列：一个精巧到拍大腿的方案

延迟任务是消息队列领域的老大难。你有一个订单下单后30分钟未支付，需要自动关闭；一个优惠券在某个时刻要自动失效；一个定时提醒要在明天早上九点触发。这类"我说啥时候执行、就啥时候执行"的任务，叫延迟任务。

Redis的ZSet是当前中小规模系统里实现延迟队列的绝佳方案。思路极其简单：把任务ID作为member，执行时间戳作为score，塞进ZSet。然后起一个后台线程，周期性用ZRANGEBYSCORE扫描score小于当前时间戳的所有任务，取出来扔进真正的执行队列或者直接执行，执行完用ZREM删掉。这个方案的复杂度可以控制得很低，我在优惠券过期自动失效项目里就是靠它支撑了日均百万级延迟任务的调度，任务按时触发率达到99.9%以上，完全满足业务要求。

要注意的是，这个方案存在单线程扫描的调度延迟，通常会有秒级的误差，对误差要求极苛刻的场景需要另寻出路。另外，任务执行完忘记ZREM的话，会导致同一任务被反复执行，幂等设计要做好。仍然需要的是，如果要跨节点共享延迟任务，还是那句话，上Kafka或者专业的任务调度系统更稳妥。

5. 计数器、排行榜、签到统计：把Redis用到极致的小而美场景

5.1 原子计数器与接口限流

很多业务场景需要的就是"数字+1"这个操作，比如文章阅读数、视频播放量、商品销量、点赞数。如果用MySQL做，每一次加1都是一次行锁更新，并发一高整个表都被锁拖累，性能和成本都很差。

用Redis就是INCR一条命令收工。INCR的原子性由Redis单线程模型天然保证，并发环境下多个请求同时INCR，结果一定是准确的，不会出现"同时读到一个值再写回去导致丢更新"的经典并发问题。我的处理流程是：先INCR一个计数key，后台通过异步任务定期把计数值同步回MySQL，期间前端展示的数据直接读Redis。这个模型下，数据库的写压力被削平了，读性能也几乎无损。注意要给计数key设置持久化，并且在大促活动结束后要做一次全量回源，防止Redis重启弄丢数字。

接口限流也是个特别典型的应用场景。最简单的计数器限流是：每个用户每分钟调了100次接口，超过就拒绝。实现上就是INCR这个用户的限流key，第一次调用时同时设置60秒过期，之后每次调用先INCR再判断当前计数是否超过阈值。这个方案单机很好用，缺点是它不是滑动窗口，会在每个窗口边界出现两倍的突发流量。更平滑的版本是用ZSet记录每次调用的时间戳，每次请求前ZREMRANGEBYSCORE清掉窗口外的历史记录，再统计窗口内的请求数，就能做到精确的滑动窗口限流。我在抢券活动接口上用的就是后者，实际效果非常稳。

5.2 ZSet排行榜：从热搜到积分榜的一行命令

排行榜大概是程序员能在面试官面前讲得最开心的一个Redis场景，因为ZSet简直是为它量身定做的。它的内部结构是"member + score"，score可以是任意双精度浮点数，于是你能想到的任何"打分排序"都能装进去。

热搜榜的实现：某条内容被点击一次，ZINCRBY hot_board 1 content_id，分数自动加1。然后ZREVRANGE hot_board 0 9 WITHSCORES取分数最高的前10条。整个过程不需要排序算法，不需要数据库查询，两个命令出结果，查询耗时稳定在个位数毫秒级。我做过的游戏积分榜、新人排行榜也全是同一套逻辑，score换成积分值而已。

这里有个实战小技巧：有时候业务榜单不只是按分数排，比如"分数相同的情况下，先达到的人排在前面"。ZSet的分数是单个数字解决不了这种tie-break规则的，我的处理办法是把score设计成一个足够大的整数，用"分数 * 10^N + (最大时长 - 耗时)"拼出复合分数，这样就能同时表达两个排序维度。这种把业务规则压缩进一个score的技巧，在高T恤竞争环境里经常用到。

5.3 Bitmap与HyperLogLog：两个不占内存的统计神器

签到统计是Bitmap的经典应用场景。一个用户一年签到了多少天，很多人第一反应是建一张签到表，一行一条记录。我实际做过的想法是：给每个用户维护一个365位的位图，每个bit代表一天，签到了置1，没签到置0。用SETBIT和BITCOUNT就能查“历史累计签到天数”，用BITFIELD可以批量查出某个月的签到情况。

更夸张的是，Redis支持对两个Bitmap做BITOP位运算，比如统计两个都签到的用户交集，直接把365个bit做AND操作就行，这个速度比数据库里的JOIN快了不止一个数量级。内存成本方面，一个用户一年只需要365位，也就是46个字节，100万用户也才46MB，这就是位图压缩的恐怖之处。

HyperLogLog则是统计UV（独立访客数）的优选方案。它的原理是用固定大小的内存（默认约12KB）去估算一个集合的去重基数，标准误差在0.81%左右。拿一个每日2亿UV的资讯App来讲，如果用Set存用户ID，内存是个天文数字；用HyperLogLog，一天的数据就是十几KB的量级，误差还在业务可接受范围内。我们在两个头部项目里都用PFADD一个key + PFCOUNT取去重值，实现了亿级UV的近乎零成本统计。需要提醒的是，HyperLogLog是估计值，不是精确值，绝对精确的去重场景不适合，比如财务对账这种一分钱都不能错的，就别用了。

6. 高可用与持久化：让Redis自己也要扛得住场景

6.1 单机、主从、哨兵还是集群：部署形态怎么选

应用场景决定了部署形态，这是我从不敢省的一环。开发环境用单机Redis就够了，本地跑个redis-server.exe，或者用Docker拉一个容器，不要浪费精力搭集群。但生产环境如果只上了单机，那一旦Redis进程崩溃，整个应用层缓存全灭，甚至业务直接瘫痪。我见过太多初创团队在这上面栽了跟头。

生产上最经典的形态是主从加哨兵。主节点负责写，从节点负责读，哨兵进程监控主节点的状态，主节点挂了自动把一个从节点提升为新的主节点。这套架构在绝大多数读写比例高的业务场景里都够用。主从同步带来的延迟问题也值得关注，通常从节点会落后主节点几十毫秒，在一致性要求高的场景要强制读主库。

数据量再上一个台阶，或者需要横向扩展写能力的时候，就要上Redis Cluster。它把数据按key哈希到16384个槽位，分布在多个主节点上，每个主节点配上从节点保证可用性。比如热词里就有人搜"k8s redis 集群"，在Kubernetes里部署Redis集群是常规操作，StatefulSet挂持久化卷，配合Headless Service做节点发现。Cluster方案我唯一想提醒的是：不支持多key操作（除非key都在同一个槽位），也不支持跨节点事务，这些限制在业务建模时就得考虑进去，别等上线了再做跨槽位的操作然后报错。

6.2 持久化机制详解：RDB和AOF怎么搭配才合适

Redis虽然是内存数据库，但提供了持久化能力。RDB和AOF是两大核心机制，很多人在配置Redis时忽略这两者的选择，结果Redis重启后缓存数据全部丢失，数据库被一波请求撞翻。

RDB是"定期给内存拍一张快照"，默认配置比如save 900 1表示900秒内至少有1个key变化就触发一次快照。RDB的恢复速度快，文件体积小，适合做冷备份和灾难恢复。缺点是它不支持秒级持久化，最后几分钟的数据可能全丢。AOF则是把每次写操作以日志形式追加到文件里，可以配置成每秒钟刷一次盘（appendfsync everysec），最多丢一秒的数据。AOF的问题在于文件体积会越来越大，恢复速度也比RDB慢。

我的经验是：如果Redis的角色是纯缓存，不存关键数据，那开不开持久化都行，甚至可以直接关掉；如果Redis里存了分布式锁、计数器、延迟任务这类有状态的数据，那必须开启AOF，并且搭配RDB做周期性快照。有些团队会配置"先写AOF，每天凌晨再生成一个RDB快照，并清理旧的AOF文件"，这个组合兼顾了恢复速度和数据安全。多说一句，生产环境AOF rewrite要留意触发阈值，别让AOF文件无限膨胀后把磁盘打爆。

6.3 部署后最常见的连接超时排查实录

连接超时是Redis场景里最让人头大的问题之一，热词里那条"redis command timed out; nested exception is io.lettuce.core.rediscommandtim"就是一个典型的报错，我在Spring Boot项目里看到过无数次。

Lettuce是Spring Boot默认的Redis客户端，它底层基于Netty做异步连接复用。出现RedisCommandTimeoutException，最常见的原因并不是Redis本身卡了，而是Lettuce的单个连接内的请求堆积。想象一个场景：某个大Key的查询命令执行得很慢，后面几百个请求都堵在同一条连接上排队，各自的超时时间一到，就集体抛RedisCommandTimeoutException。

排查路径我建议按顺序走：先看Redis的INFO命令找出慢查询，确认是哪些命令耗时长；再用redis-cli --latency对比网络延迟是否异常；然后观察应用日志里的超时分布，是单机还是全局性的。如果Redis那边各项指标都正常，那就调整Lettuce的配置参数，比如增加连接池大小、延长超时时间，或者关闭共享连接改用每次独立连接。我遇到过最离谱的一次超时，原因是应用服务器和Redis服务器之间的交换机开启了流控，把Redis的连接变成了小水管，Redis本身毫无压力，问题全在网络链路上。

7. 实战场上的避坑指南：大Key、慢查询与监控

7.1 大Key和热Key：缓存治理的第一杀手

大Key是指单个key存储的数据量过大，比如一个Hash里有几十万个字段，或者一个Set里塞了几百万个成员，或者一个String的值本身就有几十MB。大Key的危害在于：单次命令的操作耗时高，占用内存不均，删除时甚至可能阻塞整个Redis实例。

我踩过一次雷：项目里有人把用户的完整操作日志拼成一个超长字符串塞进Redis，单个key差不多20MB。平时读取还好，后来为了删除这个key做了DEL，Redis直接被阻塞了将近10秒，那10秒内服务端所有请求全部排队卡死。教训就是：删除大Key时不要用DEL，而要用UNLINK，它用的是异步线程回收内存，不会阻塞主线程。

热Key是指某个key在极短时间内被大量访问，比如热点新闻、秒杀商品。热Key打爆单节点后，Team里通常的做法是对key做本地缓存，或者把key多写几个副本分散到不同节点上。检测手段我用过redis-cli --hotkeys和Redis内置的LFU统计功能，先定位到具体key再针对性地设计缓解方案。

7.2 慢查询与阻塞操作：能避免就绝不手软

Redis是单线程模型，这里的“线程”指的是处理命令的主线程。任何一条命令执行过久，都会把后面所有命令堵住。最容易制造阻塞的命令就那么几类：KEYS *，它要遍历整个key空间，哪怕只有几十万key也会让Redis卡上几十毫秒到几秒；HGETALL取一个超大Hash；SORT在大集合上执行；还有O(N)复杂度的ZRANGEBYSCORE等。

我给自己定过一条规矩：生产环境永远不执行KEYS命令。真要遍历key，用SCAN命令配合游标分批获取，虽然慢，但不会阻塞主线程。排查阻塞操作可以靠SLOWLOG GET命令查慢查询日志，里面记录了执行时间超过阈值的命令，然后针对性地优化。比如把一次HGETALL拆成多个HMGET，或者把大集合拆散成小集合，都能有效降低单次命令的耗时。

7.3 日志与监控：不盯紧就等着半夜被叫醒

Redis的日志和监控在应用场景里属于那种"平时感觉没用，出事时救命"的东西。官方自带的INFO命令能看内存、客户端连接数、命中率、持久化状态；CONFIG SET slowlog-log-slower-than 10000可以设置慢查询阈值，再通过SLOWLOG GET查看。可视化方面，Redis Insight自带dashboard，Prometheus + redis_exporter也是标准组合，能采集大量指标到Grafana出图。

我在团队里维护过一个监控规则速查表：内存使用率超过80%要告警，因为触发淘汰策略后缓存命中率会大跌；连接数超过maxclients的70%要告警，因为新连接会被拒绝；主从复制积压缓冲区持续增长要告警，说明从节点可能长期掉线。监控的作用不是让你看到问题，而是让你在用户感知到之前就把问题按死在摇篮里。日志这块，除了Redis自身日志，更重要的其实是应用侧的访问日志——把每条Redis命令的耗时记录到日志系统里，出了慢查询能直接定位到是哪条业务逻辑引入的，这个排查效率比对着Redis内部瞎猜高太多。

我个人这些年养成的习惯是：每次排查完一个问题，就把对应的命令和场景记录到一个自己的知识库里，比如今天说的缓存穿透、大Key删除、连接超时，都配上一段真实事故的背景描述。这样下次再遇到类似问题，不用重新从头开始排查，直接按经验去验证就好。Redis的应用场景虽然多，但真正让人成长的不是背了多少命令，而是踩过多少坑之后，能把这些坑讲得清清楚楚。