状态机之外:多张订单同时活跃时,谁拥有状态
来源:dev.to — 2026-11-06
📋 概述
上一篇文章让订单能等待外部结果而不假装操作已完成:承运商询价返回请求 ID,回复以消息形式到达,队列消费者先核对它是否仍属于尚未完成的询价再应用。但一个订单有几个组件同时说话时,转移表只回答「这个变更允不允许」,回答不了「谁有权执行这个决定」。作者指出两条绕过路径:创建 order 的代码可以仍然持有对象直接赋值 order.status,队列再正确也白搭;以及 frozen 消息里的 payment 字段仍指向可变对象,发送后改它,消费者收到的和发送者想提交的不是一回事。加锁也不够,因为锁同样要求每个写入者配合。他的答案是给每张订单一个所有者——这是 actor 形状的边界:状态机定义哪些变更是合法的,actor 边界定义谁可以执行。
🔑 核心要点
- 队列只排序消息,不约束所有变更路径;持有可变对象的调用方可以完全绕过队列、转移表和校验器。
- frozen dataclass 不会让嵌套字段不可变,同一个 payment 对象在消息发出后仍能被修改。
- 共享锁要求每个写入者参与,这与「靠队列收口」是同一类错觉,只是换了个位置。
- 多个订单 actor 可以挂在同一个 Python 事件循环上,不需要各自独占线程。
💡 金句
“The state machine defines which changes are valid. The actor boundary defines who may perform them.”
译:状态机定义了哪些变更是合法的,actor 边界定义了谁有权执行这些变更。
👍 0
👎 0
← 返回 dev.to 首页