审核系统项目深挖

机制训练文档 · 项目卡片 · 指标取证

事实与链路

• 盘点审核对象、调用方、角色、日任务量/峰值、人工队列 SLA、P95/P99、本人负责模块及结果来源。未知数字标记待核实。
• 主链路：提交 → 创建任务 → 机审 → 人审 → 复审/申诉 → 通知；记录撤回、失败、超时和终态的处理规则。
• 项目表达：业务目标 → 本人职责 → 一条主链路 → 一个难点和取舍 → 结果证据。深入追问再展开容量、审计和恢复。

决策与失败边界

问题	核对实现与取舍
重复任务	唯一键如 (biz_type,biz_id,biz_version)；直接插入、冲突后返回已有任务。先查后插和 Redis 锁不能代替数据库约束
非法转换	集中维护 (from,event)→to 转换表；更新附带预期状态与版本，影响 0 行按重复或冲突处理
多人领取	UPDATE ... SET assignee=? WHERE id=? AND assignee IS NULL，确认影响行数
机审晚到	转人工后机审结果只留痕；回调只更新预期机审状态。人工/复审裁决优先级由业务约定
结论成功、通知失败	状态和 Outbox 同一事务；投递失败退避重试，超过预算进入待处理队列；下游按事件 ID 或任务版本幂等
规则升级	明确按创建时还是执行时版本；记录规则/模型版本和命中明细；变更灰度，历史复审新增记录
积压	看任务到达率、处理率、最老任务年龄及环节耗时。机审受下游容量约束，人审受人力约束；净处理率为正才估算追平时间
方案演进	比较枚举/转换表与工作流引擎的定制、学习和运维成本；按实际技术债排序

-- 教学示例：业务转换校验与数据库条件更新缺一不可
UPDATE audit_task
SET status = ?, version = version + 1
WHERE id = ? AND status = ? AND version = ?;

教学状态图，需按真实项目修订：

CREATED → MACHINE_REVIEWING → FINISHED
                 ↓ 存疑/超时
           MANUAL_PENDING → MANUAL_REVIEWING → FINISHED
                                                ↓ 申诉/抽检
                                           RECHECKING → FINISHED
允许撤回的非终态 → CANCELED

练习

闭卷画状态图，解释重复提交、机审晚到、通知失败、规则升级四种场景；再准备一份优化或故障案例。每项结论注明真实实现、本人贡献或设计建议。