从条码到云端：手机扫码App在物流分拣中的低延时高并发实践
做了八年物流信息化，我见过太多“理论上可行、现场就崩”的方案。尤其是中小配送中心，既没有自动化交叉带分拣机的预算，又不想在“双十一”这种节点被积压的包裹淹没。我们团队从2020年开始，就在华东几个仓配客户那里推一个看起来很土但极其耐造的思路：用改装过的安卓手机当扫码终端，背后接一套自己写的轻量云端服务，专门解决物流分拣里最头疼的两个词——低延时、高并发。
先说为什么是手机，而不是工业PDA。不是因为便宜这么简单。现在中端安卓机的摄像头在景深和帧率上，已经能稳定识别脏污、褶皱的一维条码；更关键的是，它的无线模块和系统生态，让我们能直接用WebView套壳做App，迭代速度按天算。工业设备固件升级一次走流程要两周，手机端热更新半小时全覆盖。
但手机扫码最大的坑，不在识别率，在“扫完之后”。分拣员一秒扫两单，两百个人同时在线，就是每秒四百次写请求。如果走传统REST接口，每次都建连接、查库、回包，MySQL在主键冲突和行锁上会直接躺平。我们第一版就栽在这，晚高峰延时从80毫秒飙到4秒，分拣线堵得像个停车场。
后来逼出来一套组合拳。终端侧，App不做实时上传，而是本地建一个SQLite队列，扫码成功先落本地，立刻给分拣员“绿勾”反馈，这个时间控制在30毫秒以内——人感无延迟。网络好的时候，后台线程按批量（比如每20条或200毫秒）打包成Protobuf推到云端网关。云端这边弃用同步入库，用Go写了一个无状态接入层，收到批次直接扔进Kafka，削峰填谷。下游消费者按仓别分区，Redis做预校验（看这单是不是已分拣过），PolarDB只承接最终落盘和统计。
这里有个细节很多同行会忽略：高并发不是“能收多少”，是“别让错单混进去”。我们云端对批次做了幂等键，手机端每次打包带设备号 递增序号，重复包直接丢弃。去年“618”，其中一个客户现场187台手机同时跑，峰值写入3.2万条/分钟，云端P99延时压在110毫秒，分拣差错率比他们上年用老PDA还低了0.7个千分点。
当然，手机方案不是银弹。低温仓电池衰减、个别机型摄像头老化，我们都在App里做了健康度上报，仓管员平板上能看见哪台机子该换了。从条码到云端，本质不是技术多炫，是把合适的工具放在合适的泥地里。物流这行，能扛住高峰还不掉链子的，才是真权威。
微信号：18581869297
