03-保洁业务核心链路

在 AIOT 平台中，保洁业务的核心是基于智能工牌（BADGE）和工单队列（OrderQueue）的硬件级调度系统。

保洁业务深度依赖 02-工单队列系统.md 提供的公共基础设施。

一、硬件联动：智能工牌（BADGE）

保洁业务与智能工牌深度绑定，实现"人到现场才能作业"的强约束：

入队即推送：工单入队后，系统通过 OrderQueueService.enqueue 将指令推送到保洁员的智能工牌（deviceId）
按键确认：保洁员在工牌上按键确认后，队列状态从 WAITING 变为 PROCESSING，同时工单状态变为 CONFIRMED
信标打卡：保洁员到达现场，工牌感应信标后，工单状态变为 ARRIVED
离线检测：如果工牌离线（CleanerStatusEnum.OFFLINE），当前任务自动暂停（PROCESSING -> PAUSED）

二、保洁特有的队列使用方式

1. 并发抢单控制

由于突发工单是广播的，抢单时的并发控制是红线：

移动端发起抢单请求
后端拦截，尝试获取 Redis 锁 ops:ticket:grab:lock:{ticketId}
锁获取成功后，校验工单当前状态是否仍为 PENDING_DISPATCH
并发数限制校验：检查该保洁员当前处于 IN_PROGRESS 状态的工单是否超过配置上限（如最多只能同时进行 3 单任务）
校验通过，写入接单人信息，状态扭转为 IN_PROGRESS，释放锁

2. 执行反馈标准动作（防篡改）

保洁人员在现场执行完毕点击"完工"时，必须包含以下标准化材料的强制校验：

LBS 定位打卡校验

点击完工时，必须随接口上报当前 GPS/WIFI 定位坐标
后端计算该坐标与工单要求点位的距离，超过设定阈值（如 100 米）则拒绝完工

清理前后对比照（核心证据）

必须强制上传至少两张照片：【清理前】与【清理后】
防篡改机制：
- 照片上传在移动端层面必须限制"只能当场拍照"，禁止从相册挑选
- 后端接收图片后，规划接入服务端统一打上不可逆的时间戳与定位水印

耗材扣减（一致性难点）

如果保洁使用了特殊耗材（如两瓶清洁剂），在完工时需同步勾选消耗量
后端在处理 COMPLETED 状态跃迁时，需开启数据库事务，同步扣减库存域（Inventory）的数量
若库存不足或发生死锁，工单完工事务必须一并回滚

三、队列与工单的完整流转示例

1. 规则引擎生成保洁工单 -> 工单状态: PENDING
2. 调度引擎分配保洁员 -> 工单状态: QUEUED, 队列状态: WAITING
3. 推送至智能工牌 -> 工单状态: DISPATCHED
4. 保洁员按键确认 -> 工单状态: CONFIRMED, 队列状态: PROCESSING
5. 到达现场信标打卡 -> 工单状态: ARRIVED
6. 作业完成 -> 工单状态: COMPLETED, 队列状态: REMOVED
7. 系统自动检查该保洁员队列 -> 如有 WAITING 任务，继续推送

四、保洁特有的状态流转

保洁业务在标准工单状态机基础上，增加了 QUEUED（排队中）状态：

stateDiagram-v2
    [*] --> PENDING : 生成工单
    PENDING --> QUEUED : 进入派单队列
    QUEUED --> DISPATCHED : 推送到工牌
    DISPATCHED --> CONFIRMED : 按键确认
    CONFIRMED --> ARRIVED : 信标感应
    ARRIVED --> COMPLETED : 作业完成
    COMPLETED --> [*]

QUEUED：工单已进入 OrderQueue，等待按 queueScore 排序后分配
DISPATCHED：指令已推送到智能工牌，等待保洁员响应

3.5 KiB Raw Blame History Unescape Escape