动车自动售货机管理系统：弱网通信与订单状态机的工程实践

1. 项目背景与需求拆解1.1 动车场景下的特殊约束“动车自动售货机”这七个字我头一回看到时候真没当回事心想不就是把地铁站里那台售货机搬上火车么等真正动手做需求分析才发现这完全是一个“看起来简单、做起来全是坑”的项目。普通售货机是固定电源、固定网络、固定空间坏了大不了换个机位动车售货机是装在高速移动的列车上供电是直流母线、网络是时有时无的4G/5G信号、空间是人均几十厘米的道道连补货都要卡在列车进站停靠的几分钟窗口里完成。这才是动车上做自动售货机最真实的面貌稳定压倒一切离线必须兜底。我梳理这个项目的第一个动作就是把动车环境约束整理成一张需求输入表后续所有设计都围绕这张表展开。动车车厢内没有标准220V市电整车供电以DC110V为主部分车型还有DC24V/DC48V接口售货机必须做宽压输入和隔离转换。运行途中网络状况极不稳定进出隧道时信号直接归零所以终端不能依赖“必须在线才能卖货”的模式。空间上又要考虑旅客行李架、过道宽度和设备开门检修的最小尺寸售货机整机高度、深度都被锁死。这些硬性约束摆在面前传统售货机方案基本等于直接报废必须重新设计。1.2 系统范围与角色划分这个项目虽然叫“管理系统”但实际交付物是“终端设备 云端服务 运营后台 运维工具”四位一体的完整链路。只做一套后台管理界面是远远不够的因为售货机一旦在动车上通电运行就牵扯到设备注册、订单下发、库存同步、退款对账、补货盘点、故障上报等一整套闭环。我把系统角色划分成三类旅客是购买者只用触屏或扫码完成选购支付补货运维人员负责装货、调整货道、查看设备状态、处理卡货故障运营管理人员盯的是销售数据、库存周转、设备在线率和退款处理。每个角色的关注点差异很大。旅客只关心能不能快速买到水、不重复扣款补货员关心一条线路停靠站之间能装多少货、货道映射是否准确运营关心的是某个SKU在哪个车次卖得好、哪些车次退货率高。所以系统设计不能做成一套界面通吃所有角色而是要在后端明确划分权限域和数据口径。我在项目一开始就强制定义了“终端设备—商品库存—订单流水—结算记录”四大核心数据域所有角色看到的报表都从这四个数据域聚合避免后续出现“终端显示有货但后台显示无货”这类数据孤岛问题。2. 整体架构设计与核心方案选型2.1 分层架构终端、通信、业务、管理四条线我当时给这个项目画的第一版架构图不是先画技术组件而是先画数据走向。因为售货机项目的数据流非常长从旅客扫码开始到售货机出饮料再到云端扣款、库存减一最后生成一张对账报表中间经过至少五个节点。任何一个节点的数据不一致都会造成“扣了钱不出货”或者“出了货没扣钱”的严重客诉。所以整体架构我采用的是比较稳妥的四层设计每一层只做好自己那一件事。设备层就是售货机终端的嵌入式主控负责电机驱动、光电出货检测、温度采集、触摸屏交互、支付模块通信。通信层主要是网络保障终端走4G/5G蜂窝网络通道上报数据同时内置本地存储做离线缓存网络恢复后自动追传。业务服务层是后端API承载订单管理、商品管理、设备管理、库存中心、支付回调、对账任务。管理展示层就是运营后台和运维APP提供数据看板、补货任务单、异常告警功能。这样的分层最大的好处是替换成本低通信层将来从4G换到5G模组业务层完全不用改设备层增加新机型服务端只需要新增设备型号配置不用重新开发接口。2.2 硬件主控选型与服务端技术栈硬件选型这部分我反复权衡了很久。动车上空间有限发热要小接口要稳定成本还不能失控。最终确定的是“双芯片”方案主控用STM32F407系列负责电机控制、传感器采集和执行逻辑网络与交互用一块Linux工控板也可以理解成安卓屏或精简工控主机负责支付流程、用户界面和服务端通信。两块芯片之间通过串口协议通信主控只做执行工控板只做业务交互这样即使工控板死机重启主控还能保证当前货道电机不会误动作安全性有个兜底。服务端我选择的是Spring Boot加MySQL加Redis这套主流组合没有上特别花哨的新技术。原因很实际售货机系统的核心是订单和库存的强一致性MySQL的事务能力足够可靠Redis用来做分布式锁和热点数据缓存比如库存预扣、订单幂等校验至于消息队列只在退款和补货通知场景用了轻量级的解决方案避免引入过重的基础设施。对这个项目来说技术选型的第一原则不是“炫技”不是“上微服务”而是团队接手快、线上出问题能快速定位。3. 核心功能模块设计与实现3.1 终端控制流程从扫码到出货的状态机设计售货机终端最核心的流程就是“支付后出货”这个流程如果做不好其他一切功能都白搭。我设计的时候把终端运行状态严格定义成六个状态空闲、出货中、支付成功待出货、出货失败、故障停机、离线补货。终端每一次接收到服务端指令都会先判断当前状态是否能执行比如电机正在转动时如果又来一笔退款指令终端必须拒绝执行防止因指令并发导致重复出饮料。从扫码到出货的完整链路是这样的旅客扫描售货机屏幕上的动态二维码其实这个二维码带着设备编号和本次会话标识服务端收到扫码请求后创建设备会话旅客在手机上选择商品并支付微信或支付宝回调服务端“已支付”服务端生成一张订单把订单内容和货道号下发给终端终端收到“出货指令”后驱动对应货道的电机转圈把商品推落同时红外光电传感器检测到商品掉落终端把出货结果上报服务端服务端确认后返回给用户手机“出货成功”。关键的一点是这笔订单在服务端必须保持“待出货”状态等终端确认落到“出货成功/失败”之后才真正闭环不能支付回调一到就立刻把订单置为已完成。这个看似微小的顺序问题恰恰是很多售货机项目出现“钱扣了货没出但订单显示成功”的根源。3.2 出货检测与卡货兜底机制出货检测是售货机上最被低估的难题。看起来电机转几圈把饮料推下来就行了实际上不同瓶型、不同重心、不同温度下的饮料滑动阻力完全不一样尤其夏天放过碳酸饮料之后瓶身有水珠摩擦力明显增加电机推动时非常容易出现“半卡不卡”的状态。我的做法是在每个货道末端加一组对射式光电传感器电机动作后等待固定时间窗口如果光电传感器没有检测到商品挡光再复亮就判定为疑似卡货立即触发一次反向转动把货道里的商品退回去避免产生“夹了一半”的尴尬状态。如果反向转动之后光电传感器仍然没有恢复终端直接上报“卡货故障”服务端自动把这条货道设置为不可售卖并在后台生成待处理工单防止旅客后续继续下单买到故障货道。同时退款流程也会从人工介入改为自动判断只要订单支付成功但出货失败系统在五秒内自动原路退款并给用户推送通知。旅客最不能接受的就是“扣钱不出货还要等客服”自动退款机制能在很大程度上把客诉消解在产生之前。以下是我在终端主控里设计的一段简化状态判断逻辑用伪代码描述核心分支// 终端主控出货执行流程简化版 int execute_delivery(order_t *order) { if (device_state ! STATE_IDLE) { return ERR_BUSY; // 非空闲状态拒绝出货 } device_state STATE_DELIVERING; motor_start(order-channel_id); // 启动对应货道电机 bool drop_ok wait_detect(DETECT_TIMEOUT_MS); // 等待光电检测 if (!drop_ok) { motor_reverse(order-channel_id); // 反向转动尝试退卡 if (!wait_detect(DETECT_TIMEOUT_MS)) { device_state STATE_FAULT; // 确认卡货 report_fault(order-channel_id); return ERR_JAM; // 等待自动退款 } } motor_stop(); device_state STATE_IDLE; return OK; }这段逻辑在项目里反复打磨过很多遍特别要提醒的是“等待光电检测”的超时窗口不要设得太长。太短会导致大瓶饮料还没来得及掉落就误判卡货太长又会让下一个旅客等待过久。我第一次测试用了10秒窗口结果实际使用中用户普遍觉得“出货好慢”后面调成动态窗口小瓶水6秒、大瓶饮料8秒体验才正常。3.3 库存管理与补货闭环库存是售货机系统的第二个命门。传统售货机常见的库存问题是“终端库存和后台库存两张皮”补货员把货装进机器但没有扫货道码后台不知道实际库存卖了几瓶之后两边数字对不上只能靠人工盘点强制校正。我在这套系统里把补货流程做了严格闭环补货员在运维APP上选择当前车次和机器编号逐个货道扫描商品条码录入“补货数量”提交后服务端更新该货道库存并生成一条补货流水。库存扣减的逻辑也做了特殊设计。终端每次成功出货后上报的不是“当前剩余数量”而是“本次扣减一个剩余X个”服务端收到后以本次出货记录为准扣减库存同时记录一个“终端上报剩余量”用于比对。如果两边差异超过阈值系统自动生成盘点提醒而不是直接信任某一侧。这个设计在动车上特别重要因为补货窗口很短补货员可能漏扫一两瓶只有通过每笔出货的连续比对才能及时发现库存漂移否则等库存差到十几瓶才发现整台机器的热点商品已经断货很久了。关于补货盘点我还加了一个“整层盘点”模式补货员在APP上选择某层货道把实际数量填写提交服务端直接把该层库存覆盖为填写的数量。这个模式在补货员时间特别紧的时候非常实用但它必须追加操作日志和审批动作防止误操作导致库存被篡改。实际项目里有运维人员反馈“整层盘点太爽了有时候来不及一瓶瓶扫”但也确实出过一次把数字填错导致后台库存虚高的乌龙所以后来加了“盘点前后差异大于阈值必须二次确认”的规则。3.4 支付回调与订单对账的幂等设计支付是整个系统里最容易出“线上问题”的环节任何一个重复回调、漏回调、超时回调都可能造成资金差错。我设计订单状态时把订单生命周期定义了五档已创建、已支付、出货中、已完成、退款中/已关闭。每档状态之间的流转都通过状态机强制约束支付回调只能在“已创建→已支付”之间流转重复回调在“已支付”时直接返回成功不再重复处理。这里最需要强调的是幂等设计。支付平台在极端情况下会重复推送回调如果每次回调都执行一次“发货指令”旅客就会被出两瓶饮料。我的做法是在服务端用订单号加Redis分布式锁确保同一笔订单的支付回调只有一个线程能进入发货流程同时在订单表加唯一索引兜底。另外还有一个很隐蔽的坑支付回调里不能只相信回调参数里的“实付金额”必须拿这个金额和订单创建时锁定的金额比对不一致直接置为异常订单转人工处理。曾经遇到过一笔订单用户支付了1元但回调里金额显示成1.00元精度问题导致金额比对直接失败后来统一以“分”为单位的整数存储才彻底消掉这类隐患。4. 动车环境适配的关键细节4.1 供电与电源保护设计动车上的电源环境比普通市电复杂得多这不是危言耸听。列车牵引系统启停时直流母线电压会波动感性负载投切还会引入浪涌和尖峰售货机里又有电机、加热制冷模块这些频繁启停的部件自身就会对供电产生污染。所以我给售货机供电系统设计了“三级处理”第一级是宽压输入模块支持DC24V到DC110V范围内的输入自适应第二级是隔离DC-DC转换器把输入电压隔离成稳定的DC12V和DC5V给主控、工控板和外设供电第三级是电机驱动独立供电不和其他控制电路共用电源防止电机启动瞬间拉低电压导致主控复位。实际调试中真遇到过不少次主控无故重启查到最后就是电机启动瞬间电流太大把控制板电源拉崩了。后来把电机电源独立之后“重启怪病”基本绝迹。另外动车经常通过高压电气区段电磁干扰比普通场景强不少所以所有通信线缆我都选用屏蔽线且屏蔽层单点接地传感器信号线还要加RC滤波。一开始为了省成本用的普通排线结果4G模组经常掉线排查了一个星期最后把线缆全部换掉之后系统才稳定下来这个教训至今印象深刻。4.2 弱网环境下的通信与离线补偿动车里网络信号弱尤其进出隧道、跨省交界的时候基本处于断网状态。售货机不能因为断网就停止售卖所以我设计了“离线销售”模式终端检测到自己断网后仍然允许用户扫码、支付但是支付流程会走“离线下单延迟确认”逻辑。具体实现是这样的用户扫码后终端生成本地离线订单号不实时请求服务端而是提示用户“当前网络不稳定支付完成后请稍等片刻查看结果”用户完成支付后终端在本地缓存这笔支付结果并启动定时器每隔10秒尝试上报一旦网络恢复终端把缓存的所有订单批量上传服务端服务端按订单号和设备编号去重后逐个调用支付平台查询凭证确认成功才更新库存和订单状态。这样设计之后即便用户在隧道里买了饮料出隧道后也能在几分钟内看到支付结果更新不会出现“钱付了货没出用户还在那等半天”的体验灾难。这里一定要注意离线销售的缓存数据在终端本地不能放太久项目里设置的是72小时过期。超过72小时还没上报成功的订单终端会强制标记为“待人工处理”并在运维后台生成对账异常记录因为网络中断超过三天订单到底成没成功已经很难确认了必须人工介入不能一直挂着。5. 数据库表设计与核心查询逻辑5.1 核心数据表结构数据库方面的核心表我设计得比较克制没有做一堆“看起来很全但实际没人用”的字段。主要分成四张核心业务表设备表、商品表、货道表、订单表。设备表记录每台售货机的编号、型号、所在车次、安装车厢、当前在线状态、固件版本商品表记录商品基础信息包括名称、条码、售价、规格、图片货道表是设备和商品之间的映射关系记录某台设备第几层第几列对应什么商品、当前库存、最大容量订单表记录每一笔交易包括订单号、设备编号、货道ID、商品ID、实付金额、支付渠道、状态、创建时间、完成时间、退款时间。订单表是整个系统的核心也是数据量增长最快的表。动车上一天一个车次可能产生几百笔订单几十个车次的设备一周就能累计上万条数据。我特意为订单表做了按月分表避免单表数据量过大导致查询越来越慢。同时订单表里有一个“device_report_snapshot”字段存的是终端上报的当前库存JSON快照虽然看起来冗余但对排查“库存两遍不一致”非常有用因为随时可以回溯到某笔订单发生时终端到底认为货道里还有多少货。以下是一个简化版的订单表结构字段设计可以直接参考字段名类型说明order_idvarchar(64)订单号全局唯一device_idvarchar(32)设备编号channel_idint货道编号goods_idint商品IDpay_amountint实付金额单位分pay_channeltinyint支付渠道1-微信2-支付宝order_statustinyint订单状态1-已创建2-已支付3-出货中4-已完成5-退款中6-已关闭create_timedatetime下单时间paid_timedatetime支付成功时间finish_timedatetime出货确认时间device_report_snapshotvarchar(512)终端上报库存快照5.2 订单状态机与异常单处理流程订单状态机我强烈建议每个字段的状态流转都做成枚举驱动而不是散落在业务代码里到处改。我们项目里定义了一个订单状态枚举类所有更新订单状态的操作都走同一个入口方法方法里面先校验当前状态到目标状态的流转是否合法不合法直接抛异常。比如“已创建”的订单不能直接变成“已完成”必须先到“已支付”再到“出货中”最终才能到“已完成”。这套状态机上线之后订单状态乱跳的问题基本绝迹。异常单处理流程同样重要。我把“支付成功但出货失败”和“出货成功但上报失败”都归为异常单每天凌晨跑一个巡检定时任务把超过24小时还没有走到最终状态的订单全部扫描出来自动挂起并通知运营人员。运营人员在后台可以对异常单执行“退款”“强制完成”“人工确认”三个操作。这里要注意退款操作和订单状态更新必须放在同一个数据库事务里否则可能出现订单标记退款了但支付平台退款失败财务两边对不上。6. 项目落地与常见问题排查6.1 现场部署踩过的坑项目上线部署阶段我们曾经在动车上连续跑了一周模拟测试发现有一个高频问题列车频繁过隧道时终端上报的订单状态经常前后错乱。排查了很久最后定位到是4G模组在信号恢复瞬间会快速恢复连接导致之前缓存的请求和新的请求同时涌出而服务端处理线程并发执行先进来的后处理后进来的先处理把订单顺序搞乱了。解决方案是在终端和服务端之间增加一个单调递增的序列号服务端对同一设备的请求按序列号强制排序序列号不连续就缓存等待确保顺序不乱。还有一个很容易被新入行的人忽略的坑是“时间同步”。动车售货机长期在弱网环境下运行终端本地时间很容易漂移如果终端上报订单时间和服务端时间不一致对账的时候会出现早上八点的订单排在晚上十点后面的怪异现象。我们的做法是每次网络恢复且服务端下发校时指令时终端做一次时间校准同时所有订单上报带上“本地时间戳”和“服务端接收时间戳”两个字段对账时以服务端时间为准但保留终端原始时间用于排查延迟问题。6.2 常见故障速查表我把项目里遇到的高频故障整理成了一张速查表每次培训新同事的时候直接发这张表能省掉很多重复答疑。故障现象可能原因处理方式用户支付成功但未出货货道电机故障/卡货/终端离线先查终端是否在线在线则查货道电机状态触发自动退款终端离线后台看不到状态4G信号弱/模组死机/供电异常远程重启终端检查供电电压确认天线位置库存显示和实际不符补货未录入/订单上报丢失执行货道盘点校准查询订单流水比对差异订单状态一直“出货中”终端上报丢失/服务端回调未处理查看终端本地缓存手动补推上报或强制关闭订单用户重复扣款支付回调重复/幂等失效检查Redis锁和唯一索引核对支付平台流水6.3 性能与稳定性优化建议系统上线至今我持续做了一些优化效果最明显的有三处。第一处是服务端的核心接口全部做了Redis缓存比如商品列表、货道信息、设备信息这些数据变更频率很低完全不必要每次都查数据库加了缓存之后接口平均响应时间从80ms降到10ms以内。第二处是终端上报接口做成了批量模式断网恢复后一次性上报几十条订单而不是一条一条请求大幅减少弱网环境下的连接开销。第三处是报警规则我只对“连续三单出货失败”和“设备离线超过30分钟”这类高价值事件推送告警其他琐碎日志一律进日志平台避免运维人员被告警轰炸产生疲劳。实际运营中有一个数据让我特别有感触上线自动退款机制之前每天客诉里约有四成和“扣款未出货”相关上线自动退款和状态机之后这类客诉几乎下降了一个数量级。事实证明售货机系统的体验提升很多时候不是靠前端界面多好看而是靠后台异常处理流程多严密。最后再分享一个小的调试思路如果你在装售货机类项目建议在所有关键节点都加上日志埋点特别是支付回调、出货指令下发、出货结果上报这三个环节每条日志都打上订单号。线上出问题的时候只要拿着订单号把这三个环节的日志拉出来排个序问题基本十有八九能一眼看到。这个习惯帮我省下了很多本该熬夜排查的时间真的非常值。