想看看redis里到底藏了多少队列，顺便扒一扒它们的秘密和结构

那天下午，服务器又有点蔫儿，响应慢吞吞的，我寻思着，八成又是Redis里那些队列在“作妖”，这Redis就像个老仓库，大家都往里面塞东西，时间久了，谁也不知道角落里到底堆了些什么，我决定不再靠猜，得亲自进去“盘点”一下，看看里面到底藏了多少队列,顺便扒一扒它们的秘密和结构。

第一招：敲开门，先看个大概

要进Redis的门，得用钥匙，我打开终端，输入了那个熟悉的命令（来源：Redis官方文档 KEYS 命令），我没用那些花里胡哨的图形界面，就觉得黑底白字的命令行最有感觉，我敲下了 keys * ,回车！

好家伙，屏幕上瞬间滚出一长串键名，密密麻麻的，这可不是个好习惯（来源：Redis官方建议，生产环境慎用 KEYS *，因为它会阻塞其他请求），毕竟这是在大家都不怎么用系统的时候，我才敢这么干，我眯起眼睛，快速扫描着，果然，队列相关的键占了半壁江山，它们的名字也挺有意思，像“order:waiting:pay”（订单：等待支付）、“email:task:queue”（邮件任务队列）、“cache:cleanup:list”（缓存清理列表），光看名字就能猜个八九不离十，都是各个业务系统留下的“脚印”。

第二招：分清是排队（List）还是发布订阅（Pub/Sub）

光看名字不行，得知道它们是什么“材质”做的，Redis里能当队列用的结构主要有两种（来源：Redis数据类型）：一种是老老实实排队的List（列表），像超市结账的队伍，一个接一个；另一种是像广播一样的Pub/Sub（发布/订阅），一个消息发出来,所有等着听的人都能收到。

我用 type [键名] 命令（来源：Redis官方文档 TYPE 命令）一个个检查，查了一下“order:waiting:pay”，返回的是“list”，这说明它是个列表队列，订单们正按先来后到的顺序排着队呢，我又检查了一个叫“notify:user:upgrade”（通知：用户升级）的键，结果显示是“channel”，这就是Pub/Sub用的频道，属于那种“广而告之”的类型。

第三招：扒开列表队列，看里面装了啥

对于主要的List队列，我得看看里面具体是些什么“货”，直接用 LRANGE 命令（来源：Redis官方文档 LRANGE 命令）可以把队列里的元素捞出来看看，我试着对“email:task:queue”下手，输入 LRANGE email:task:queue 0 4,意思是看看这个队列里最开始的5个元素是什么。

结果一出来，是几串看起来乱七八糟的JSON字符串，我把它复制出来，在编辑器里格式化了一下，秘密就暴露了，原来每条记录都包含了用户的ID、邮箱地址、邮件模板的编号，还有一些个性化的数据，亲爱的张三，您的订单12345已发货”，这下我明白了，这个队列就是用来异步发送邮件的,避免用户下单后页面一直等着发邮件。

我又用 LLEN 命令（来源：Redis官方文档 LLEN 命令）看了看几个关键队列的长度。“order:waiting:pay”队列居然有上千个元素，而“email:task:queue”才几十个，这说明支付环节可能积压了，而邮件发送服务处理得还挺快,这是个重要的发现！

第四招：发现非主流队列和潜在问题

在盘点过程中，我还发现了一些“异类”，比如有一个键叫“delay:task:scheduler”（延迟任务调度器），它的类型是“zset”，也就是有序集合（来源：Redis数据类型 ZSET），这其实是一种高级队列，叫延迟队列，我用 ZRANGE 命令（来源：Redis官方文档 ZANGE 命令）看了下，每个元素都有一个分数（score），代表的是未来的某个时间戳，系统会定时来取已经到期的任务执行，这通常用于比如“订单30分钟未支付自动关闭”这种场景。

还发现一些键，名字像是队列，tmp:session:list”（临时会话列表），但用 TTL 命令（来源：Redis官方文档 TTL 命令）一看，存活时间（TTL）是-1，意思是永不过期，这可不是个好兆头，万一有bug导致消息只进不出，这个队列会像个无底洞一样吃掉内存，成了“僵尸队列”。

盘点总结：仓库变明堂

一番折腾下来，我对Redis里的队列了如指掌，谁在忙，谁在闲，谁的结构合理，谁可能埋了雷，心里基本有数了，我记下了几个要点：支付队列积压需要排查原因；“僵尸队列”得加上过期时间或者有清理机制；延迟队列的设计很巧妙,可以推广到其他业务。

经过这番“扒窃”，Redis这个老仓库在我眼里不再是黑盒，每个队列都像是一个有故事的工作人员，它们默默地承担着系统的流转，而定期来“盘点”一下，不仅能防患于未然，还能更好地理解整个系统的运行脉络，所谓的秘密和结构，其实就是系统业务逻辑最真实的倒影,就藏在那些看似枯燥的键名和数据格式里。