Resque Worker容器健康检查：存活与就绪探针配置
项目地址: https://gitcode.com/gh_mirrors/re/resque 你是否遇到过Resque Worker假死导致任务堆积？容器化部署时如何确保Worker真实可用？本文将详解基于Redis状态和进程信号的健康检查方案，通过存活探针(Liveness Probe)和就绪探针(Readiness Probe)保障Worker集群稳定性。
健康检查核心指标
Resque Worker的健康状态可通过以下维度判断：
- 进程活性：Worker主进程是否存活
- 心跳状态：Redis中worker heartbeat是否更新（默认每5秒）
- 任务处理能力：是否能正常从队列获取并执行任务
- 资源消耗：内存使用是否超出阈值（参考examples/monit/resque.monit中300MB限制）
存活探针实现方案
存活探针用于检测并重启无响应的Worker进程，推荐两种实现方式：
1. Redis心跳检查（推荐）
Resque Worker每5秒自动更新Redis心跳（lib/resque/worker.rb#L527-L536），可通过以下脚本检查：
#!/bin/bash
# 存活探针脚本: check_liveness.sh
WORKER_ID=$1
HEARTBEAT_TTL=15 # 允许3个心跳周期的延迟
LAST_HEARTBEAT=$(redis-cli GET "worker:$WORKER_ID:heartbeat" 2>/dev/null)
if [ -z "$LAST_HEARTBEAT" ]; then
exit 1 # 无心跳记录
fi
NOW=$(date +%s)
HEARTBEAT_TIME=$(date -d "$LAST_HEARTBEAT" +%s 2>/dev/null || echo 0)
if [ $((NOW - HEARTBEAT_TIME)) -gt $HEARTBEAT_TTL ]; then
exit 1 # 心跳过期
else
exit 0 # 存活正常
fi
2. 进程PID检查
通过监控PID文件判断进程状态，结合Monit配置思路（examples/monit/resque.monit）：
#!/bin/bash
# 进程检查脚本: check_pid.sh
PID_FILE="/data/app/tmp/pids/resque_worker.pid"
if [ ! -f "$PID_FILE" ]; then
exit 1
fi
PID=$(cat "$PID_FILE")
if ps -p $PID > /dev/null; then
exit 0
else
exit 1
fi
就绪探针实现方案
就绪探针确保Worker准备好接收任务，需验证队列处理能力：
#!/bin/bash
# 就绪探针脚本: check_readiness.sh
WORKER_ID=$1
QUEUE_NAME=$2
# 检查Worker是否处于idle或working状态
WORKER_STATE=$(redis-cli HGET "resque:worker:$WORKER_ID" "state" 2>/dev/null)
if [ "$WORKER_STATE" != "idle" ] && [ "$WORKER_STATE" != "working" ]; then
exit 1
fi
# 检查是否能从目标队列获取任务
QUEUE_SIZE=$(redis-cli LLEN "resque:queue:$QUEUE_NAME" 2>/dev/null)
if [ "$QUEUE_SIZE" -lt 0 ]; then
exit 1 # 队列不存在
fi
exit 0
Kubernetes探针配置示例
将上述脚本集成到Kubernetes部署中：
apiVersion: apps/v1
kind: Deployment
metadata:
name: resque-worker
spec:
replicas: 3
template:
spec:
containers:
- name: worker
image: resque-worker:latest
command: ["bundle", "exec", "resque:work"]
args: ["QUEUE=*", "VERBOSE=1"]
livenessProbe:
exec:
command: ["/app/check_liveness.sh", "$(WORKER_ID)"]
initialDelaySeconds: 30 # 首次检查延迟
periodSeconds: 10 # 检查间隔
failureThreshold: 3 # 3次失败后重启
readinessProbe:
exec:
command: ["/app/check_readiness.sh", "$(WORKER_ID)", "critical_queue"]
initialDelaySeconds: 10
periodSeconds: 5
env:
- name: WORKER_ID
valueFrom:
fieldRef:
fieldPath: metadata.name
进阶优化策略
1. 动态阈值调整
根据任务类型调整资源阈值，如图片处理Worker可提高内存限制：
# 在monit配置中差异化设置（参考[examples/monit/resque.monit](https://link.gitcode.com/i/14b5171d4ef97dee5bb16920be0b1cbd)）
if totalmem is greater than 500 MB for 10 cycles then restart
2. 多探针组合
结合TCP端口检查Resque Web控制台（lib/resque/server.rb）：
readinessProbe:
httpGet:
path: /workers
port: 5678
initialDelaySeconds: 15
3. 异常恢复钩子
利用Resque的worker_exit钩子（lib/resque/worker.rb#L259）实现故障自愈：
Resque.after_fork do |job|
# 注册异常退出处理逻辑
at_exit { Resque::Stat.incr("worker:restarts") }
end
最佳实践总结
-
探针配置原则：
- 存活探针周期 < 心跳周期（建议10秒）
- 就绪探针失败阈值 > 1（允许短暂队列阻塞）
-
监控结合：
- 配合Prometheus抓取Redis中的worker指标
- 关注
processed和failed统计（lib/resque/stat.rb）
-
部署检查清单：
- ✅ 验证PID文件生成路径
- ✅ 测试Redis网络连通性
- ✅ 模拟OOM场景验证自动恢复
通过以上配置，可有效解决Worker假死、资源泄漏等问题，确保Resque集群在容器环境下的高可用性。实际部署时建议先在测试环境验证探针脚本，逐步调整阈值以适应业务负载。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
