1. 为什么要把会话、执行、状态链三件事拆开看做过服务端远程调度本地工具的人大概率都经历过同一个阶段一开始觉得这事很简单服务端发个指令本地工具跑一下把结果回传就完事了。真上手之后才发现麻烦根本不在发指令这一步而在指令发出去之后的一连串状态管理上——谁在跑、跑到哪了、跑完了没有、结果对应的是哪一次请求、中途断了怎么办。我最初做这类系统时就是典型的一把梭思路一个 WebSocket 连接客户端收到消息就执行执行完把结果塞回去。Demo 阶段确实能跑通但只要同时来两个请求或者某个工具执行时间超过预期整个链路就开始乱套。最典型的现象是服务端收到了结果但不知道这个结果对应的是哪一次调用或者本地工具还在跑服务端已经超时重发了指令导致同一个任务被执行了两遍。问题的根子在于我把三件本质不同的事情混在了一个通道里会话Session服务端和本地客户端之间的长连接本身它是有生命周期的会断、会重连、会有多个客户端同时在线。执行Execution一次具体的工具调用它有开始、有过程、有结束可能成功也可能失败还可能超时。状态链State Chain这次执行从发起到结束的完整状态流转记录它是服务端做幂等、做重试、做结果归属判断的唯一依据。这三件事如果共用一个 ID、共用一套状态那系统一旦并发上来必然出问题。所以这篇先不聊具体怎么连、怎么传而是把拆这件事讲透——拆分会话、执行与状态链 ID是整个远程调用本地工具方案能不能工程化落地的第一道分水岭。这篇适合两类人看一类是正在做服务端调度本地能力、但被状态管理搞晕的开发者另一类是还没动手、想提前把架构想清楚的同行。我会把每个 ID 该管什么、为什么不能合并、拆开之后数据怎么流转结合我踩过的坑一条条讲清楚。至于 WSS 连接本身的建立、鉴权、心跳这些放到下一篇展开。2. 会话 ID连接的身份不是任务的身份2.1 会话 ID 到底标识什么先把概念钉死会话 ID 标识的是一条连接通道而不是一次任务。它回答的问题是这条消息是从哪个客户端、哪条连接上来的而不是这条消息属于哪次调用。很多人第一次设计时会把会话 ID 当成任务 ID 用觉得一个客户端连上来给它一个 ID后面所有请求都挂在这个 ID 下就行了。这个思路在小规模、单任务场景下能跑但只要出现下面任意一种情况就会崩同一个客户端同时处理多个任务连接断开后客户端重连但之前的任务还没结束服务端需要主动向某个客户端推送消息而不是被动等结果。会话 ID 的合理生成方式我一般用客户端标识 连接序号或者直接用一个随机 UUID在连接建立握手成功的那一刻生成绑定到这条连接对象上。它不需要全局唯一到永久只需要在这条连接存活期间唯一即可。连接一断这个会话 ID 就作废重连就是新的会话 ID。2.2 会话 ID 的生命周期与连接状态会话 ID 的生命周期和连接是强绑定的这里有个容易被忽略的细节连接断开不等于任务结束。这是新手最容易混淆的地方。我见过一种实现客户端一断线服务端就把这个会话下所有进行中的任务标记为失败。这个逻辑看起来很干净实际上很粗暴。因为网络抖动导致的短暂断线太常见了客户端可能三秒后就重连上来了任务其实还在本地正常跑着。你把它标记失败等客户端重连回传结果时服务端反而不知道该不该认这个结果。正确的做法是会话 ID 只管连接状态连接断了就标记这条会话为离线但不碰任务状态。任务状态由执行 ID 和状态链来管。客户端重连后建立新会话然后通过一个任务认领或状态同步的机制把本地还在跑的任务重新挂到新会话上。这样连接和任务就彻底解耦了。下面这张表是我总结的会话状态和任务状态的关系建议在设计时对照着理一遍会话状态任务状态正确处理方式在线进行中正常收发消息离线进行中保留任务等待重连认领离线已完成待回传缓存结果重连后补传在线已完成正常回传并清理离线超时进行中触发超时策略标记待确认注意会话离线后不要立即清理任务上下文至少保留一个重连窗口期这个窗口期要大于你预期的最大网络抖动恢复时间。2.3 多客户端并存时会话 ID 的价值当服务端要调度多个本地客户端时会话 ID 的价值才真正体现出来。比如你有三台机器都装了本地工具服务端要决定把某个任务派给谁。这时候会话 ID 就是路由的依据——服务端维护一张会话 ID → 客户端能力的映射表根据任务需要的工具类型选一个在线的、有对应能力的会话下发。如果没有独立的会话 ID你就没法做这种路由只能广播或者靠客户端自己抢这两种方式在任务量上来后都会变成灾难。广播浪费带宽、抢任务会导致负载不均。所以会话 ID 不只是个标识它是服务端做任务分发的路由键。3. 执行 ID一次调用的唯一身份证3.1 为什么执行 ID 必须由服务端生成执行 ID 标识的是一次具体的工具调用它必须满足一个硬性要求全局唯一且由服务端生成。为什么强调服务端生成因为服务端是任务的发起方它需要在任务发出的那一刻就拿到这个 ID用于后续的结果匹配、超时判断、日志追踪。如果让客户端生成再回传服务端在任务发出到收到回执之间就处于不知道任务 ID的盲区这个盲区里如果发生超时重发就会产生重复任务。执行 ID 的生成我一般用时间戳 服务端实例标识 自增序列的组合或者直接用 UUID v4。前者可读性好、便于排查后者实现简单、无碰撞担忧。具体选哪个看团队习惯但有一点必须保证同一个执行 ID 在整个系统里只能对应一次调用绝不能复用。3.2 执行 ID 与幂等性的关系执行 ID 最核心的作用是支撑幂等。远程调用本地工具网络是不可靠的服务端发出去的指令客户端可能收到、可能没收到、可能收到两次。如果没有执行 ID客户端收到两次相同指令时无法判断这是重发还是新任务就会重复执行。有了执行 ID 之后客户端本地维护一个已处理执行 ID 集合收到指令先查这个 ID 处理过没有没处理过正常执行执行前把 ID 记入集合处理过且已完成直接把缓存的结果回传不重复执行处理过且进行中回传进行中状态让服务端知道别急。这个机制看起来简单但它是整个方案能扛住网络抖动的关键。我踩过的坑是一开始没做这个集合结果服务端因为超时重发本地工具被触发了两次产生了两个副作用比如两次写文件、两次发通知排查了半天才发现是重发导致的。提示已处理执行 ID 集合不能无限增长要设置过期清理策略一般保留时间要大于服务端的最大重试窗口。3.3 执行 ID 在日志与追踪中的串联作用执行 ID 还有一个容易被低估的价值它是全链路日志的串联键。服务端发指令时打一条日志带上执行 ID客户端收到、开始执行、执行完成各打一条日志也带上执行 ID这样出问题时你可以用这一个 ID 把整条链路的日志全部捞出来一眼看清卡在哪一步。我现在的习惯是任何跨进程、跨网络的调用第一件事就是确定追踪 ID然后所有相关日志都带上它。远程调用本地工具这种场景链路本来就长服务端 → 网络 → 客户端 → 本地工具进程 → 回传没有统一的追踪 ID排查问题基本靠猜。4. 状态链 ID把一次执行的全过程串成一条线4.1 状态链要解决的核心问题如果说执行 ID 是这次调用是谁那状态链解决的就是这次调用现在到哪了。它记录的是执行过程中的状态流转已下发、已接收、执行中、执行成功、执行失败、已回传、已确认。为什么状态链要单独拎出来而不是塞在执行 ID 里因为状态是会变的而且可能变很多次。一次执行可能经历下发 → 接收 → 执行中 → 失败 → 重试 → 执行中 → 成功 → 回传这么长一串。如果把这些状态都塞在一个字段里反复覆盖你就丢失了历史出问题时无法回溯它到底经历了什么。状态链 ID 的作用是把这一串状态变更记录关联起来形成一个有序的事件序列。它和执行 ID 通常是一对多的关系一个执行 ID 对应一条状态链状态链里包含多个状态节点。4.2 状态节点的设计有序、可追溯、可重放状态链里的每个节点我一般会记录这几个字段状态类型当前处于哪个阶段时间戳这个状态是什么时候发生的来源这个状态是服务端产生的还是客户端上报的附加信息比如失败原因、重试次数、耗时。这样设计的好处是整条链是有序且可追溯的。当服务端收到一个执行成功的回传时它可以顺着状态链往回看这个执行是什么时候下发的、客户端什么时候接收的、中间有没有重试过。如果发现中间有过一次重试那就要警惕是不是有重复执行的风险。更进一步有序的状态链还支持重放。比如服务端重启后内存里的任务状态丢了它可以通过持久化的状态链把任务状态重建出来。这在做高可用时非常有用。4.3 状态链与执行 ID 的绑定方式状态链 ID 和执行 ID 的绑定我推荐两种方式看你的存储选型第一种是状态链 ID 就等于执行 ID状态节点作为执行记录的附属数据存储。这种方式简单查询方便适合状态节点不多、不需要独立索引的场景。第二种是状态链 ID 独立生成通过执行 ID 关联。这种方式适合状态节点很多、需要单独对状态做分析的场景比如你想统计平均一次执行经历几个状态节点。我实际项目里用的是第一种因为状态链本质上是执行记录的延伸没必要再引入一个独立 ID 增加复杂度。但如果你的系统需要把状态链单独做审计或分析第二种更合适。5. 三个 ID 拆开之后数据到底怎么流转5.1 一次完整调用的 ID 流转全过程把三个 ID 拆开之后一次完整的调用流程是这样的客户端连接服务端握手成功服务端生成会话 ID绑定这条连接服务端要调用某个本地工具生成执行 ID同时创建一条状态链初始状态为已下发服务端通过会话 ID 找到对应连接把执行 ID 和指令一起下发客户端收到指令先查执行 ID 是否处理过未处理则记录并开始执行状态链追加已接收客户端执行工具状态链追加执行中执行完成客户端把结果和执行 ID 一起回传状态链追加执行成功服务端收到结果用执行 ID 匹配到对应任务状态链追加已确认任务闭环。整个过程中会话 ID 负责消息走哪条路执行 ID 负责这是哪次任务状态链负责任务走到哪了。三者各司其职互不干扰。5.2 断线重连时三个 ID 如何协同断线重连是最能体现拆分价值的场景。假设客户端在执行过程中断线了会话 ID 对应的连接失效服务端标记该会话离线但不动执行 ID 和状态链客户端重连服务端生成新的会话 ID客户端上报本地还在进行的执行 ID 列表服务端把这些执行 ID 重新绑定到新会话 ID 上执行完成后客户端通过新会话回传结果服务端用执行 ID 匹配状态链继续追加。如果没有拆分断线时你根本分不清是连接断了还是任务断了重连后也无法准确恢复任务上下文。拆分之后连接问题和任务问题彻底分离各自处理各自的。5.3 超时与重试场景下的 ID 校验超时重试是另一个必须靠 ID 拆分才能做对的场景。服务端下发指令后启动超时计时器超时后它面临一个选择重发还是放弃有了执行 ID 和状态链这个决策就有依据了查状态链如果状态还停留在已下发说明客户端可能没收到可以重发用同一个执行 ID如果状态已经是执行中说明客户端收到了正在跑这时候重发会导致重复执行应该改为查询状态而不是重发指令如果状态是执行成功但结果没回传说明结果在路上丢了应该让客户端重传结果而不是重跑。这套逻辑的核心就是重试的是消息不是任务。执行 ID 保证了无论消息重发多少次任务只被执行一次。这也是为什么执行 ID 必须由服务端生成、必须全局唯一。6. 我在拆分过程中踩过的几个真实坑6.1 把会话 ID 当执行 ID 用导致的串号最早的一版我图省事客户端连上来给个 ID后面所有请求都用这个 ID 当任务标识。结果两个任务并发时回传的结果全串了——服务端收到结果用会话 ID 一查发现这个会话下有俩任务根本不知道结果是哪个的。这个坑的本质是会话是一对多的一个会话下可以有多个执行。用一对多的键去标识一对一的执行必然串号。修复方式就是引入独立的执行 ID每个任务一个回传时带上。6.2 状态覆盖式更新导致的历史丢失第二版我引入了执行 ID但状态还是用一个字段反复覆盖。结果有次任务失败重试重试成功后状态字段显示成功但失败的那次记录没了。排查时完全不知道它失败过、失败原因是什么。后来改成状态链每次状态变更追加一个节点历史完整保留。这个改动让排查效率提升了一大截因为你能看到任务走过的每一步而不是只看最终结果。6.3 重连后任务认领逻辑缺失第三版我做了会话和执行 ID 的拆分但忘了做重连后的任务认领。客户端断线重连后服务端不知道这个新会话对应的是哪个旧任务导致任务结果回传时匹配不上任务永远卡在执行中。补上认领逻辑后客户端重连第一件事就是上报本地进行中的执行 ID服务端据此重建绑定关系。这个逻辑不复杂但漏了就是致命的。7. 拆分方案落地时的几个设计取舍7.1 ID 生成放在服务端还是客户端执行 ID 必须服务端生成这个前面说过了。但会话 ID 可以灵活一点如果客户端有稳定的设备标识可以用设备标识 连接序号生成便于服务端识别是同一台设备重连如果不需要识别设备纯随机 UUID 也行。状态链 ID 我倾向于不单独生成直接复用执行 ID减少一层映射关系。除非你有独立分析状态链的需求否则没必要增加复杂度。7.2 状态链存内存还是持久化这个取决于你的可靠性要求。纯内存状态链性能好、实现简单但服务端重启就丢了。持久化状态链能扛重启但写入有开销。我的建议是关键任务的状态链必须持久化非关键任务可以内存 定期落盘。判断标准是任务丢了会不会造成业务损失。会就持久化不会就内存。7.3 三个 ID 的命名与可读性最后说个细节ID 的命名最好带上前缀比如sess_、exec_、chain_。这样在日志里一眼就能区分这是哪种 ID排查时不用去猜。这个习惯看起来小但在长链路排查时能省不少时间。8. 关于这套拆分思路的一点个人体会这套会话、执行、状态链三拆分的思路我用了几个项目之后最大的感受是它把不确定关进了笼子里。网络是不确定的、客户端是不确定的、执行时长是不确定的但通过三个 ID 各管一段每个不确定因素都有了对应的处理位置系统整体就变得可预测了。我见过不少同行一开始嫌麻烦觉得一个 ID 能搞定的事何必拆三个。但等到并发上来、断线频繁、需要重试的时候返工的成本远大于一开始就拆清楚。拆分的本质不是增加复杂度而是把混在一起的复杂度分开让每一部分都变得简单可控。下一篇我会接着讲 WSS 连接本身的建立、鉴权怎么做、心跳和重连策略怎么设计以及客户端本地工具进程怎么管理。这些和本篇的 ID 拆分是配套的ID 是骨架连接和进程管理是血肉两者合起来才是一套完整的方案。如果你正在做类似的东西建议先把 ID 拆分这块理清楚再往下走不然后面每加一个功能都会牵一发而动全身。
