测验：批处理重试与重复执行的影响

完成数：1 作业已完成，并且账本中有两次相同订单的交货。最准确的解释是什么？

• 执行完成条件和要处理的外部任务数量必须单独检查。
• 由于“完整”条件保证一次交货，因此必须将其从分类帐计数中排除。
• 如果只有一个成功的Pod，则失败的Pod的请求也会被外部取消。
• 如果并行度设置为1，则不会出现相同顺序的重复存储。

restartPolicy：Never，同一个Job拥有的Pod A失败，Pod B成功，两个容器的restartCount都是0。观察有什么区别？

• 即使容器在同一个 Pod 内重新启动，restartCount 也不会改变
• 作业控制器可以创建替换 Pod，而无需重新启动 Pod 内部
• 由于有 Never 设置，因此两个 Pod 必须属于不同的 Job。
• 由于新的 Pod 已经创建，因此没有来自失败的 Pod 的外部请求。

BackoffLimit: 0 作业保存后立即失败，仅剩一份复合交付。在重新运行新作业之前，操作员应该做什么？

• 由于这是一个失败的作业，我们假设没有副作用，并使用新的任务密钥再次运行它。
• 如果您将重试限制更改为更大的值，请等待查看现有货件是否会自动取消。
• 使用稳定的业务密钥检查现有处理结果并申请重新执行合约
• 删除失败的Pod也会初始化账本，所以先删除Pod。

当对同一业务密钥的两个请求同时到达时，确保合成账本仅进行一次交付的核心合约是什么？

• 两个客户端均创建一个新的 UUID 并跳过重复查找。
• 将处理完成情况写入每个Pod的内存中，不查看其他Pod的状态。
• 划分查找和插入后，如果确定都不存在，则分别添加一行。
• 使用唯一的业务密钥和一个写入事务处理查询和插入。

即使使用不同名称的作业重新执行相同的任务，也应该维护哪些值以避免创建重复交付？

• 识别工作和订单逻辑范围的可靠密钥
• 创建新作业时 API 服务器给出的唯一 UID。
• 在每个运行进程开始时创建的新随机密钥。
• 发送请求的 Pod 的新名称和容器启动时间。

在安全模式下，在作业重试和单独的作业重新执行之间，存在 3 个请求和 1 个交付。应该保存哪些观察数据？

• 由于只有一次交付，因此只留下第一个请求，并删除重复的请求历史记录。
• 所有这三个都留下一个连接，该连接指向与请求的执行标识符相同的运输编号。
• 只保留最终作业的完整条件，并排除账本和失败的 Pod
• 补充第二个交付行，使请求数等于交付数

作业超过了 activeDeadlineSeconds，并因 DeadlineExceeded 而失败。该程序在终止前保存了发货。哪个结论是正确的？

• 当时间限制到期时，作业的外部保存也会同时取消。
• 如果 backoffLimit 仍然存在，即使超时后也会继续重试
• 由于执行完成和任务取消是不同的，所以需要分别检查剩余的下发结果。
• 由于存在“失败”条件，因此分类账中剩余的交付不能算作成功。

我在 CronJob 中指定了 concurrencyPolicy: Forbid 。幂等处理的正确描述是什么？

• 防止处理同一订单的所有手动作业相互重叠。
• 由其他 CronJobs 启动的相同任务会自动合并为一次执行。
• 发生故障后，CronJob 会自动删除存储在外部账本中的重复结果。
• 限制同一 CronJob 的执行重叠和重叠工作处理合约是分开的。