用Redis搭建监控队列的那些事儿，聊聊实践中遇到的坑和经验

主要参考了个人项目实践、团队技术分享以及《Redis实战》等资料中的相关思路，结合常见运维场景进行总结。）

用Redis做监控队列,听起来挺简单的对吧？就是把监控 agent 采集到的数据往 Redis 的 list 里一扔，然后消费端再从这个 list 里取出来处理，我们最开始也是这么想的，觉得用个 lpush 和 brpop 就搞定了一个高性能队列，但真用起来才发现，坑是一个接一个。

第一个大坑：消息丢失，防不胜防

我们一开始用的就是最简单的 LPUSH（生产消息） 和 BRPOP（阻塞消费消息） 组合，BRPOP 确实好用，没消息就等着，有消息就弹出来，但问题就出在“弹出来”这个动作上，消息一旦被 BRPOP 弹出，就从 Redis 里彻底删除了，如果我们的消费端 worker 进程在拿到消息后、还没处理完业务逻辑的时候，突然崩溃了，这条消息就彻底丢了，监控数据啊，丢一条可能就意味着某个服务器宕机了你不知道，这可是大事。

解决办法： 后来我们换成了 BRPOPLPUSH 命令（或者用新版本的 RPOPLPUSH 替代方案），这个命令很巧妙，它从一个 list 弹出消息的同时，会把这个消息塞进另一个“备份 list”，消费端 worker 从主队列取消息，处理完成后，再自己手动去备份 list 里把这条消息删除，这样，即使 worker 中途挂掉，消息也还在备份 list 里躺着，我们可以启动一个补偿进程，把这些没被确认的消息重新放回主队列让其他 worker 重试，这就实现了“至少一次消费”的保证，虽然可能重复，但绝不会丢。

第二个坑：队列堆积，内存告警

监控数据量一大,特别是业务高峰期或者某个服务出问题狂报错的时候，消息生产速度远远大于消费速度，Redis 是内存数据库，队列消息全放在内存里，眼看着 Redis 的内存使用率蹭蹭往上涨，很快就触发告警了，搞得运维同事天天紧张兮兮的。

解决办法： 我们做了几件事，第一，精简消息体，采集的原始数据可能很臃肿，我们在 agent 端就做一次预处理，只提取关键字段，用更短的键名，甚至做简单的压缩，尽量让一条消息的体积变小，第二，设立多级队列，不是所有监控数据都需要实时处理，我们把告警级别最高的数据（P0 级故障）放进一个“快队列”，消费速度快；把一些用于后期分析的趋势数据、日志数据放进一个“慢队列”，消费慢一点也没关系，这样快队列不容易堆积，避免了关键告警被延迟，第三，设置队列最大长度，用 Redis 的 LTRIM 命令，或者在生产端判断 LLEN 长度，当队列超过一定数量时，果断丢弃最旧的消息（监控数据有时效性，太旧的数据丢了也比拖垮整个系统好），或者转移到更廉价的存储（比如写入文件）。

第三个坑：消费者挂了，消息卡死

用了 BRPOPLPUSH 后，消息安全了，但新问题来了：如果某个消费者 worker 因为代码 bug 卡死了（进程没挂，但就是不处理消息也不报错），那么它从备份 list 里“认领”的那条消息就永远得不到确认，会一直占着位置，导致后续消息堆积。

解决办法： 我们给每条消息引入了一个“超时机制”，简单说，就是在把消息放入备份队列时，同时记录一个对应的超时时间戳（比如当前时间+5分钟），我们启动一个定时扫描的“守护进程”，每隔一段时间就去检查备份队列里的消息，如果发现某条消息的超时时间已经到了，就认为处理它的 worker 已经“失联”了，守护进程会把这条消息重新塞回主队列，让其他健康的 worker 去处理，这就像给每个任务加了一个看门狗。

第四个坑：监控队列本身的监控

用 Redis 做队列，你还得监控这个队列本身是否健康，队列长度是不是突然暴涨？消费者数量是不是减少了？消息的平均处理时间是不是变长了？这些指标如果不监控，等出问题了才发现就晚了。

解决办法： 我们通过 Redis 自带的 INFO 命令定期采集一些关键指标，list 的长度（LLEN）、Redis 的内存使用量、连接数等，然后把这些指标也纳入我们的监控系统（ ironic，对吧？用监控系统监控监控队列），一旦发现队列长度连续增长，或者长时间没有消费者活动，就立刻告警。

总结一下经验：

直接用 Redis 的 list 做简单队列可以，但用于严肃的监控场景，一定要考虑好消息可靠性（防丢失）、系统抗压性（防堆积）、故障恢复（防卡死）和自监控，这些坑我们都踩过，解决办法也不复杂，核心思想就是“冗余+超时+降级”，Redis 性能是好，但它不是万能的银弹，设计架构的时候多想想极端情况，才能让监控系统真的可靠起来。