立库指令进出队列缓慢解决方案
Posted Jane Chiu
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了立库指令进出队列缓慢解决方案相关的知识,希望对你有一定的参考价值。
问题描述
以现有WCS传至WMS的立库指令在现场业务较多时WMS处理效率很低(即WMS从收到WCS指令到处理完成的耗时长),其中主要是入库任务耗时达到分级,现场要求是秒级完成。
问题分析
完成对立库指令执行情况监控后,察觉所有入库卸货指令处理方式是通过队列控制并发,导致队列里两条入库指令之间存在有不少的卸货指令,故而第二条入库指令要等待很长时间才能出列进行处理。
解决方案
在不影响业务及其现有方式上,分而治之,区分开入库、卸货和Error指令,每种指令都有其相应地解决方案。
- 入库指令还是走队列控制
因为入库涉及规则业务耦合性高,故而要实现入库并发必须得考虑如何规避掉开通入库并发后产生的问题;以下红色部分为入库任务并发方案的逻辑,将用伪代码逻辑形式阐述,这部分将添加到入库规则标准wms_rule_pvt主程序包内。
- 卸货指令处理方案有三
其一,需追踪到卸货指令来源,在其来源处直接程序处理,不进入队列串行,但这种方式改造量大且开发/测试成本高,尤其是如果指令来源是与WCS交互产生的,那协调WCS开发人员和处理WCS调处理失败后重推机制较为麻烦;
其二,使用JOB直接走程序处理,当时指令表里有多少条卸货指令,JOB就取多少进行直接处理,但这种方式针对卸货指令较多时,程序处理总耗时若大于JOB频率(5s),则下一时间段的JOB任务会等待当前程序处理完毕;
其三,新增队列处理机制来处理卸货指令,这种只能串行; - Error(无法处理的完成报告)指令因目前系统数据量少且业务无耦合,可以使用JOB(频率10s)直接程序处理,不进行队列串行。
针对卸货指令,我个人建议选择第二种,如果后期总是出现了程序处理总耗时若大于JOB频率,我们可以再启个JOB进行处理,无需再进行改造等。
若按个人建议的卸货指令按方案二处理,总体队列/JOB改造的情况:之前形式为(1个队列,2个JOB)现改造后为(1个队列,4个JOB)。
针对入库规则效率影响说明二点:
- 入库任务一旦并发后,如果当前装入任务,原本在没有并发的情况下,入库规则策略给出了符合规则的货位后就可以结束找符合规则的货位的循环逻辑,但在有并发的情况下,若检测到该货位入库并发程序锁的存在,就会去找出下一个符合规则的货位,依次循环找出符合规则且没有入库并发程序锁的货位,那势必会延长该任务的装入效率。但这种影响个人觉得不大,应该会在十秒内。
- 同一物料并发入库,这才是最影响效率的一点,因为Oracle针对物料的任何库存操作(出入库)都会设置全局上现有量锁,故而现场业务需注意这一点,避免WMS存在大量的锁等待。
以上是关于立库指令进出队列缓慢解决方案的主要内容,如果未能解决你的问题,请参考以下文章
GO语言: 双单链表队列进出栈打造一个简易的数据结构库 以及测试你的程序是否存在BUG!