确认

一条消息如何确认：处理器返回什么，失败策略如何决定，重试在哪里结束。

以文字阅读本图

1. 一条消息 → 解码 消息内容
2. 解码 消息内容 → 处理器 运行: 已解码
3. 解码 消息内容 → 解码失败： 默认 drop
4. 处理器 运行 → 结果 函数体的返回值: 返回
5. 处理器 运行 → 发生 panic： 默认 fail_fast， 服务停止
6. 解码失败： 默认 drop → 结果 函数体的返回值
7. 发生 panic： 默认 fail_fast， 服务停止 → 结果 函数体的返回值: 其他策略
8. 结果 函数体的返回值 → ack() 已确认
9. 结果 函数体的返回值 → drop() 已拒绝
10. 结果 函数体的返回值 → retry() 立即
11. 结果 函数体的返回值 → retry_after 稍后
12. retry() 立即 → 先检查尝试上限
13. retry_after 稍后 → 先检查尝试上限
14. 先检查尝试上限 → 未到上限： 由 Broker 重投， 或把副本发往 重试地址
15. 先检查尝试上限 → 到达上限： 副本发往死信
16. 先检查尝试上限 → 到达上限， 未声明死信： 直接拒绝
17. 确认之后： 运行 and_after 和钩子

处理器的结果是一个值。Ok 表示确认，错误结果说明如何处置这条消息。普通的 Result<(), E> 出错时，消息会被丢弃，而不是重试。

无法解码的内容和发生 panic 的处理器都交给失败策略。除 fail_fast 之外的策略，处置方式与同名的结果相同；skip 则确认这条消息。fail_fast 停止服务，不确认这条消息，能重新投递的 Broker 会在重启之后把它交回来。

立即重试 retry() 如果既没有声明尝试上限，也没有声明死信地址，就直接交还给 Broker 重新入队。有了声明，自己统计重投次数的 Broker 仍然重新入队，次数由 Broker 记录。Broker 不统计次数时，运行时把一份副本发布到订阅的重试地址，并拒绝原消息。副本在消息头里带着尝试次数。

延迟重试 retry_after 在 Broker 支持延迟重投时使用它。否则运行时在延迟之后发布副本，无论有没有声明。

声明了上限时，两种重试之前都会先检查上限。到达上限时，声明了死信地址的消息会复制到那里，没有声明的则被拒绝。自己转移耗尽次数的消息的 Broker 在启动时收到声明，由它自己执行。

Broker 拒绝确认时，运行时会记录日志，然后继续处理下一条。