全渠道这个词，在零售业被讲烂了。但在技术后端，它更像是一场对状态机的持久战。我做了六年，踩过无数坑，今天不聊营销，只拆两个核心：状态同步，订单路由。
别看这两个词简单。它们决定了你的系统能不能在双十一的流量洪峰里活下来，也决定了顾客在门店退货时，你线上积分是否立刻回滚。
核心思想就一句话：所有渠道，共享一个事实来源。
你可以把整个全渠道系统想象成一张庞大的地铁网络。每一条地铁线是一个渠道——线上商城、小程序、门店POS、第三方平台。而唯一的换乘站，就是我们的统一状态层。所有渠道的事件都必须经过这里，否则就会像列车闯进别的轨道，瞬间乱成一锅粥。
一、统一状态层：不只是同步，是让数据变成一条河
很多团队的“全渠道”，其实是“多渠道”：各渠道独立数据库，用定时任务批量同步。那是水壶式倒水，到用户面前永远是半凉的。我们的做法，是把所有渠道的订单、库存、会员数据，全部改成事件流。每一次状态变更，都变成一个不可变的事件。
注意，这里有个认知门槛：不是把状态同步过去，而是让状态在事件流里“生长”。
每个事件必须携带一个 prevVersion。一旦当前版本和它不匹配，就说明发生了并发冲突。我们并没有尝试自动合并，而是把冲突事件推给人工处理。为什么？因为业务语义太复杂，线上自动合并，且不说风险，光验收就过不了。也许你羡慕那些用 CRDT 的团队，但 CRDT 在全渠道这种业务里，无法满足“积分和退款”的强一致性。
事件溯源的好处是，任何时间点的状态都可以回溯。这个能力在排查线上故障时救命！你能精确回放到昨天的 14:03:07，看到那一秒订单到底发生了什么。
这里有一个数据：系统上线后，对账误差从 0.7% 降到了 0.01%。我们每个月省了一个专职对账的人。
二、路由算法：用数学把订单“推”到正确的地方
有了统一状态层，下一步就是路由。一句话概括：一张订单来了，到底哪个仓库发货？很多人直接按距离选，但那是天真。
我们的成本函数长这样：
履约成本 = 物流费 + 库存积压惩罚 + 退货风险系数 + 时效违约罚金
这里面每一个子项，都会随着用户地址、商品类型、仓库实时库存变化。优化目标是让总履约成本最小。但我们不能跑遗传算法，太慢。我们用了一个两阶段近似算法：先基于覆盖度筛掉 80% 的仓，再用动态规划在剩下的仓里找最优。
这个设计后来成了我们系统的“工程美学”代表。为什么？因为它把复杂问题拆成了两个简单步骤，像精密的齿轮一样咬合。
为了验证，我们做了一轮对比压测。
同样的 1000 万订单量，模拟 200 个门店并发路由。传统方案是中心式库存轮询，每 5 秒同步一次，路由决策时拿到的数据已经过期。结果：P99 延迟 2.8 秒，超卖率 1.2%。我们的方案：P99 延迟 180 毫秒，超卖率 0.003%。你没看错，延迟快了 15.5 倍，超卖率低了 400 倍。
能达到这个数字，除了路由，更关键的是事务消息。我们用本地消息表加 RocketMQ 事务消息，保证事件不丢不重。压测中，RocketMQ 的重试机制救了我们至少三次。所以，如果你想复制这个架构，请一定选一个靠谱的消息中间件。
三、三个坑，每个都是给生产环境的“献祭”
这里我不想全讲，只讲那些真正让团队加过班的坑。
第一个：消息乱序。多渠道并发写事件，顺序会乱。这是必然的。如果你直接消费，状态会倒退。我们要在每个事件上挂一个单调递增的 sequence，消费者端按 sequence 缓存并排序，然后顺序执行。注意，sequence 必须由源头统一分配，不能靠时间戳。因为服务器时钟在 NTP 同步时，可能往回跳几百毫秒。我们曾在凌晨四点被消息乱序搞到全量回放！
第二个：预占库存和实际扣减的模型。如果你下单就扣库存，后果是什么？很多人拍下不付款，库存被锁死，毛利全无。我们做的是“预占-释放-扣减”三步。但预占事件和释放事件频率极高，会导致 Redis 中的库存 count 剧烈抖动。最后我们把预占事件独立成状态标签，不再和实时库存数字混在一起。释放时，异步修正库存。用了这个模型，库存缓存命中率从 91% 升到 99.4%，QPS 高峰也不担心穿透。
第三个：约束条件缺失导致的离谱路由。我们的初版算法，只考虑了距离和库存。结果，一批订单被路由到了偏远仓，因为那里的库存多，可实际运费高到吓人。结果用户承诺的次日达完全无法实现。第二天被业务方一顿骂。修复方法很简单，把约束条件做成可动态配置的 JSON 下发，比如“物流时效要求”和“地址偏远程度惩罚”权重随时可调。这样我们改一次权重，5 分钟内全部节点生效，不用发版。
这三个坑，每一个都让我们付出了至少一周的工时。所以分享出来，希望你们别掉进去。
最后，很多人问我，全渠道的最佳实践是什么？说实话，我脑子里没有标准答案。唯一确定的是，把状态建模放在第一位。那些表面上的 API 网关、消息中间件、多级缓存，都只是表演。真正的功夫，在事件的定义和状态转换的约束里。
你可以在一个晚上接入 Flink 或者 Spark，但如果你没有把状态的来龙去脉理清，一切工具都只是给空中楼阁添砖。
就这样吧。
