NapCatQQ 错误处理与容灾机制3 个参数让机器人故障后自己好起来【免费下载链接】NapCatQQModern protocol-side framework based on NTQQ项目地址: https://gitcode.com/gh_mirrors/na/NapCatQQ本文用一次机器人假死的故障讲清 NapCatQQ 错误处理与容灾机制是怎么运转的以及 maxRetries、disableTime、healthCheckInterval 三个参数该怎么配。一次 API 调用失败为什么能拖垮机器人先回忆一个场景深夜群里有人 机器人它内部一次 API 调用失败抛出异常。没有兜底时异常会直接中断事件处理机器人从此假死后续消息全部丢失若故障下游持续报错它还会不断重试、不断失败把时间耗死在这里。问题的本质只有两点关键路径上没有备选方案故障下游没有被隔离。跟着一次失败走完容灾闭环按时间顺序把一次故障经历的流程串起来。第一站是回退。fall-back.ts 里的 Fallback 把多个处理函数按优先级排成一条链运行时逐个尝试谁先返回有效结果就用谁全部失败时抛出携带所有中间错误的 AggregateError方便你定位而不是静默吞掉。第二站是重试与熔断。health.ts 里的 ResourceManager 按名字为每个资源记账失败累计到 maxRetries 次资源就被禁用 disableTime 毫秒禁用期内新的调用立刻得到一条带恢复时间的明确报错而不是傻等——别再往故障下游上撞。第三站是健康检查恢复。禁用到期后下一次调用会触发健康检查用 testArgs 走一遍 resourceFn或调用你提供的 healthCheckFn 做轻量探测。通过则立即恢复、计数清零连续探测失败达到 maxHealthCheckFailures 次代码默认 20资源被永久禁用从根上止血。辅助角色有两个cancel-task.ts 的 CancelableTask 让长任务可被 cancel() 主动中止并挂回调清理避免僵尸任务占资源store.ts 提供带 TTL 的 key-value 存储缓存运行期的关键状态配合持久化数据重启后能快速把现场重建出来。任何一次成功调用都会清零计数与禁用时间所以这是一个失败→熔断→探测→恢复的循环而非单向降级。maxRetries、disableTime、healthCheckInterval 怎么配注册资源时可以这样写{ maxRetries: 3, // 连续失败多少次后熔断默认 3 disableTime: 30000, // 熔断持续毫秒数默认 30 秒 healthCheckInterval: 60000 // 两次健康检查的最小间隔默认 60 秒 }调整思路下游是偶尔抽风的第三方接口maxRetries 提到 5 能多挡一些抖动本地服务保持默认即可。disableTime 要盖住下游的典型恢复时间太短会反复撞墙太长则闪断之后恢复慢。healthCheckInterval 是两次探测的下限下游恢复慢或探测本身昂贵时把它调大更稳妥。成本高的资源建议单独提供一个轻量 healthCheckFn别拿完整调用当探针。怎么确认容灾在生效没生效先查什么排障按这个顺序来看报错文案错误信息里出现 currently disabled until 或 permanently disabled说明熔断已触发容灾在正常工作。看统计getResourceStats 返回 successCount、failureCount 和 isEnabledfailureCount 在涨但机器人照常应答属于预期行为。没生效先查三处调用是否走了 registerResource / callResource裸调 resourceFn 会绕过全部保护资源 type 名字是否前后一致不同名字是两个独立资源、各算各的计数maxRetries 是否设得过大导致熔断几乎不触发。长任务卡顿单独查这类问题与熔断无关确认是否用了 CancelableTask 并在超时后主动 cancel。写在最后容灾的价值不在永不失败而在失败之后机器人能自己定位问题、自己恢复。上线前建议你人为制造一次下游故障完整走一遍熔断→健康检查→恢复的链路确认配置真实生效。️【免费下载链接】NapCatQQModern protocol-side framework based on NTQQ项目地址: https://gitcode.com/gh_mirrors/na/NapCatQQ创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
NapCatQQ 错误处理与容灾机制3 个参数让机器人故障后自己好起来【免费下载链接】NapCatQQModern protocol-side framework based on NTQQ项目地址: https://gitcode.com/gh_mirrors/na/NapCatQQ本文用一次机器人假死的故障讲清 NapCatQQ 错误处理与容灾机制是怎么运转的以及 maxRetries、disableTime、healthCheckInterval 三个参数该怎么配。一次 API 调用失败为什么能拖垮机器人先回忆一个场景深夜群里有人 机器人它内部一次 API 调用失败抛出异常。没有兜底时异常会直接中断事件处理机器人从此假死后续消息全部丢失若故障下游持续报错它还会不断重试、不断失败把时间耗死在这里。问题的本质只有两点关键路径上没有备选方案故障下游没有被隔离。跟着一次失败走完容灾闭环按时间顺序把一次故障经历的流程串起来。第一站是回退。fall-back.ts 里的 Fallback 把多个处理函数按优先级排成一条链运行时逐个尝试谁先返回有效结果就用谁全部失败时抛出携带所有中间错误的 AggregateError方便你定位而不是静默吞掉。第二站是重试与熔断。health.ts 里的 ResourceManager 按名字为每个资源记账失败累计到 maxRetries 次资源就被禁用 disableTime 毫秒禁用期内新的调用立刻得到一条带恢复时间的明确报错而不是傻等——别再往故障下游上撞。第三站是健康检查恢复。禁用到期后下一次调用会触发健康检查用 testArgs 走一遍 resourceFn或调用你提供的 healthCheckFn 做轻量探测。通过则立即恢复、计数清零连续探测失败达到 maxHealthCheckFailures 次代码默认 20资源被永久禁用从根上止血。辅助角色有两个cancel-task.ts 的 CancelableTask 让长任务可被 cancel() 主动中止并挂回调清理避免僵尸任务占资源store.ts 提供带 TTL 的 key-value 存储缓存运行期的关键状态配合持久化数据重启后能快速把现场重建出来。任何一次成功调用都会清零计数与禁用时间所以这是一个失败→熔断→探测→恢复的循环而非单向降级。maxRetries、disableTime、healthCheckInterval 怎么配注册资源时可以这样写{ maxRetries: 3, // 连续失败多少次后熔断默认 3 disableTime: 30000, // 熔断持续毫秒数默认 30 秒 healthCheckInterval: 60000 // 两次健康检查的最小间隔默认 60 秒 }调整思路下游是偶尔抽风的第三方接口maxRetries 提到 5 能多挡一些抖动本地服务保持默认即可。disableTime 要盖住下游的典型恢复时间太短会反复撞墙太长则闪断之后恢复慢。healthCheckInterval 是两次探测的下限下游恢复慢或探测本身昂贵时把它调大更稳妥。成本高的资源建议单独提供一个轻量 healthCheckFn别拿完整调用当探针。怎么确认容灾在生效没生效先查什么排障按这个顺序来看报错文案错误信息里出现 currently disabled until 或 permanently disabled说明熔断已触发容灾在正常工作。看统计getResourceStats 返回 successCount、failureCount 和 isEnabledfailureCount 在涨但机器人照常应答属于预期行为。没生效先查三处调用是否走了 registerResource / callResource裸调 resourceFn 会绕过全部保护资源 type 名字是否前后一致不同名字是两个独立资源、各算各的计数maxRetries 是否设得过大导致熔断几乎不触发。长任务卡顿单独查这类问题与熔断无关确认是否用了 CancelableTask 并在超时后主动 cancel。写在最后容灾的价值不在永不失败而在失败之后机器人能自己定位问题、自己恢复。上线前建议你人为制造一次下游故障完整走一遍熔断→健康检查→恢复的链路确认配置真实生效。️【免费下载链接】NapCatQQModern protocol-side framework based on NTQQ项目地址: https://gitcode.com/gh_mirrors/na/NapCatQQ创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
