Redis Stream 消息不再推进:从 Pending 积压到故障消费者安全接管
适用场景 本文适用于使用 Redis Stream 消费组承载异步任务、事件通知或轻量消息队列的系统。典型架构是生产者通过 XADD 写入 Stream,多个消费者用 XREADGROUP 拉取消息,业务成功后再执行 XACK。 当某个消费者在处理期间崩溃、被强制重启或网络中断时,已经投递但尚未确认的消息不会重新出现在
Tag
包含这个标签的文章。
适用场景 本文适用于使用 Redis Stream 消费组承载异步任务、事件通知或轻量消息队列的系统。典型架构是生产者通过 XADD 写入 Stream,多个消费者用 XREADGROUP 拉取消息,业务成功后再执行 XACK。 当某个消费者在处理期间崩溃、被强制重启或网络中断时,已经投递但尚未确认的消息不会重新出现在
适用场景 代码仓库、CI 日志、工单截图或聊天记录中出现了生产 API 密钥。密钥仍在被多个服务使用,直接禁用可能造成业务中断,但继续保留又会扩大攻击窗口。 本文面向服务到服务调用的静态 API 密钥,给出一套可执行的处置流程:先确认影响范围并限制风险,再创建权限更小的新密钥,通过短暂的双密钥窗口迁移调用方,验证新密钥
适用场景 本文适用于 Node.js 20.3 及以上版本使用原生 fetch 调用内部 API、第三方服务或网关的 TypeScript 项目。示例使用该版本提供的 AbortSignal.any();更早版本可以用等价的信号组合函数替代。典型现象是:业务层已经返回“请求超时”,但下游仍持续收到请求;并发升高后连接数
适用场景 FastAPI、Django ASGI 或自研 asyncio 服务会在同一线程交错处理多个请求。团队希望所有日志自动带上 request_id,却发现并发压测时标识偶尔串到另一个请求,或请求结束后启动的后台任务仍携带旧用户上下文。 本文用 Python 标准库复现并修复这个问题。重点不是某个 Web 框架的
适用场景 本文适用于 Prometheus 根据错误率、延迟、资源使用率等指标触发告警,并通过 Alertmanager 发送通知的场景。典型问题是:指标在阈值附近波动,告警几分钟内反复触发和恢复;短暂采集缺口被误判为恢复;值班人员收到大量重复通知,却难以判断故障是否真正结束。 目标不是简单地“把告警调迟”,而是分别处
适用场景 集群管理员准备升级内核、更换节点或缩容节点池,执行 kubectl drain 后命令长时间重试,并反复出现 Cannot evict pod as it would violate the pod's disruption budget。业务当前未必已经中断,但维护窗口正在被耗尽。 本文适用于由 Deplo
适用场景 生产环境执行 python manage.py migrate 后长时间没有结束,应用发布流水线被阻塞;或者迁移最终报出 Lock wait timeout exceeded、OperationalError。这类问题常见于 Django + MySQL/InnoDB:迁移本身很短,却在等待另一条业务 SQL
适用场景 Python 服务或批处理脚本通过 httpx 调用第三方 HTTP API。流量上来后,应用日志开始出现 httpx.PoolTimeout,但目标接口的监控显示延迟正常;重启服务后短暂恢复,随后问题又出现。常见于 FastAPI/Django 的异步任务、数据同步程序和并发爬取工具。 本文以 httpx.
适用场景 使用 Celery + Redis/RabbitMQ 承担异步任务。队列中仍有大量待执行任务,但监控显示少数 Worker 忙碌、其余 Worker 空闲;或者短任务被长任务“压住”,整体延迟持续升高。本文以默认的 prefork 并发池和 RabbitMQ 为例,Redis broker 的排查思路相同。
适用场景 Linux 服务器上的 Java、Python、Go 或 Node.js 服务由 systemd 托管。发布后或依赖异常时,进程在几秒内连续退出;即使问题随后已修复,执行 systemctl restart 仍失败,状态显示为 failed,日志里出现 Start request repeated too q