因为php cli进程throw未捕获异常会直接退出，导致队列消费中断；必须用try/catch显式捕获、记录结构化日志、跳过当前任务并继续处理下一条，redis本身无自动重试或死信机制，所有容错逻辑需手动实现。
为什么不能直接在 Redis 队列消费者里 throw Exception
PHP 的 CLI 进程（比如 php worker.php）里一旦 throw 未捕获异常，整个进程就退出，队列消费中断，后续任务全卡住。你想要的不是崩溃，而是记录错误、跳过当前任务、继续处理下一条——这得靠显式错误捕获 + 自定义日志写入逻辑，而不是依赖 PHP 默认异常终止行为。
Redis 队列本身不提供错误重试或死信机制，所有容错逻辑必须由你手写。
- 消费者必须用
try/catch包裹每条任务的执行体 - 错误日志不能只写
error_log()或var_dump()，要结构化（含时间、任务 ID、原始数据、堆栈） - 别把敏感字段（如用户 token、密码）直接塞进日志字符串
怎么用 Redis List 做队列并安全消费带错误日志的任务
推荐用 LPUSH 入队、BRPOP 阻塞出队，避免轮询浪费 CPU。每条任务建议是 JSON 字符串，含 job_id、type、payload 和可选 attempts 计数。
示例消费者片段：
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
<?php $redis = new Redis();
$redis->connect('127.0.0.1', 6379);
while (true) {
$res = $redis->brPop(['my_queue'], 5); // 阻塞 5 秒
if (!$res) continue;
$taskJson = $res[1];
$task = json_decode($taskJson, true);
try {
handleTask($task);
} catch (Exception $e) {
logCustomError($task, $e);
// 可选：失败超 3 次则推到 error_queue 归档
if (($task['attempts'] ?? 0) lPush('my_queue', json_encode($task));
} else {
$redis->lPush('error_queue', json_encode([
'task' => $task,
'error' => $e->getMessage(),
'trace' => $e->getTraceAsString(),
'time' => date('c')
]));
}
}
}
logCustomError() 怎么设计才方便排查和收敛
不要用 file_put_contents() 直接追加文本——并发高时容易日志错乱、没原子性、难 grep。更稳妥的是：用 Redis 的 LPUSH 推到专用日志队列，再由独立日志落盘进程统一处理；或者用 Monolog + RotatingFileHandler，但注意设置 lock_level 防止多进程写冲突。
- 日志内容必须包含：
job_id（便于关联原始任务）、task_type、error_code（如VALIDATION_FAILED）、raw_payload_snippet（截取前 200 字符） - 避免在日志中调用
json_encode($e)—— Exception 对象不可序列化，会报Serialization of 'Exception' is not allowed - 如果用 Monolog，handler 的
filename路径别写相对路径，用__DIR__ . '/logs/error.log'显式指定
Redis 连接断开或任务执行超时怎么办
CLI 消费者长期运行，网络抖动或 Redis 重启会导致 $redis->connect() 失效，但连接对象不会自动重连。每次操作前必须检查 $redis->isConnected()，断开就重建连接；同时给关键操作加超时控制（比如 set_time_limit(30)），防止单个任务拖垮整条流水线。
-
BRPOP的 timeout 参数设为 5～30 秒，太短增加无效轮询，太长导致故障响应延迟 - 用
set_error_handler()捕获致命错误（如Fatal error: Allowed memory size exhausted），记录后exit(1)触发进程重启（靠 supervisor 管理） - 别在消费者里做耗时 IO（如远程 HTTP 请求），应拆成两阶段：先入队，再由专用 worker 执行并回写结果
真正麻烦的是任务幂等性——比如日志已写、但业务状态没更新，重启后重复消费又写一遍日志。这得靠任务 ID 去重或数据库唯一索引兜底，不是单靠日志模块能解决的。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
