CN116545941A - 一种指令发送方法、系统、智能终端及存储介质 - Google Patents

一种指令发送方法、系统、智能终端及存储介质 Download PDF

Info

Publication number
CN116545941A
CN116545941A CN202310782115.XA CN202310782115A CN116545941A CN 116545941 A CN116545941 A CN 116545941A CN 202310782115 A CN202310782115 A CN 202310782115A CN 116545941 A CN116545941 A CN 116545941A
Authority
CN
China
Prior art keywords
instruction
transmission
service
sending
daily
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
CN202310782115.XA
Other languages
English (en)
Other versions
CN116545941B (zh
Inventor
何传琛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Huaxiang Lianxin Technology Co ltd
Original Assignee
Beijing Huaxiang Lianxin Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Huaxiang Lianxin Technology Co ltd filed Critical Beijing Huaxiang Lianxin Technology Co ltd
Priority to CN202310782115.XA priority Critical patent/CN116545941B/zh
Publication of CN116545941A publication Critical patent/CN116545941A/zh
Application granted granted Critical
Publication of CN116545941B publication Critical patent/CN116545941B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2425Traffic characterised by specific attributes, e.g. priority or QoS for supporting services specification, e.g. SLA
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/24Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2441Traffic characterised by specific attributes, e.g. priority or QoS relying on flow classification, e.g. using integrated services [IntServ]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本发明涉及一种指令发送方法、系统、智能终端及存储介质,其方法包括获取所有待发送的业务指令,每个业务指令都有所属的指令类型以及指令特征,指令特征至少包括处理时段、上级关联关系和指令所属对象中的一个;获取当前日期;根据所有指令类型的处理时段、当前日期和日发送上限值确定当日可发指令和当日必发指令;获取历史数据;根据当日必发指令的数量、历史数据中核心指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度确定多个发送时间点和每个发送时间点的发送速度;在每个发送时间点按照预设的发送策略至少发送一批当日可发指令。本发明具有稳定、及时地发送业务指令的特点。

Description

一种指令发送方法、系统、智能终端及存储介质
技术领域
本申请涉及电信业务管理的技术领域,尤其是涉及一种指令发送方法、系统、智能终端及存储介质。
背景技术
虚拟运营商,是指依靠租用传统电信运营商的通信资源开展电信业务的新型电信运营商。虚拟运营商一般拥有某种或者某几种能力,如技术能力、设备供应能力、市场能力等。在租用基础通信资源之后,根据自身主营业务优势对通信服务进行深度加工,最终以自己的品牌、自建的客户服务系统,向消费者提供通信服务。
可以了解的是,虚拟运营商为了持续提供其主营业务,也需要和联通、移动、电信等实体运营商进行业务往来。具体来说,虚拟运营商根据需求会向实体运营商发送多种业务指令,例如:开户、停机、开机等。对于虚拟运营商而言,这些待发送的业务指令都存储于指令池中。尤其是在特殊时间点时,指令池中业务指令的数量会突然增多。然而,实体运营商对有的业务的办理时段有要求,还对有的业务每天的业务指令的发送数量有要求,这就导致虚拟运营商难以将业务指令稳定、及时地发送。
发明内容
本申请目的一是提供一种指令发送方法,具有稳定、及时地发送业务指令的特点。
本申请的上述申请目的一是通过以下技术方案得以实现的:
一种指令发送方法,包括:
获取待发送指令池中所有待发送的业务指令,每个业务指令都有所属的指令类型,以及与指令类型对应的指令特征,每个业务指令的指令特征至少包括处理时段、上级关联关系和指令所属对象中的一个, 所述处理时段为实体运营商为每一类业务指令指定的办理时段,所述上级关联关系为两种指令类型先后顺序的关联性;
获取当前日期;
根据所有指令类型的处理时段、当前日期和日发送上限值确定当日可发指令和当日必发指令,所述日发送上限值为实体运营商设定的每类业务指令一天可发送的数量上限;
获取历史数据,所述历史数据包括每个指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度,所述发送速度为单位时间内发送的指令数量;
根据当日必发指令的数量、历史数据中核心指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度确定多个发送时间点和每个发送时间点的发送速度,所述核心指令类型为处理时段与当前日期最为接近的指令类型;
在每个发送时间点按照预设的发送策略至少发送一批当日可发指令。
通过采用上述技术方案,能够根据当前日期和不同指令类型的业务指令的处理时段对待发送指令池中的业务指令进行分类,从而得到当日可发指令和当日必发指令。根据当日必发指令的数量和历史数据所确定的多个发送时间点使得当日必发指令能够分散在不同的发送时间点发送,不仅能够用于监测每个发送时间点的发送效率,也能够保证至少将当日必发指令全部发送至实体运营商,以实现稳定、及时地发送业务指令。
本申请在一较佳示例中可以进一步配置为:所述当日必发指令包括第一必发指令和第二必发指令,根据所有指令类型的处理时段、当前日期和日发送上限值确定当日必发指令包括:
根据所有指令类型的处理时段和当前日期确定第一必发指令;
若所述第一必发指令中有指定指令类型的业务指令且上一级指令待发送,所述指定指令类型为具有上级关联关系的指令类型,所述上一级指令为与该业务指令为同一指令所属对象的具有上级关联关系的业务指令;
则在确定上一级指令属于当日可发指令时,根据上一级指令的指令类型所对应的处理时长判断该业务指令是否能在当日完成处理,得到判断结果;
根据判断结果调整第一必发指令的数量。
通过采用上述技术方案,可以从不同角度统计当日必发指令,使得统计的当日必发指令更加准确。在统计第一必发指令时,将上一级指令考虑进来,能够避免出现接收到因业务指令发送顺序不对而导致的业务指令发送失败的问题。
本申请在一较佳示例中可以进一步配置为:所述根据判断结果调整第一必发指令的数量包括:
若判断结果为上一级指令能在当日完成处理,则将该业务指令列为第一必发指令;
若判断结果为上一级指令不能在当日完成处理,则将第一必发指令中与该上一级指令为同一指令所属对象的具有上级关联关系的业务指令从第一必发指令中删除。
本申请在一较佳示例中可以进一步配置为:所述根据所有指令类型的处理时段、当前日期和日发送上限值确定当日必发指令包括:
根据所有指令类型的处理时段和当前日期确定当日可发指令;
根据当日可发指令和第一必发指令确定实际可发指令中所有指令类型的指令数量,所述实际可发指令为当日可发指令中除第一必发指令的业务指令;
根据当前日期和实际可发指令中所有指令类型的处理时段确定实际可发指令中所有指令类型的处理时限,所述处理时限为可发送每个指令类型的业务指令的剩余时长;
根据实际可发指令中所有指令类型的指令数量、处理时限、日发送上限值确定第二必发指令。
通过采用上述技术方案,将第二必发指令作为当日必发指令,以使第二必发指令能够在当日发出,这有利于所有当日可发指令能够在各自处理时段内完成发送。
本申请在一较佳示例中可以进一步配置为:所述根据当日必发指令的数量、历史数据中核心指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度确定多个发送时间点包括:
根据历史数据中核心指令类型的业务指令每个月发送量最高的那天对应时间点的发送速度确定平均发送速度;
根据当日必发指令的数量和平均发送速度确定发送时间点的数量;
按照历史数据中每个月核心指令类型的业务指令的发送速度由高到低的顺序选取相应数量的时间点,作为发送时间点。
通过采用上述技术方案,平均发送速度能够反映历史记录中发送业务指令的平均水平,以此确定多个发送时间点,并按照历史数据中发送速度由高到低的顺序选取可以在一定程度上提高选取到各个虚拟运营商发送业务指令数量较少的时间点的概率。
本申请在一较佳示例中可以进一步配置为:所述发送策略包括:
以平均发送速度发送一次当日必发指令;
当接收到实体运营商反馈的超量信息时,停止发送并等待下一个发送时间点;
当未接收到实体运营商反馈的超量信息时,提高发送速度并发送下一次当日必发指令;
当当日必发指令完成发送后,发送实际可发指令;
发送业务指令时按照业务指令的优先级进行发送,业务指令的优先级由高到低的顺序为第一必发指令中所有的上一级指令、当日必发指令处理时段较短的业务指令、当日必发指令处理时段较长的业务指令、当日可发指令处理时段较短的业务指令,当日可发指令处理时段较长的业务指令。
通过采用上述技术方案,因为发送时间点数量是根据当日必发指令数量计算的,所以每个发送时间点都发送一批业务指令时,最少也能够将所有当日必发指令数量都发送至实体运营商,这样可以保证每个发送时间点发送业务指令的效率和当天发送业务指令的效率。
本申请在一较佳示例中可以进一步配置为:还包括,当业务指令发送失败时,按照预设的重发策略重新发送,所述重发策略包括:
若发送失败的业务指令为第一必发指令中所有的上一级指令,则在接收到实体运营商反馈的报错信息后,按照发送时间点重新发送,若发送时间点晚于最晚时间点,则不再重新发送,所述最晚时间点为所有发送时间点中最晚的发送时间点减去上一级指令的处理时长;
若发送失败的业务指令为第一必发指令,则在所有当日必发指令完成发送后,统一发送;
若发送失败的业务指令为第二必发指令,则从同指令类型的业务指令中选取同等数量的业务指令发送。
通过采用上述技术方案,能够在业务指令发送失败时,尽可能地将更多的当日必发指令发送至实体运营商。
本申请目的二是提供一种指令发送系统,具有稳定、及时地发送业务指令的特点。
本申请的上述申请目的二是通过以下技术方案得以实现的:
一种指令发送系统,包括,
指令获取模块,用于获取待发送指令池中所有待发送的业务指令,每个业务指令都有所属的指令类型,以及与指令类型对应的指令特征,每个业务指令的指令特征至少包括处理时段、上级关联关系和指令所属对象中的一个, 所述处理时段为实体运营商为每一类业务指令指定的办理时段,所述上级关联关系为两种指令类型先后顺序的关联性;
日期获取模块,用于获取当前日期;
数据获取模块,用于获取历史数据,所述历史数据包括每个指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度,所述发送速度为单位时间内发送的指令数量;
指令确定模块,用于根据所有指令类型的处理时段、当前日期和日发送上限值确定当日可发指令和当日必发指令,所述日发送上限值为实体运营商设定的每类业务指令一天可发送的数量上限;
所述指令确定模块包括,
第一确定单元,用于根据所有指令类型的处理时段和当前日期确定第一必发指令;若所述第一必发指令中有指定指令类型的业务指令且上一级指令待发送,所述指定指令类型为具有上级关联关系的指令类型,所述上一级指令为与该业务指令为同一指令所属对象的具有上级关联关系的业务指令;则在确定上一级指令属于当日可发指令时,根据上一级指令的指令类型所对应的处理时长判断该业务指令是否能在当日完成处理,得到判断结果;根据判断结果调整第一必发指令的数量;若判断结果为上一级指令能在当日完成处理,则将该业务指令列为第一必发指令;若判断结果为上一级指令不能在当日完成处理,则将第一必发指令中与该上一级指令为同一指令所属对象的具有上级关联关系的业务指令从第一必发指令中删除;以及,
第二确定单元,用于根据所有指令类型的处理时段和当前日期确定当日可发指令;根据当日可发指令和第一必发指令确定实际可发指令中所有指令类型的指令数量,所述实际可发指令为当日可发指令中除第一必发指令的业务指令;根据当前日期和实际可发指令中所有指令类型的处理时段确定实际可发指令中所有指令类型的处理时限,所述处理时限为可发送每个指令类型的业务指令的剩余时长;根据实际可发指令中所有指令类型的指令数量、处理时限、日发送上限值确定第二必发指令;
时间点确定模块,用于根据当日必发指令的数量、历史数据中核心指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度确定多个发送时间点和每个发送时间点的发送速度,所述核心指令类型为处理时段与当前日期最为接近的指令类型;
所述时间点确定模块包括,
发送速度确定单元,用于根据历史数据中核心指令类型的业务指令每个月发送量最高的那天对应时间点的发送速度确定平均发送速度;以及,
时间点确定单元,用于根据当日必发指令的数量和平均发送速度确定发送时间点的数量;按照历史数据中每个月核心指令类型的业务指令的发送速度由高到低的顺序选取相应数量的时间点,作为发送时间点;
发送模块,用于在每个发送时间点按照预设的发送策略至少发送一批当日可发指令;所述发送策略包括,以平均发送速度发送一次当日必发指令;当接收到实体运营商反馈的超量信息时,停止发送并等待下一个发送时间点;当未接收到实体运营商反馈的超量信息时,提高发送速度并发送下一次当日必发指令;当当日必发指令完成发送后,发送实际可发指令;发送业务指令时按照业务指令的优先级进行发送,业务指令的优先级由高到低的顺序为第一必发指令中所有的上一级指令、当日必发指令处理时段较短的业务指令、当日必发指令处理时段较长的业务指令、当日可发指令处理时段较短的业务指令,当日可发指令处理时段较长的业务指令;以及,
重发模块,用于当业务指令发送失败时,按照预设的重发策略重新发送;所述重发策略包括,若发送失败的业务指令为第一必发指令中所有的上一级指令,则在接收到实体运营商反馈的报错信息后,按照发送时间点重新发送,若发送时间点晚于最晚时间点,则不再重新发送,所述最晚时间点为所有发送时间点中最晚的发送时间点减去上一级指令的处理时长;若发送失败的业务指令为第一必发指令,则在所有当日必发指令完成发送后,统一发送;若发送失败的业务指令为第二必发指令,则从同指令类型的业务指令中选取同等数量的业务指令发送。
本申请目的三是提供一种智能终端,具有稳定、及时地发送业务指令的特点。
本申请的上述申请目的三是通过以下技术方案得以实现的:
一种智能终端,包括存储器和处理器,所述存储器上存储有能够被处理器加载并执行上述指令发送方法的计算机程序。
本申请目的四是提供一种计算机存储介质,能够存储相应的程序,具有便于实现稳定、及时地发送业务指令的特点。
本申请的上述申请目的四是通过以下技术方案得以实现的:
一种计算机可读存储介质,存储有能够被处理器加载并执行上述任一种指令发送方法的计算机程序。
综上所述,本申请包括以下至少一种有益技术效果:
本申请能够根据当前日期和不同指令类型的业务指令的处理时段对待发送指令池中的业务指令进行分类,从而得到当日可发指令和当日必发指令。根据当日必发指令的数量和历史数据所确定的多个发送时间点使得当日必发指令能够分散在不同的发送时间点发送,不仅能够用于监测每个发送时间点的发送效率,也能够保证至少将当日必发指令全部发送至实体运营商,以实现稳定、及时地发送业务指令;
从不同角度统计当日必发指令,使得统计的当日必发指令更加准确,也能有效避免发送业务指令时出现业务指令发送顺序不对的问题;
平均发送速度能够反映历史记录中发送业务指令的平均水平,以此确定多个发送时间点,并按照历史数据中发送速度由高到低的顺序选取可以在一定程度上提高选取到各个虚拟运营商发送业务指令数量较少的时间点的概率。
附图说明
图1是本申请其中一实施例的指令发送方法的流程示意图。
图2是本申请其中一实施例的指令发送系统的系统示意图。
图3是本申请其中一实施例的智能终端的结构示意图。
图中,21、指令获取模块;22、日期获取模块;23、数据获取模块;24、指令确定模块;241、第一确定单元;242、第二确定单元;25、时间点确定模块;251、发送速度确定单元;252、时间点确定单元;26、发送模块;27、重发模块;301、CPU;302、ROM;303、RAM;304、总线;305、I/O接口;306、输入部分;307、输出部分;308、存储部分;309、通信部分;310、驱动器;311、可拆卸介质。
具体实施方式
以下结合附图对本申请作进一步详细说明。
本具体实施例仅仅是对本申请的解释,其并不是对本申请的限制,本领域技术人员在阅读完本说明书后可以根据需要对本实施例做出没有创造性贡献的修改,但只要在本申请的权利要求范围内都受到专利法的保护。
为使本申请实施例的目的、技术方案和优点更加清楚,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
本申请实施例提供一种指令发送方法,应用于虚拟运营商的服务器中,能够在实体运营商制定的限制条件下,稳定地、及时地将业务指令发送给实体运营商。
下面结合说明书附图对本申请实施例作进一步详细描述。
本申请实施例提供的指令发送方法的主要流程描述如下。
如图1所示:
步骤S100:获取待发送指令池中所有待发送的业务指令。
可以了解的是,每个业务指令都有所属的指令类型,以及与指令类型对应的指令特征。指令类型分为开户、产品功能变更、补换卡、停机、开机、销户、过户和网别变更等类型。业务指令的指令特征用于将该业务指令与其他业务指令进行区分。指令特征至少包括处理时段、指令所属对象和上级关联关系中的一个。其中,处理时段为实体运营商为每一类业务指令指定的办理时段。每一业务指令都对应有指令类型,进而也能确定其处理时段。指令所属对象即为业务指令对应的虚拟号码。在本申请中,除了开户这一指令类型的业务指令没有指令所属对象,其他指令类型的业务指令都具有指令所属对象这一指令特征。上级关联关系为两种指令类型先后顺序的关联性。例如,停机和开机这两种指令类型就具有上级关联关系。对于同一指令所属对象的具有上级关联关系的两个业务指令,需要先发送并完成处理的业务指令称为上一级指令。其中,业务指令的指令类型可以通过业务指令的格式或者是内容进行识别和区分。各个指令类型与处理时段、是否有指令所属对象和上级关联关系之间的对应关系可以预先存储于诸如存储器等具有存储功能的存储设备中。
步骤S200:获取当前日期。
由于实体运营商的数据每个月重置一次,例如业务套餐中每一项的余量,故在获取当前日期时,以某月某日的形式呈现即可。
步骤S300:根据所有指令类型的处理时段、当前日期和日发送上限值确定当日可发指令和当日必发指令。
其中,日发送上限值为实体运营商设定的每类业务指令一天可发送的数量上限。不同指令类型的业务指令的日发送上限值不同,有的指令类型的业务指令的日发送上限值为50条,有的指令类型的业务指令的日发送上限值为没有上限。当日可发指令为当前这一天可以进行发送的业务指令。因为同一指令类型的业务指令的处理时段相同,所以当日可发指令中的业务指令都是由各个指令类型的所有待发送业务指令组成的。当日必发指令为必须在当前这一天进行发送的业务指令。
在发送业务之前,首先需要明确哪些业务指令是当日可发的,哪些业务是当日必发的,分别是哪些指令类型的业务指令,每个指令类型的业务指令分别有多少。其中,由于在统计当日必发指令时需要从多个方面考虑,所以在本申请中,把当日必发指令分成了第一必发指令和第二必发指令,而后分别进行统计。
可选的,步骤S300包括以下步骤(步骤S310~步骤S360):
步骤S310:根据所有指令类型的处理时段和当前日期确定当日可发指令。
在所有待发送业务指令中,筛选出处理时段包含当前日期的指令类型所对应的业务指令,即可得到当日可发指令。
步骤S320:根据所有指令类型的处理时段和当前日期确定第一必发指令。
其中,第一必发指令为因为受处理时段限制而必须在当日发送的指令。同样的,在所有待发送业务指令中,筛选出处理时段为当前日期的指令类型所对应的业务指令,即可得到第一必发指令。值得说明的是,考虑到发送第一必发指令时,可能存在因为同一指令所属对象的上一级指令未发送而导致业务指令发送失败的情况,所以还要对第一必发指令的范围进行调整。针对上述业务指令发送失败的情况,实体运营商会反馈报错信息,从而得知业务指令发送失败。
步骤S330:若第一必发指令中有指定指令类型的业务指令且上一级指令待发送,则在确定上一级指令属于当日可发指令时,根据上一级指令的指令类型所对应的处理时长判断该业务指令是否能在当日完成处理,得到判断结果。
上述指定指令类型为具有上级关联关系的指令类型。
可以理解的是,首先需要确定第一必发指令中是否有指定指令类型,若否,则无需对第一必发指令的范围进行调整。反之,若是,则需要进一步确定指定指令类型中所有业务指令的上一级指令是否都已完成发送并完成处理。若指定指令类型中所有业务指令的上一级指令都已完成发送并完成处理,则说明当第一必发指令完成发送时,不会接收到因业务指令发送顺序不对导致的报错信息。此时,也无需对第一必发指令的范围进行调整。反之,若指定指令类型中存在个别业务指令的上一级指令待发送的情况,则还需要确定上一级指令是否为当日可发指令。若上一级指令并不是当日可发指令,则说明上一级指令无法发送,若将与之相对应的同一指令所属对象的业务指令发送,则一定会接收到报错信息。为此,将与之相对应的同一指令所属对象的业务指令从第一必发指令中删掉。若上一级指令是当日可发指令,则需要根据上一级指令的指令类型所对应的处理时长判断该业务指令是否能在当日完成处理,并得到判断结果。
上述处理时长为实体运营商办理每个指令类型的业务指令的时长。可以理解的,只有当上一级指令完成发送并完成处理,与之相对应的同一指令所属对象的业务指令才能成功发送至实体运营商。因此,在确定所有待发送的上一级指令时,需要先确定每一个上一级指令的指令类型所对应的处理时长。该步骤可以调取对照表,以确定每个上一级指令的处理时长。对照表包括每一指令类型和处理时长的对应关系。进一步的,判断结果有两种,即上一级指令能够在当日完成发送并完成处理,和上一级指令不能在当日完成发送并完成处理。其中,对照表可以预先存储于服务器中诸如存储器等具有存储功能的存储设备中。
步骤S340:根据判断结果调整第一必发指令的数量。
具体来说,当上一级指令能够在当日完成并完成处理,则将上一级指令也列入第一必发指令中。反之,当上一级指令不能在当日完成并完成处理,则将与之相对应的同一指令所属对象的业务指令从第一必发指令中删掉。
至此,能够确定所有当日可发指令中的第一必发指令。下面对第二必发指令的确定方式进行说明。
可以了解的是,第二必发指令为受日发送上限值限制而必须在当日发送的业务指令。即若第二必发指令不能在当日完成发送,则会导致相对应的指令类型的所有业务指令不能在处理时段内完成发送。
首先,可以明确的是,第二必发指令一定来自于当日可发指令中除去第一必发指令的部分。为了便于说明,下文中将当日可发指令中除去第一必发指令后的业务指令称为实际可发指令。
步骤S350:根据当前日期和实际可发指令中所有指令类型的处理时段确定实际可发指令中所有指令类型的处理时限。
其中,处理时限为可发送每个指令类型的业务指令的剩余时长,即处理时限的计算方式为处理时段中最后一天的日期减当前日期加一。
步骤S360:根据实际可发指令中所有指令类型的指令数量、处理时限、日发送上限值确定第二必发指令。
可以理解的,对于实际可发指令而言,虽然不用在当日完成发送,但其处理时段有限,每日发送量也有限,如果不提前做出合理的安排,就会使得这些实际可发指令并不能在对应的处理时段内全部发送。
下面以一个指令类型为例,进行详细说明。假设该指令类型的所有业务指令都为实际可发指令。
当得知该指令类型的指令数量、处理时限和日发送上限值时,需要计算除去当日后还能够发送该指令类型的最大指令数量,即(处理时限-1)*日发送上限值。而后,判断该指令类型的指令数量和最大指令数量之间的大小关系。若该指令类型的指令数量不超过最大指令数量,则说明当日不发送该指令类型的业务指令,该指令类型的业务指令也能够在处理时段内完成发送。反之,若该指令类型的指令数量大于最大指令数量,则说明当日需发送一部分该指令类型的业务指令。进一步的,计算指令数量与最大指令数量的差值,若差值不超过日发送上限值,则从该指令类型的业务指令中选取数量为差值的业务指令列为第二必发指令。若差值大于日发送上限值,则从该指令类型的业务指令中选取数量为日发送上限值的业务指令列为第二必发指令。
实际可发指令中每一指令类型的业务指令都按照上述方式确定需要列为第二必发指令的业务指令,即可得到第二必发指令。
至此,能够确定所有当日可发指令中的当日必发指令。
步骤S400:获取历史数据。
历史数据包括每个指令类型的业务指令每个月发送量最高的日期、对应的时间点及该时间点的发送速度。发送速度为单位时间内发送的指令数量。可以理解的是,每个指令类型的业务指令都有自己的处理时段,所以每个月中只有处理时段内有一定的发送量。其中每个月发送量最高的日期,即为在所有待发送业务指令中处理时段与当日最为接近的一个指令类型。
步骤S500:根据当日必发指令的数量、历史数据中核心指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度确定多个发送时间点和每个发送时间点的发送速度。
其中,核心指令类型为处理时段与当前日期最为接近的指令类型。
可以理解的是,实体运营商不仅会限制每个指令类型的业务指令每天的发送量,还会限制不同时刻能够接收到的指令数量。具体来说,某一天多个虚拟运营商的待发送指令都会增多,而在某一时刻,多个虚拟运营商都会发送一定数量的业务指令至实体运营商。若此时实体运营商接收到的业务指令数量太多,则会反馈超量信息,以控制各个虚拟运营商一次性发送的业务指令的数量。在这过程中,实体运营商每个时间点能够接收到的业务指令数量也是动态变化的。为了避免同一时间点各个虚拟运营商发送的业务指令数量过多,导致被实体运营商限制发送速度,需要尽量将选取的发送时间点与其他虚拟运营商发送业务指令的时间点错开。为此,本申请在发送业务指令当日会选取多个发送时间点发送业务指令。
可选的,步骤S500包括以下步骤(步骤S510~步骤S530):
步骤S510:根据历史数据中核心指令类型的的业务指令每个月发送量最高的那天对应时间点的发送速度确定平均发送速度。
平均发送速度能够反映历史各个月中核心指令类型的业务指令发送量最高时发送速度的平均水平。其中,为了便于计算,将每个时间点不同批次发送业务指令的发送速度看作是相同的。进一步的,平均发送速度的计算方式为先计算每个月发送量最高的那天对应时间点的发送速度总和,而后通过计算发送速度总和与历史数据中月份数量的比值,以得到平均发送速度。
步骤S520:根据当日必发指令的数量和平均发送速度确定发送时间点的数量。
可以明确的是,当日最少应该将当日必发指令全部发送至实体运营商,当当日必发指令完成发送后,根据实际情况可以继续发送当日可发指令中待发送 的业务指令。同时,在发送业务指令时需要先对当前发送时间点的发送速度进行监测,以确保发送业务指令时的效率。因此,根据当日必发指令的数量和平均发送速度可以确定发送时间点的数量。以最坏的情况为例,即没有一个发送时间点能够以快的发送速度发送业务指令,此时每个发送时间点都以平均发送速度发送一次业务指令以监测发送效率,这样也能保证所有的当日必发指令都能够发送至实体运营商。具体的,发送时间点的数量为当日必发指令的数量/平均发送速度的取整结果加一。
步骤S530:按照历史数据中每个月核心指令类型的业务指令的发送速度由高到低的顺序选取相应数量的时间点,作为发送时间点。
当确定发送时间点的数量后,虽然在一些实施例中可以在一天中随机选取对应数量的时间点作为发送时间点,但随机选取的时间点并没有依据,很难选取到各个虚拟运营商发送业务指令数量较少的时间点。因此,在本申请中,优选按照历史数据中每个月核心指令类型的业务指令的发送速度由高到低的顺序进行选取,这样能够在一定程度上提高选取到各个虚拟运营商发送业务指令数量较少的时间点的概率。
当然,除了将业务指令分为多个发送时间点进行发送外,还需要配合一定的发送策略,以使得所有当日必发指令都发送至实体运营商,并将当日可发指令中尽可能多的待发送业务指令发送至实体运营商。
步骤S600:在每个发送时间点按照预设的发送策略至少发送一批当日可发指令。
其中,发送策略具体包括:首先以平均发送速度发送一次当日必发指令,以确定当前发送时间点的发送效率。即当发送的业务指令数量过多时,会接收到实体运营商反馈的超量信息,当未接收到实体运营商反馈的超量信息,则说明当前发送效率较高。对于接收到实体运营商反馈的超量信息的情况,由于发送效率不能得到保证,所以需要停止发送并等待下一个发送时间点。对于未接收到实体运营商反馈的超量信息的情况,则可以提高发送速度并发送下一次的当日必发指令。在一些具体的实施例中,提高发送速度的方式可以为每次发送速度都比前一次快固定量。
进一步的,在发送业务指令时,也需要按照业务指令的优先级顺序发送,即优先发送优先级较高的业务指令。在本申请中,优先级最高的是第一必发指令中的上一级指令,因为上一级指令和与之相对应的同一指令所属对象的业务指令都需要在同一天内完成发送,并且上一级指令在发送至实体运营商后还需要经过处理时长才能完成处理,因此,上一级指令应该尽早地发送。优先级仅次于上一级指令的是当日必发指令中除上一级指令外的其他业务指令。不过,在当日必发指令中也是处理时段与当前日期越接近的业务指令的优先级越高。最后,优先级最低的是当日可发指令。同样的,当日可发指令中也是处理时段与当前日期越接近的业务指令的优先级越高。
需要注意的是,在发送第一必发指令中时,应该先将与上一级指令相对应的同一指令所属对象的业务指令进行标记并暂时存放在待发送指令池中,直到实体运营商完成对上一级指令的处理后,再将与之相对应的同一指令所属对象的业务指令发送,以避免收到实体运营商反馈的报错信息。
值得说明的是,在向实体运营商发送业务指令时,由于网络影响或者其他原因可能会导致业务指令发送失败,此时则需要将发送失败的这些业务指令重新发送。为此,本申请针对于业务指令发送失败的情况,还提供了按照预设的重发策略重新发送的方法。
具体的,重发策略对于不同的业务指令发送失败采用不同的重发方式。其中,若发送失败的业务指令为第一必发指令中的上一级指令,则在接收到实体运营商反馈的报错信息后,按照发送时间点重新发送。还需要注意的是,上一级指令的发送情况会影响与之相对应的同一指令所属对象的业务指令的发送。具体来说,若发送时间点晚于最晚时间点,则不再重新发送。可以理解的,此时虽然还能够继续重新发送上一级指令,但是与之相对应的同一指令所属对象的业务指令无法在满足上一级指令处理完成这一条件时进行发送,因此,除了上一级指令不再重新发送外,与之相对应的同一指令所属对象的业务指令也不再发送。其中,最晚时间点为发送时间点中最晚的发送时间点减去上一级指令的处理时长。
若发送失败的业务指令为第一必发指令中除上一级指令外的业务指令,贼在所有当日必发指令完成发送后,统一发送。这些业务指令可以在当日必发指令完成发送后任意时间发送,若仍接收到实体运营商反馈的报错信息,则再次发送,直至当日结束时停止发送。
若发送失败的业务指令为第二必发指令,则从同指令类型的业务指令中选取同等数量的业务指令发送。根据上文介绍的内容可以了解到,发送第二必发指令时,只要使得各个指令类型的业务指令的发送数量达到指定数量即可,因此,当部分业务指令发送失败时,从同指令类型的业务指令中选取同等树龄的业务指令重新发送即可。同样的,若仍接收到实体运营商反馈的报错信息,则再次选取相应数量的业务指令随时发送,直至当日发送数量达到要求。若当日结束时当日发送数量还没达到要求,也停止发送。还需要注意的是,第二必发指令中同样可能存在指定指令类型的业务指令,因此在从当日可发指令中选取业务指令列为第二必发指令时,或是在从当日可发指令中再次选取业务指令重新发送时,都需要避开上一级指令待发送的业务指令,以避免实体运营商反馈报错信息。
本申请的一种指令发送方法,能够稳定、及时地发送业务指令,并尽可能地确保当日必发指令都完成发送,同时也使得当日可发指令中有尽可能多的指令在当日完成发送。
图2为本申请一种实施例提供的指令发送系统。
如图2所示的指令发送系统,包括指令获取模块21、日期获取模块22、数据获取模块23、指令确定模块24、时间点确定模块25、发送模块26和重发模块27,其中:
指令获取模块21,用于获取待发送指令池中所有待发送的业务指令。
每个业务指令都有所属的指令类型,以及与指令类型对应的指令特征。每个业务指令的指令特征至少包括处理时段、上级关联关系和指令所属对象中的一个。处理时段为实体运营商为每一类业务指令指定的办理时段。上级关联关系为两种指令类型先后顺序的关联性。
日期获取模块22,用于获取当前日期。
数据获取模块23,用于获取历史数据。历史数据包括每个指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度。发送速度为单位时间内发送的指令数量。
指令确定模块24,用于根据所有指令类型的处理时段、当前日期和日发送上限值确定当日可发指令和当日必发指令。日发送上限值为实体运营商设定的每类业务指令一天可发送的数量上限。
指令确定模块24包括第一确定单元241和第二确定单元242。
第一确定单元241,用于根据所有指令类型的处理时段和当前日期确定第一必发指令;用于在第一必发指令中有指定指令类型的业务指令且上一级指令待发送时,则在确定上一级指令属于当日可发指令时,根据上一级指令的指令类型所对应的处理时长判断该业务指令是否能在当日完成处理,得到判断结果;用于根据判断结果调整第一必发指令的数量,若判断结果为上一级指令能在当日完成处理,则将该业务指令列为第一必发指令,若判断结果为上一级指令不能在当日完成处理,则将第一必发指令中与该上一级指令为同一指令所属对象的具有上级关联关系的业务指令从第一必发指令中删除。其中,指定指令类型为具有上级关联关系的指令类型,上一级指令为与该业务指令为同一指令所属对象的具有上级关联关系的业务指令。
第二确定单元242,用于根据所有指令类型的处理时段和当前日期确定当日可发指令;用于根据当日可发指令和第一必发指令确定实际可发指令中所有指令类型的指令数量;用于根据当前日期和实际可发指令中所有指令类型的处理时段确定实际可发指令中所有指令类型的处理时限;用于根据实际可发指令中所有指令类型的指令数量、处理时限、日发送上限值确定第二必发指令。其中,实际可发指令为当日可发指令中除第一必发指令的业务指令。处理时限为可发送每个指令类型的业务指令的剩余时长。
时间点确定模块25,用于根据当日必发指令的数量、历史数据中核心指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度确定多个发送时间点和每个发送时间点的发送速度。核心指令类型为处理时段与当前日期最为接近的指令类型。
时间点确定模块25包括发送速度确定单元251和时间点确定单元252。
发送速度确定单元251,用于根据历史数据中核心指令类型的业务指令每个月发送量最高的那天对应时间点的发送速度确定平均发送速度。
时间点确定模块252,用于根据当日必发指令的数量和平均发送速度确定发送时间点的数量;用于按照历史数据中每个月核心指令类型的业务指令的发送速度由高到低的顺序选取相应数量的时间点,作为发送时间点。
发送模块26,用于在每个发送时间点按照预设的发送策略至少发送一批当日可发指令。发送策略包括,以平均发送速度发送一次当日必发指令;当接收到实体运营商反馈的超量信息时,停止发送并等待下一个发送时间点;当未接收到实体运营商反馈的超量信息时,提高发送速度并发送下一次当日必发指令;当当日必发指令完成发送后,发送实际可发指令;发送业务指令时按照业务指令的优先级进行发送。业务指令的优先级由高到低的顺序为第一必发指令中所有的上一级指令、当日必发指令处理时段较短的业务指令、当日必发指令处理时段较长的业务指令、当日可发指令处理时段较短的业务指令,当日可发指令处理时段较长的业务指令。
重发模块27,用于当业务指令发送失败时,按照预设的重发策略重新发送。重发策略包括,若发送失败的业务指令为第一必发指令中所有的上一级指令,则在接收到实体运营商反馈的报错信息后,按照发送时间点重新发送,若发送时间点晚于最晚时间点,则不再重新发送。最晚时间点为所有发送时间点中最晚的发送时间点减去上一级指令的处理时长。若发送失败的业务指令为第一必发指令,则在所有当日必发指令完成发送后,统一发送。若发送失败的业务指令为第二必发指令,则从同指令类型的业务指令中选取同等数量的业务指令发送。
图3示出了适于用来实现本申请实施例的智能终端的结构示意图。
如图3所示,智能终端包括中央处理单元(CPU)301,其可以根据存储在只读存储器(ROM)302中的程序或者从存储部分加载到随机访问存储器(RAM)303中的程序而执行各种适当的动作和处理。在RAM 303中,还存储有系统操作所需的各种程序和数据。CPU 301、ROM302以及RAM 303通过总线304彼此相连。输入/输出(I/O)接口305也连接至总线304。
以下部件连接至I/O接口305:包括键盘、鼠标等的输入部分306;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分307;包括硬盘等的存储部分308;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分309。通信部分309经由诸如因特网的网络执行通信处理。驱动器310也根据需要连接至I/O接口305。可拆卸介质311,诸如磁盘、光盘、磁光盘、半导体存储器等,根据需要安装在驱动器310上,以便于从其上读出的计算机程序根据需要被安装入存储部分308。
特别地,根据本申请的实施例,上文参考流程图图1描述的过程可以被实现为计算机软件程序。例如,本申请的实施例包括一种计算机程序产品,其包括承载在机器可读介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分309从网络上被下载和安装,和/或从可拆卸介质311被安装。在该计算机程序被中央处理单元(CPU)301执行时,执行本申请的系统中限定的上述功能。
需要说明的是,本申请所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于:具有一种或多种导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中,计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质,该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输,包括但不限于:无线、电线、光缆、RF等,或者上述的任意合适的组合。
附图中的流程图和框图,图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,前述模块、程序段、或代码的一部分包含一种或多种用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
描述于本申请实施例中所涉及到的单元或模块可以通过软件的方式实现,也可以通过硬件的方式来实现。所描述的单元或模块也可以设置在处理器中,例如,可以描述为:一种处理器包括:指令获取模块21、日期获取模块22、数据获取模块23、指令确定模块24、时间点确定模块25、发送模块26和重发模块27。其中,这些单元或模块的名称在某种情况下并不构成对该单元或模块本身的限定,例如,指令获取模块21还可以被描述为“用于获取待发送指令池中所有待发送的业务指令的模块”。
作为另一方面,本申请还提供了一种计算机可读存储介质,该计算机可读存储介质可以是上述实施例中描述的智能终端中所包含的;也可以是单独存在,而未装配入该智能终端中的。上述计算机可读存储介质存储有一个或者多个程序,当上述前述程序被一个或者一个以上的处理器用来执行描述于本申请的指令发送方法。
以上描述仅为本申请的较佳实施例以及对所运用技术原理的说明。本领域技术人员应当理解,本申请中所涉及的申请范围,并不限于上述技术特征的特定组合而成的技术方案,同时也应涵盖在不脱离前述申请构思的情况下,由上述技术特征或其等同特征进行任意组合而形成的其它技术方案。例如上述特征与本申请中申请的(但不限于)具有类似功能的技术特征进行互相替换而形成的技术方案。

Claims (10)

1.一种指令发送方法,其特征在于,包括:
获取待发送指令池中所有待发送的业务指令,每个业务指令都有所属的指令类型,以及与指令类型对应的指令特征,每个业务指令的指令特征至少包括处理时段、上级关联关系和指令所属对象中的一个, 所述处理时段为实体运营商为每一类业务指令指定的办理时段,所述上级关联关系为两种指令类型先后顺序的关联性;
获取当前日期;
根据所有指令类型的处理时段、当前日期和日发送上限值确定当日可发指令和当日必发指令,所述日发送上限值为实体运营商设定的每类业务指令一天可发送的数量上限;
获取历史数据,所述历史数据包括每个指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度,所述发送速度为单位时间内发送的指令数量;
根据当日必发指令的数量、历史数据中核心指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度确定多个发送时间点和每个发送时间点的发送速度,所述核心指令类型为处理时段与当前日期最为接近的指令类型;
在每个发送时间点按照预设的发送策略至少发送一批当日可发指令。
2.根据权利要求1所述的指令发送方法,其特征在于,所述当日必发指令包括第一必发指令和第二必发指令,根据所有指令类型的处理时段、当前日期和日发送上限值确定当日必发指令包括:
根据所有指令类型的处理时段和当前日期确定第一必发指令;
若所述第一必发指令中有指定指令类型的业务指令且上一级指令待发送,所述指定指令类型为具有上级关联关系的指令类型,所述上一级指令为与该业务指令为同一指令所属对象的具有上级关联关系的业务指令;
则在确定上一级指令属于当日可发指令时,根据上一级指令的指令类型所对应的处理时长判断该业务指令是否能在当日完成处理,得到判断结果;
根据判断结果调整第一必发指令的数量。
3.根据权利要求2所述的指令发送方法,其特征在于,所述根据判断结果调整第一必发指令的数量包括:
若判断结果为上一级指令能在当日完成处理,则将该业务指令列为第一必发指令;
若判断结果为上一级指令不能在当日完成处理,则将第一必发指令中与该上一级指令为同一指令所属对象的具有上级关联关系的业务指令从第一必发指令中删除。
4.根据权利要求3所述的指令发送方法,其特征在于,所述根据所有指令类型的处理时段、当前日期和日发送上限值确定当日必发指令包括:
根据所有指令类型的处理时段和当前日期确定当日可发指令;
根据当日可发指令和第一必发指令确定实际可发指令中所有指令类型的指令数量,所述实际可发指令为当日可发指令中除第一必发指令的业务指令;
根据当前日期和实际可发指令中所有指令类型的处理时段确定实际可发指令中所有指令类型的处理时限,所述处理时限为可发送每个指令类型的业务指令的剩余时长;
根据实际可发指令中所有指令类型的指令数量、处理时限、日发送上限值确定第二必发指令。
5.根据权利要求4所述的指令发送方法,其特征在于,所述根据当日必发指令的数量、历史数据中核心指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度确定多个发送时间点包括:
根据历史数据中核心指令类型的业务指令每个月发送量最高的那天对应时间点的发送速度确定平均发送速度;
根据当日必发指令的数量和平均发送速度确定发送时间点的数量;
按照历史数据中每个月核心指令类型的业务指令的发送速度由高到低的顺序选取相应数量的时间点,作为发送时间点。
6.根据权利要求5所述的指令发送方法,其特征在于,所述发送策略包括:
以平均发送速度发送一次当日必发指令;
当接收到实体运营商反馈的超量信息时,停止发送并等待下一个发送时间点;
当未接收到实体运营商反馈的超量信息时,提高发送速度并发送下一次当日必发指令;
当当日必发指令完成发送后,发送实际可发指令;
发送业务指令时按照业务指令的优先级进行发送,业务指令的优先级由高到低的顺序为第一必发指令中所有的上一级指令、当日必发指令处理时段较短的业务指令、当日必发指令处理时段较长的业务指令、当日可发指令处理时段较短的业务指令,当日可发指令处理时段较长的业务指令。
7.根据权利要求6所述的指令发送方法,其特征在于,还包括,当业务指令发送失败时,按照预设的重发策略重新发送,所述重发策略包括:
若发送失败的业务指令为第一必发指令中所有的上一级指令,则在接收到实体运营商反馈的报错信息后,按照发送时间点重新发送,若发送时间点晚于最晚时间点,则不再重新发送,所述最晚时间点为所有发送时间点中最晚的发送时间点减去上一级指令的处理时长;
若发送失败的业务指令为第一必发指令,则在所有当日必发指令完成发送后,统一发送;
若发送失败的业务指令为第二必发指令,则从同指令类型的业务指令中选取同等数量的业务指令发送。
8.一种指令发送系统,其特征在于,包括:
指令获取模块(21),用于获取待发送指令池中所有待发送的业务指令,每个业务指令都有所属的指令类型,以及与指令类型对应的指令特征,每个业务指令的指令特征至少包括处理时段、上级关联关系和指令所属对象中的一个, 所述处理时段为实体运营商为每一类业务指令指定的办理时段,所述上级关联关系为两种指令类型先后顺序的关联性;
日期获取模块(22),用于获取当前日期;
数据获取模块(23),用于获取历史数据,所述历史数据包括每个指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度,所述发送速度为单位时间内发送的指令数量;
指令确定模块(24),用于根据所有指令类型的处理时段、当前日期和日发送上限值确定当日可发指令和当日必发指令,所述日发送上限值为实体运营商设定的每类业务指令一天可发送的数量上限;
所述指令确定模块(24)包括,
第一确定单元(241),用于根据所有指令类型的处理时段和当前日期确定第一必发指令;若所述第一必发指令中有指定指令类型的业务指令且上一级指令待发送,所述指定指令类型为具有上级关联关系的指令类型,所述上一级指令为与该业务指令为同一指令所属对象的具有上级关联关系的业务指令;则在确定上一级指令属于当日可发指令时,根据上一级指令的指令类型所对应的处理时长判断该业务指令是否能在当日完成处理,得到判断结果;根据判断结果调整第一必发指令的数量;若判断结果为上一级指令能在当日完成处理,则将该业务指令列为第一必发指令;若判断结果为上一级指令不能在当日完成处理,则将第一必发指令中与该上一级指令为同一指令所属对象的具有上级关联关系的业务指令从第一必发指令中删除;以及,
第二确定单元(242),用于根据所有指令类型的处理时段和当前日期确定当日可发指令;根据当日可发指令和第一必发指令确定实际可发指令中所有指令类型的指令数量,所述实际可发指令为当日可发指令中除第一必发指令的业务指令;根据当前日期和实际可发指令中所有指令类型的处理时段确定实际可发指令中所有指令类型的处理时限,所述处理时限为可发送每个指令类型的业务指令的剩余时长;根据实际可发指令中所有指令类型的指令数量、处理时限、日发送上限值确定第二必发指令;
时间点确定模块(25),用于根据当日必发指令的数量、历史数据中核心指令类型的业务指令每个月发送量最高的日期、对应的时间点,及该时间点的发送速度确定多个发送时间点和每个发送时间点的发送速度,所述核心指令类型为处理时段与当前日期最为接近的指令类型;
所述时间点确定模块(25)包括,
发送速度确定单元(251),用于根据历史数据中核心指令类型的业务指令每个月发送量最高的那天对应时间点的发送速度确定平均发送速度;以及,
时间点确定单元(252),用于根据当日必发指令的数量和平均发送速度确定发送时间点的数量;按照历史数据中每个月核心指令类型的业务指令的发送速度由高到低的顺序选取相应数量的时间点,作为发送时间点;
发送模块(26),用于在每个发送时间点按照预设的发送策略至少发送一批当日可发指令;所述发送策略包括,以平均发送速度发送一次当日必发指令;当接收到实体运营商反馈的超量信息时,停止发送并等待下一个发送时间点;当未接收到实体运营商反馈的超量信息时,提高发送速度并发送下一次当日必发指令;当当日必发指令完成发送后,发送实际可发指令;发送业务指令时按照业务指令的优先级进行发送,业务指令的优先级由高到低的顺序为第一必发指令中所有的上一级指令、当日必发指令处理时段较短的业务指令、当日必发指令处理时段较长的业务指令、当日可发指令处理时段较短的业务指令,当日可发指令处理时段较长的业务指令;以及,
重发模块(27),用于当业务指令发送失败时,按照预设的重发策略重新发送;所述重发策略包括,若发送失败的业务指令为第一必发指令中所有的上一级指令,则在接收到实体运营商反馈的报错信息后,按照发送时间点重新发送,若发送时间点晚于最晚时间点,则不再重新发送,所述最晚时间点为所有发送时间点中最晚的发送时间点减去上一级指令的处理时长;若发送失败的业务指令为第一必发指令,则在所有当日必发指令完成发送后,统一发送;若发送失败的业务指令为第二必发指令,则从同指令类型的业务指令中选取同等数量的业务指令发送。
9.一种智能终端,其特征在于,包括存储器和处理器,所述存储器上存储有能够被处理器加载并执行如权利要求1至7中任一种指令发送方法的计算机程序。
10.一种计算机可读存储介质,其特征在于,存储有能够被处理器加载并执行如权利要求1至7中任一种指令发送方法的计算机程序。
CN202310782115.XA 2023-06-29 2023-06-29 一种指令发送方法、系统、智能终端及存储介质 Active CN116545941B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310782115.XA CN116545941B (zh) 2023-06-29 2023-06-29 一种指令发送方法、系统、智能终端及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310782115.XA CN116545941B (zh) 2023-06-29 2023-06-29 一种指令发送方法、系统、智能终端及存储介质

Publications (2)

Publication Number Publication Date
CN116545941A true CN116545941A (zh) 2023-08-04
CN116545941B CN116545941B (zh) 2023-09-12

Family

ID=87443872

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310782115.XA Active CN116545941B (zh) 2023-06-29 2023-06-29 一种指令发送方法、系统、智能终端及存储介质

Country Status (1)

Country Link
CN (1) CN116545941B (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022127386A1 (zh) * 2020-12-17 2022-06-23 中兴通讯股份有限公司 状态迁移的方法、网络设备及存储介质
WO2022263610A1 (en) * 2021-06-18 2022-12-22 Canon Kabushiki Kaisha Low latency fairness management
JP2023004495A (ja) * 2021-06-26 2023-01-17 広海 大谷 インターネットを介したビジネスモデルの考案とセキュリティの強化方法の発明

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022127386A1 (zh) * 2020-12-17 2022-06-23 中兴通讯股份有限公司 状态迁移的方法、网络设备及存储介质
WO2022263610A1 (en) * 2021-06-18 2022-12-22 Canon Kabushiki Kaisha Low latency fairness management
JP2023004495A (ja) * 2021-06-26 2023-01-17 広海 大谷 インターネットを介したビジネスモデルの考案とセキュリティの強化方法の発明

Also Published As

Publication number Publication date
CN116545941B (zh) 2023-09-12

Similar Documents

Publication Publication Date Title
CN112882813B (zh) 任务调度方法、装置、系统及电子设备
US20150100655A1 (en) On-demand mailbox synchronization and migration system
US20150067028A1 (en) Message driven method and system for optimal management of dynamic production workflows in a distributed environment
US8862729B2 (en) Forecast-less service capacity management
KR101416280B1 (ko) 이벤트 처리 시스템 및 방법
US8069236B2 (en) Flow control of events based on threshold, grace period, and event signature
US20180255129A1 (en) Server load management for data migration
CN111275415A (zh) 资源通道的切换方法、装置、设备及存储介质
CN114567519B (zh) 一种多线程并行管理多个智能设备指令消息的方法及装置
CN114338534A (zh) 一种消息路由方法及装置
US11425084B2 (en) Data processing for multi-objective communication engagement
CN111182479B (zh) 信息发送的控制方法及装置
CN110532156B (zh) 一种容量预测方法及装置
CN110008187B (zh) 文件传输调度方法、装置、设备及计算机可读存储介质
CN111282263A (zh) 事件消息的处理方法、装置、电子设备及可读存储介质
CN114827280A (zh) 请求处理方法、装置、设备、介质
CN116545941B (zh) 一种指令发送方法、系统、智能终端及存储介质
CN112565391A (zh) 调整工业互联网平台中实例的方法、装置、设备和介质
CN111754218A (zh) 支付方式推荐方法和装置
US9300561B2 (en) Business intelligence-infused smart retransmission processing
US20180123866A1 (en) Method and apparatus for determining event level of monitoring result
CN114528109A (zh) 资源请求方法、装置和系统
CN109325859B (zh) 会员升级处理方法、系统及服务器
CN111192113A (zh) 订单处理方法、装置、设备及存储介质
US11972287B2 (en) Data transfer prioritization for services in a service chain

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant