多端协同系统中共享资源分配的状态一致性设计

沙糖桔45

321人浏览 · 2026-05-28 17:03:06

沙糖桔45 · 2026-05-28 17:03:06 发布

在一些复杂的业务系统里，同一份资源并不总是只服务于一个任务。它可能先被任务 A 占用，又在满足条件时被任务 B 临时复用；任务 A 结束后，这份资源还可能继续流转给任务 C，或者回到待处理池。

这个场景看起来只是“多加几个字段”的问题，但真正落到系统实现里，会同时影响后端分配逻辑、Web 管理端展示、PDA/移动端现场操作以及资源回收流程。如果没有统一的状态模型，最容易出现的问题是：后端已经做了复用判断，前端仍按普通资源展示；移动端提交时少传了下一个任务，后端不知道资源该流向哪里；回收时只按普通资源处理，导致部分设备状态或资源状态没有被正确释放。

[外链图片转存中…(img-4sHJkGyJ-1779958910322)]

本文用一个脱敏后的抽象案例，聊聊这类“共享资源分配”在多端协同系统中的设计思路。

背景：一个抽象案例

假设系统中有三类角色：

后端服务：负责资源分配、状态流转、回收和一致性校验。
Web 管理端：负责展示任务明细、标记异常状态、提供重新分配入口。
PDA/移动端：负责现场绑定、确认、扫码、回收等高频操作。

资源默认属于某一个任务，但在特定条件下可以被另一个任务临时使用。为了让系统知道“这份资源当前是正常分配，还是跨任务复用”，需要引入几个抽象概念：

shared: 当前记录是否属于共享资源。
ownerTaskId: 资源原始归属任务。
currentTaskId: 资源当前服务任务。
nextTaskId: 当前任务结束后，资源要继续流向的下一个任务。
sharedGroupId: 多个任务围绕同一份资源形成的协作组。

问题的关键不是字段本身，而是这些字段在不同端之间如何保持一致。

问题拆解

这类需求通常会暴露出四个技术问题。

第一，资源分配不是单点动作，而是生命周期动作。
如果只在“首次分配”时处理共享，后续的补充、回收、结束、转交都会变成例外分支。例外分支越多，状态越容易漂移。

第二，前端展示不能只显示“成功/失败”。
共享资源和普通资源的风险不同。Web 端需要把“资源来自哪里、为什么被复用、是否需要重新分配”表达清楚；移动端则需要把“是否必须选择下一任务”放在提交前，而不是提交失败后才让用户猜。

第三，后端必须做最终校验。
移动端可以做前置判断，但不能相信移动端一定传了正确参数。只要涉及资源归属、状态流转、重复提交，就必须以后端校验为准。

第四，回收动作要能按粒度处理。
有些时候不能简单地“一键释放全部资源”，而是要支持按执行位置、按资源标识或按任务关系做局部释放。否则现场操作会被迫绕路，系统状态也更难恢复。

方案设计

可以把整个链路拆成三层：数据模型、服务编排、多端交互。

后端：用状态模型约束资源流转

后端不要只保存“资源属于哪个任务”，而要能表达“资源为什么属于这个任务”。普通占用和共享占用在业务上是两种状态，在技术上也应该拆开。

一个简化后的实体可以这样设计：

public class ResourceAllocation {
    private Long id;
    private Long resourceId;
    private Long currentTaskId;
    private Long ownerTaskId;
    private Long sharedGroupId;
    private Boolean shared;
    private AllocationStatus status;
}

当系统自动分配资源时，不建议只做一次简单查询：

Resource resource = resourceRepository.findFirstAvailable(resourceCode);

更稳妥的做法是把“普通可用资源”和“可共享资源”分成两个候选集，再按优先级合并：

List<Resource> normalCandidates = resourceRepository.findAvailable(resourceCode);
List<Resource> sharedCandidates = resourceRepository.findShareable(resourceCode, currentTaskId);

List<AllocationPlan> plans = allocationPlanner.plan(
    currentTaskId,
    requiredQuantity,
    normalCandidates,
    sharedCandidates
);

这样服务层能明确知道每一条分配记录的来源，而不是事后再从状态里反推。

Web 端：把隐性冲突变成可见信息

Web 管理端的价值不是重复后端逻辑，而是把复杂状态翻译成用户能理解的界面信息。

比如任务明细表里，普通资源和共享资源不能只靠同一个“正常”标签展示。可以把展示状态做成一个独立映射：

const allocationStatusView = {
  NORMAL: { label: '正常分配', type: 'success' },
  SHARED: { label: '共享占用', type: 'warning' },
  MISSING: { label: '待补充', type: 'danger' }
}

如果某条记录来自其他任务，页面可以展示一个抽象提示：

function getAllocationTip(row: AllocationRow) {
  if (!row.shared) {
    return '当前资源为普通分配'
  }
  return `该资源来自关联任务，可在详情中查看流转关系`
}

注意这里不要让前端拼接复杂业务判断。前端只消费后端给出的结构化字段，负责展示、跳转和触发操作。

PDA/移动端：把现场操作变成明确选择

移动端的挑战是操作场景更紧凑，用户通常不适合阅读大段说明。对于共享资源这类有后续流向的动作，移动端最好把选择前置。

例如当前任务结束后，如果资源还可以继续给其他任务使用，就需要让用户选择下一站：

const candidates = sharedGroups
  .flatMap(group => group.nextTaskCandidates)
  .filter(item => item.enabled)

if (candidates.length > 0 && !selectedNextTaskId) {
  showToast('请选择资源后续流向')
  return
}

但这只是体验层校验。真正提交时，后端仍要重新判断：

if (shareGroup.hasRemainingTasks() && request.getNextTaskId() == null) {
    throw new BizException("shared resource requires next task selection");
}

一个比较实用的原则是：移动端负责减少误操作，后端负责保证正确性。

[外链图片转存中…(img-9PNluI4p-1779958910323)]

关键实现：把“共享”做成服务能力，而不是散落在各处的 if

如果共享资源逻辑只写在某个接口里，后面一定会被其他流程绕开。更好的做法是把它沉淀成服务能力。

比如可以定义一个分配服务：

public interface SharedAllocationService {

    boolean hasSharedAllocation(Long taskId);

    List<NextTaskOption> listNextTaskOptions(Long taskId);

    AllocationResult allocateWithSharedPolicy(Long taskId);

    void transferAfterFinish(Long taskId, Long nextTaskId);
}

这样 Web 端检查是否存在共享状态、PDA 获取下一任务候选、后端结束流程处理资源转移，都可以复用同一套语义。

服务内部再做阶段化处理：

public AllocationResult allocateWithSharedPolicy(Long taskId) {
    TaskSnapshot snapshot = taskRepository.loadSnapshot(taskId);

    AllocationContext context = AllocationContext.from(snapshot);

    List<AllocationPlan> normalPlans = planNormalResources(context);
    List<AllocationPlan> sharedPlans = planShareableResources(context);

    AllocationResult result = allocationWriter.write(taskId, normalPlans, sharedPlans);

    taskStatusUpdater.refreshByAllocationResult(taskId, result);
    return result;
}

这里有两个重点：

先构建快照，再生成计划，最后统一写入，避免边查边改导致状态不稳定。
分配完成后刷新任务明细状态，让 Web 展示和后端真实分配保持一致。

回收与释放：不要忽略局部操作

共享资源的回收比普通资源更麻烦。普通资源通常只需要释放占用即可，但共享资源还要判断：

当前任务是否真的结束。
资源是否还有下一个任务。
是否只释放某个执行位置上的资源。
是否需要联动外部状态，比如设备提示、缓存状态或现场标识。

一个抽象后的接口可以这样设计：

public void releaseByPosition(ReleaseRequest request) {
    ReleaseScope scope = releaseScopeResolver.resolve(request);

    List<ResourceAllocation> allocations = allocationRepository.findByScope(scope);
    List<ResourceAllocation> releasable = releasePolicy.filterReleasable(allocations);

    allocationRepository.markReleased(releasable);
    indicatorService.turnOff(scope.getPositionIds());
}