Asynq 如何组织异步任务执行、重试与故障恢复，与通用消息队列有何区别？
未标记
考查重点：任务状态与可靠重试。客户端把任务写入 Redis，Worker 取任务执行并按结果确认或重试；崩溃可能导致重复，任务需业务幂等，再比较通用消息队列的消费模型
本题目录
参考答案
核心回答
Asynq 是基于 Redis 的 Go 异步任务框架。客户端提交任务类型、载荷与执行选项，Worker 按类型调用注册的处理器；框架管理等待、执行、延迟调度、重试和归档。它适合文档解析、通知发送等可以脱离当前 HTTP 请求执行的工作。
入队成功只说明任务被接收，业务是否完成还要看处理结果。 处理器返回错误会触发有限重试；进程失联后，过期租约任务也可能被重新执行。因此应按至少一次执行来设计业务幂等，而不能把自动恢复理解为副作用只发生一次。
执行与重试怎样组织
客户端用 NewTask 创建类型和载荷，通过 Enqueue 提交；服务端配置并发数与队列，由 ServeMux 分派到处理器。延迟任务先处于 Scheduled，到期进入 Pending，被领取后进入 Active。
处理器成功返回后，默认删除任务数据；配置 Retention 才会保留为 Completed。返回错误或发生可处理的 panic 后，任务按重试策略等待下一次执行，超过 MaxRetry 后进入 Archived。MaxRetry 表示首次执行之后允许的重试次数；不可恢复错误可使用 SkipRetry 跳过后续重试。任务生命周期、重试选项。
重试需要同时限制次数、等待间隔、执行超时与业务总预算。临时连接失败适合退避重试，权限或配置错误通常需要先修正条件。处理器及下游调用也要响应取消，设置超时不意味着框架能撤销已经发生的外部写入。
Worker 崩溃后能恢复什么
以 v0.26.0 为例，恢复器检查租约过期的任务，根据已经重试的次数重新安排执行或归档。它恢复的是任务调度，不是从崩溃的 Go 函数中间继续运行。恢复器实现。
例如索引写入已成功，但 Worker 在确认任务前退出，下一次可能再次写索引。应让同一逻辑操作使用稳定业务键，以唯一约束、幂等更新或下游幂等接口处理重复；遇到结果未知的外部操作，先查询、对账，再决定是否重做。任务去重选项不能代替业务副作用边界上的幂等，Redis 的持久化、故障转移配置也仍然影响可靠性。
与通用消息队列有什么区别
Asynq 把“执行某个任务”的客户端、Worker、定时、重试和管理能力组合起来。通用消息中间件更多提供消息传输与消费协议，具体产品还可能支持广播订阅、分区日志或回放；也可以在其上实现任务系统。
因此要按消费关系、回放需求、调度能力和运维条件选型，不能简单说通用 MQ 都保证顺序，或 Asynq 天然吞吐更高。无论使用哪一种，都要处理生产失败、重复消费和业务状态与消息确认之间的衔接。
WeKnoraGo
基于 WeKnora核心回答
在采用 Redis/Asynq 的部署中，WeKnora 将文档上传与耗时的解析、切分、索引分开执行，再通过图片处理和后处理任务推进文档状态。任务队列负责调度与重试，数据库中的文档记录负责展示业务进度；上传成功、Worker 返回成功、文档最终可用是不同层面的结论。
文件上传后任务怎样执行？
上传服务先保存文件和 pending 文档记录，再把租户、知识库、文档与文件路径放入 DocumentProcessPayload。Worker 的 ServeMux 将文档任务交给 ProcessDocument，图片任务和后处理任务交给各自处理器，并由不同阶段的队列与并发池消费。上传与入队、处理器注册。
文档解析、切分和索引后，有图片则分派图片处理任务，之后衔接后处理；没有图片也有直接进入后处理的路径。文档与后处理选项均设置 MaxRetry(3)，即首次失败后最多再重试三次，并设置执行超时。任务选项。
失败后一定会重试吗？
不会。Asynq 根据处理器返回值判断失败，不会自行理解数据库中的 failed：
- 可重试的解析或索引错误返回
error，交给框架安排重试；已有完成记录、失效尝试等则按具体条件跳过。 - 获取知识库失败的一条路径会把文档标成
failed后返回nil；没有配置可用解析器时，也有记录失败后返回空结果的路径。这些业务失败不会因为状态名是failed就自动触发框架重试。知识库读取失败、解析器未配置。
处理器错误经现有中间件耗尽重试时，中间件记录死信，并尽力将适用的文档状态更新为失败，避免页面一直等待；回调还检查任务所属尝试，避免旧失败覆盖新处理。租约过期的恢复器可以直接归档任务，不经过这层处理器中间件；状态回写本身也可能失败。因此排查时要同时检查队列记录、文档状态与具体阶段错误，必要时由后续状态巡检纠偏。最终失败回写。
怎样判断整份文档处理结束？
有需要等待的增强子任务时，后处理阶段登记子任务数，将文档置于 finalizing；没有这类子任务时则直接完成。子任务到达可结算的终态后释放计数。数据库在同一事务内递减 pending_subtasks_count，并在计数归零且状态仍满足条件时推进文档状态。后处理登记、事务内归并。
这里的归零表示规定的任务槽已经结算，部分最终失败也会释放槽；它不证明每一次可选的识别、摘要或增强调用都成功。检索可用性和可选增强结果需要分别观察。终态释放条件。
当前实现还有什么可靠性边界？
文件与文档记录保存后才入队，两者并不是一个数据库与 Redis 的原子事务。该版本入队失败时可以标记文档失败但仍返回 knowledge, nil，因为文件已经保存。因此调用方不能仅以 HTTP 成功判断任务已经开始。若要进一步完善，可以引入事务内待发送记录与补投扫描，并按业务键防重复；这是后续设计建议。
此外，未配置 REDIS_ADDR 时走 Lite 执行器。虽然名为 SyncTaskExecutor，其 Enqueue 会启动进程内 goroutine，也有重试和最终失败回调，但没有 Redis 持久任务队列，不能承诺进程退出后任务仍会恢复。部署分支、Lite 执行器。
对应教程
- 第 25 章：LangGraph 高级特性：参考重复执行与副作用幂等的边界；
Asynq的调度与恢复机制另按上述资料说明。
参考资料
- 国内：JavaGuide：消息队列：采用异步接收与业务完成分开的解释，比较消息传输与任务执行的职责。
- 国内：JavaGuide：超时与重试：采用有限重试、退避、错误分类与写操作幂等的设计原则。
- 国内：JavaGuide：状态机与工作流：采用任务状态与业务实例分开、并行分支汇聚及状态与投递衔接的解释；不将建议的 Outbox 写成项目已有实现。
- 国内：zero2Agent：Agent Infra：采用执行成功但确认失败时按稳定业务键去重、查询未知结果的处理思路。
- 国外：Asynq：Life of a Task：采用等待、执行、重试、归档与可选成功保留的生命周期定义。
- 国外：Asynq：Task Retry：采用
MaxRetry、可配置退避和SkipRetry的语义。
