CN111027954A - 基于etc系统的行程扣费方法、装置、计算机设备和介质 - Google Patents

Abstract

本申请公开了一种基于ETC系统的行程扣费方法、装置、计算机设备及可读存储介质。所述方法包括定时扫描订单数据库上的用户高速过关的支付订单状态，并根据所述支付订单状态将支付订单划分为成功订单和失败订单；获取所述失败订单的失败类型，并根据所述失败类型将所述失败订单划分为失败类型订单；获取每一类失败类型订单中失败订单的数量，作为失败数量，并根据失败订单的失败数量、失败类型对数据进行处理，得到补扣处理结果。本方法通过按照状态对支付订单进行分类，然后再对失败订单按照失败类型进行分类，并根据不同的失败类型按照不同的处理方式对失败订单进行批量处理，解决了现有技术中ETC系统订单处理效率低下的技术问题。

Description

基于ETC系统的行程扣费方法、装置、计算机设备和介质

技术领域

本申请涉及数据处理领域，特别是涉及一种基于ETC系统的行程扣费方法、装置、计算机设备和存储介质。

背景技术

目前的高速公路收费主要是基于ETC系统的收费，通过ETC车道系统的建设，可提高车辆在收费站的通行效率，减少排放，但车辆通行时仍要限速，在高峰时期仍会造成车辆拥堵。在计算车辆行程扣费时，现有技术中的行程扣费都是一对一扣费，每通过一辆车扣费一次，然后后台对一段时间内的订单批量支付订单进行批次处理，失败的支付订单也是按照原来的方式重启批量扣费操作，因为支付订单失败的类型多样，这样批量处理会造成扣费效率低下的问题。而且在对扣费失败后的订单处理上也是按照失败订单的顺序进行处理，而失败订单有不同的类型，对所有类型的失败订单都进行按照顺序批处理，会造成订单处理主次不当，降低ETC系统订单处理效率低下的问题。

发明内容

基于此，有必要针对上述技术问题，本申请提供一种基于ETC系统的行程扣费方法、装置、计算机设备及存储介质，以解决现有技术中无法对特征进行准确提取，导致的ETC系统处理支付订单时效率低下的技术问题。

一种基于ETC系统的行程扣费方法，所述方法包括：

定时扫描订单数据库上的用户高速过关的支付订单状态，并根据所述支付订单状态将支付订单划分为成功订单和失败订单；

获取所述失败订单的失败类型，并根据所述失败类型对所述失败订单进行分组，得到失败类型订单；

若所述失败类型订单的数量在第一预设数量内，则根据所述失败类型订单的失败类型对所述失败类型订单进行批量处理，得到第一补扣处理结果；

若所述失败类型订单的数量在第二预设数量内，则根据所述失败类型订单的失败类型生成支付告警，并将所述支付告警作为第二补扣处理结果；

若所述失败类型订单的数量在第三预设数量内，则合并所述失败类型订单为失败合并订单，并对所述失败合并订单进行批量处理，得到第三补扣处理结果。

进一步地，所述根据所述失败类型订单的失败类型对所述失败类型订单进行处理，得到补扣处理结果，包括：

若所述失败类型订单为余额不足订单，则生成余额告警指令，并根据所述预设告警指令向与所述余额不足订单对应的用户发送告警指示；

生成所述重启扣费指令，并定时根据所述重启扣费指令对所述余额不足订单进行批量处理；

当得到所述处理成功结果，则停止对所述余额不足订单进行批量处理，并将所述处理成功结果作为补扣处理结果。

进一步地，所述根据所述失败类型订单的失败类型对所述失败类型订单进行处理，得到补扣处理结果，包括：

若所述失败类型订单为网络拥堵订单，则生成重启扣费指令，并根据所述重启扣费指令对所述网络拥堵订单进行批量处理，得到处理成功结果，作为补扣处理结果。

进一步地，所述获取所述失败订单的失败类型，并根据所述失败类型将所述失败订单划分为失败类型订单，包括：

获取所述失败订单的支付订单状态，从所述支付订单状态获取所述失败订单的失败类型,并按照所述失败类型对所述失败订单进行标记，并将标记后的失败订单作为失败类型订单。

一种基于ETC系统的行程扣费装置，所述装置包括：

订单划分模块，用于定时扫描订单数据库上的用户高速过关的支付订单状态，并根据所述支付订单状态将支付订单划分为成功订单和失败订单；

类型划分模块，用于获取所述失败订单的失败类型，并根据所述失败类型对所述失败订单进行分组，得到失败类型订单；

第一按类处理模块，用于若所述失败类型订单的数量在第一预设数量内，则根据所述失败类型订单的失败类型对所述失败类型订单进行批量处理，得到补扣处理结果；

第二按类处理模块，用于若所述失败类型订单的数量在第二预设数量内，则根据所述失败类型订单的失败类型生成支付告警，并将所述支付告警作为第二补扣处理结果；

第三按类处理模块，用于若所述失败类型订单的数量在第三预设数量内，则合并所述失败类型订单为失败合并订单，并对所述失败合并订单进行批量处理，得到第三补扣处理结果。

进一步地，还包括：

告警子模块，用于若所述失败类型订单为余额不足订单，则生成余额告警指令，并根据所述预设告警指令向与所述余额不足订单对应的用户发送告警指示；

定时子模块，用于生成所述重启扣费指令，并定时根据所述重启扣费指令对所述余额不足订单进行批量处理；

补扣子模块，用于当得到所述处理成功结果，则停止对所述余额不足订单进行批量处理，并将所述处理成功结果作为补扣处理结果。

一种计算机设备，包括存储器和处理器，以及存储在所述存储器中并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述基于ETC系统的行程扣费方法的步骤。

一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序被处理器执行时实现上述基于ETC系统的行程扣费方法的步骤。

上述基于ETC系统的行程扣费方法、装置、计算机设备和存储介质，通过定时扫描支付订单的状态，按照状态对支付订单进行分类，然后再对失败订单按照失败类型进行分类，并根据不同的失败类型按照不同的处理方式对失败订单进行处理，无需按照原来的方式依次顺序处理，解决了现有技术中对所有类型的失败订单都进行按照顺序批处理，造成的ETC系统订单处理效率低下的技术问题。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对本发明实施例的描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为基于ETC系统的行程扣费方法的应用环境示意图；

图2为基于ETC系统的行程扣费方法的流程示意图；

图3为基于ETC系统的行程扣费装置的示意图；

图4为一个实施例中计算机设备的示意图。

具体实施方式

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同；本文中在申请的说明书中所使用的术语只是为了描述具体的实施例的目的，不是旨在于限制本申请；本申请的说明书和权利要求书及上述附图说明中的术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。本申请的说明书和权利要求书或上述附图中的术语“第一”、“第二”等是用于区别不同对象，而不是用于描述特定顺序。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

为了使本申请的目的、技术方案及优点更加清楚明白，下面结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明实施例提供的基于ETC系统的行程扣费方法，可以应用于如图1所示的应用环境中。其中，该应用环境可以包括终端102、网络106以及服务端104，网络106用于在终端102和服务端104之间提供通信链路介质，网络106可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

用户可以使用终端102通过网络106与服务端104交互，以接收或发送消息等。终端102上可以安装有各种通讯客户端应用，例如网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端102可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能手机、平板电脑、电子书阅读器、MP3播放器(Moving Picture Experts Group AudioLayer III，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts GroupAudio Layer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。

服务端104可以是提供各种服务的服务器，例如对终端102上显示的页面提供支持的后台服务器。

需要说明的是，本申请实施例所提供的基于ETC系统的行程扣费方法一般由服务端/终端执行，相应地，基于ETC系统的行程扣费装置一般设置于服务端/终端设备中。

应该理解，图1中的终端、网络和服务端的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

其中，终端102通过网络与服务端104进行通信。服务端104向终端102发送扣费指令后，终端102通过第三方账户系统对服务端104的验证通过之后，服务端104就会对该支付订单进行处理，然后根据支付处理状态对处理后的支付订单进行分类，而后再对不同类型的失败订单进行分布式处理，得到最终的补扣处理结果。其中，终端102和服务端104之间通过网络进行连接，该网络可以是有线网络或者无线网络，终端102可以但不限于是各种个人计算机、笔记本电脑、智能手机、平板电脑和便携式可穿戴设备，服务端104可以用独立的服务器或者是多个组成的服务器集群来实现。

在一个实施例中，如图2所示，提供了一种基于ETC系统的行程扣费方法，以该方法应用于图1中的服务端为例进行说明，包括以下步骤：

步骤202，定时扫描订单数据库上的用户高速过关的支付订单状态，并根据所述支付订单状态将支付订单划分为成功订单和失败订单。

成功订单可以是支付订单已经完成的订单，失败订单是未正常完成的订单，比如在支付期间出现了异常的订单。

可选地，还可以根据支付订单状态将支付订单划分为未完成订单，未完成订单是已经创建了订单但是尚未进行支付操作或尚未生成支付操作结果的订单，此处对未完成订单的处理不做过多解释。

本实施例中，用户开车行驶在高速公路上的时间、距离、以及通过收费关口的订单号、订单金额等也会被保存在服务端上的数据路中作为行程信息保存。具体地，行程信息可以包括入口收费站名称、出口收费站名称、距离、入闸时间、出闸时间、订单号、订单金额、优惠金额、支付金额、扣款时间以及订单支付状态等。而上述的行程信息中也包括用户高速通关的支付订单状态。

支付订单状态是用户在通过高速关口时通过ETC系统进行高速扣费的支付订单的状态信息，可以是支付成功、支付失败。当用户通过关口时，ETC系统对高速系统提供消息通知接口，高速系统收到用户过关的过关信息时，通过消息通知接口将用户的过关信息发送到ETC系统，ETC系统将用户的过关信息发送给用户进行验证，验证通过后进行支付操作，最后结合支付订单的信息生成行程信息发送保存到数据库，用户可以通过第三方平台对该行程信息进行查看。

步骤204，获取所述失败订单的失败类型，并根据所述失败类型对所述失败订单进行分组，得到失败类型订单。

失败订单的失败类型有多种，可以通过调用请求状态接口的状态值获取失败订单的失败类型。请求状态接口是应用程序接口中的一种接口，所述应用程序接口(Application Programming Interface，API)是一些预先定义的函数，根据这些函数可以进行网络应用程序的开发，不需要访问源码以及理解内部的工作机制细节。

示例性的，若支付订单的请求状态接口的返回值为成功(success)，确定所述支付订单的状态为支付完成状态。当请求状态接口的返回值为失败时，确定支付订单的状态为支付失败状态。进一步地，当支付订单为失败订单时，一般返回值中会携带表示失败订单的失败类型的数据，比如因为网络拥堵造成的支付失败、因余额不足(信用卡透支等造成的余额不足情况)造成的余额不足的支付失败等等情况。在确定失败订单后也会从返回值中获取这些失败类型的数据。然后根据该失败类型的数据对失败订单进行分类，分类后的失败订单可以包括：网络拥堵订单、余额不足订单等，将网络拥堵订单、余额不足订单作为失败类型订单。

步骤206，若所述失败类型订单的数量在第一预设数量内，则根据所述失败类型订单的失败类型对所述失败类型订单进行处理，得到第一补扣处理结果。

获取一段时间中失败订单的数量，若某一类型的失败订单的数量在预设数量内，比如大于20而小于50，则可以按照失败订单的失败类型对该失败订单进行异步批量处理。不同类型的失败订单可以同时异步进行上述操作，提高了数据处理效率。

步骤208，若所述失败类型订单的数量在第二预设数量内，则根据所述失败类型订单的失败类型生成支付告警，并将所述支付告警作为第二补扣处理结果。若所述失败类型订单的数量在第二预设数量内，比如大于50，则根据所述失败类型订单的失败类型生成支付告警，并将支付告警作为第二补扣处理结果。比如，若某一类型的失败订单的数量不在预设数量内，比如大于50，则服务端可能会生成告警指令，对该段时间内的支付订单以及系统进行排查，看是否是系统本身出现异常，然后根据找出的异常提醒工作人员进行修理，也可以提示失败订单的数量异常，然后提醒工作人员进行相应排查操作。

步骤210，若所述失败类型订单的数量在第三预设数量内，则合并所述失败类型订单为失败合并订单，并对所述失败合并订单进行批量处理，得到第三补扣处理结果。若所述失败类型订单的数量在第三预设数量内，比如大于0个订单但是少于20个订单时。则可以将这些数量少于20的失败订单合并起来进行批量处理，得到补扣处理结果。比如，若得到某几类型的失败订单的数量都不在第三预设数量内，比如它们的数量都小于20，且合并后数量也在第三预设数量内，则可以按照可以将数量低于20的失败类型订单结合起来一起批量进行处理，即按照对同一时间段内的失败订单按照顺序进行处理，可以节省创建新进程的内存，提升服务器的处理效率。

上述的第一补扣处理结果、第二补扣处理结果以及第三补扣处理结果中可以包括对不同类型订单的不同处理结果。比如第一补扣处理结果、第二补扣处理结果以及第三补扣处理结果中都可以包括对网络拥堵订单或者余额不足订单的处理结果，只不过第二补扣处理结果中的对网络拥堵订单的处理结果都是支付警告，用于表示在出现大量支付失败订单时可能出现的服务端上系统逻辑异常的问题。

而第一补扣处理结果以及第二补扣处理结果中不论是对哪一种数量的网络拥堵订单的处理都是正常的重启处理结果，其中可能包括重启处理后支付失败或者支付成功的情况。若支付依旧是失败，则可以重新判断该失败订单的失败类型，再进行后续的处理，以保证按类型对失败类型订单进行处理，提高服务端对订单处理的效率。本实施例提供的基于ETC系统的行程扣费方法，通过定时扫描支付订单的状态，按照状态对支付订单进行分类，然后再对失败订单按照失败类型进行分类，并根据不同的失败类型按照不同的处理方式对失败订单进行处理，无需对所有的失败订单都按照原来的方式依次顺序处理，解决了现有技术中对所有类型的失败订单都进行按照顺序批处理，造成的ETC系统订单处理效率低下的技术问题。

在一个实施例中，步骤204，包括：

获取失败订单的支付订单状态，并按照支付订单状态对失败订单进行标记，并将标记后的失败订单作为失败类型订单。

具体地，查看请求状态接口的返回值，若请求状态接口的返回值为失败，确定支付订单为未完成状态，若返回值中的异常提醒信息为网络拥堵，则可以确认该失败订单的失败类型为：网络拥堵订单；若返回值的异常提醒信息为余额不足，则可以确认该失败订单的失败类型为：余额不足订单。然后根据失败类型对失败订单进行划分。若某一失败类型订单的数量太多，而又确定系统无异常，则可以对该超出预设数量的失败订单进行分批处理操作。

其中，分批处理可以采用定量分批处理，定量分批处理是分批处理的一种处理方式，定量分批处理是根据预设数量对失败订单的支付订单进行处理。

本实施例中，支付订单的请求状态接口的返回值可以包括成功或失败，其中，成功表示支付订单为支付完成状态，失败表示支付订单为支付未完成状态。

本实施例通过对失败订单进行标记，然后根据不同失败订单的数量的不同而进行不同的操作处理，在多方面进行异常排查和处理，可以提高数据处理的效率。

在一个实施例中，步骤206，包括：

若所述失败类型订单为网络拥堵订单，则生成重启扣费指令，并根据所述重启扣费指令对所述网络拥堵订单进行批量处理，得到处理成功结果，作为第一补扣处理结果。

进一步地，还包括：

若所述失败类型订单为余额不足订单，则生成余额告警指令，并根据所述预设告警指令向与所述余额不足订单对应的用户发送告警指示，生成所述重启扣费指令，并定时根据所述重启扣费指令对所述余额不足订单进行批量处理。

余额告警指令用于提醒用户账户余额不足，然后调用请求状态接口定时对该失败订单进行处理，并生成处理成功结果。当得到所述处理成功结果，则停止对所述余额不足订单进行批量处理，并将所述处理成功结果作为第一补扣处理结果。

本实施例中通过对不同失败订单执行不同的处理指令，解决了现有技术中对所有类型的失败订单都进行按照顺序批处理，造成的ETC系统订单处理效率低下的技术问题。

进一步地，步骤210，包括：

获取所述失败类型订单在第三预设数量内的失败订单，作为合并待处理订单。合并所述合并待处理订单，并对所述合并待处理订单进行批量处理，得到所述第三补扣处理结果。若出现大于1个的失败类型的失败订单的数量在第三预设数量内，则可以不用将这些订单分开处理，而是合并起来按照顺序依次进行处理。

通过本实施例可以节省创建新进程的内存，提升服务器的处理效率。

应该理解的是，虽然图2的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

在一个实施例中，如图3所示，提供了一种基于ETC系统的行程扣费装置，该基于ETC系统的行程扣费装置与上述实施例中基于ETC系统的行程扣费方法一一对应。该基于ETC系统的行程扣费装置包括：

订单划分模块302，用于定时扫描订单数据库上的用户高速过关的支付订单状态，并根据所述支付订单状态将支付订单划分为成功订单和失败订单。

类型划分模块304，用于获取所述失败订单的失败类型，并根据所述失败类型对所述失败订单进行分组，得到失败类型订单。

第一按类处理模块306，用于若所述失败类型订单的数量在第一预设数量内，则根据所述失败类型订单的失败类型对所述失败类型订单进行批量处理，得到第一补扣处理结果；

第二按类处理模块308，用于若所述失败类型订单的数量在第二预设数量内，则根据所述失败类型订单的失败类型生成支付告警，并将所述支付告警作为第二补扣处理结果。

第三按类处理模块310，用于若所述失败类型订单的数量在第三预设数量内，则合并所述失败类型订单为失败合并订单，并对所述失败合并订单进行批量处理，得到第三补扣处理结果。

进一步地，第一按类处理模块306，包括：

告警子模块，用于若所述失败类型订单为余额不足订单，则生成余额告警指令，并根据所述预设告警指令向与所述余额不足订单对应的用户发送告警指示；

定时子模块，用于生成所述重启扣费指令，并定时根据所述重启扣费指令对所述余额不足订单进行批量处理；

补扣子模块，用于当得到所述处理成功结果，则停止对所述余额不足订单进行批量处理，并将所述处理成功结果作为第一补扣处理结果。

进一步地，订单划分模块302，包括：

状态确认子模块，用于获取支付订单的请求状态接口的状态值，并将所述状态值作为所述支付订单状态。

进一步地，类型划分模块304，包括：

类型获取子模块，用于获取所述失败订单的支付订单状态，从所述支付订单状态获取所述失败订单的失败类型。

进一步地，类型划分模块304，还包括：

分组标记子模块，用于按照所述失败类型对所述失败订单进行标记分组，得到失败类型订单。

进一步地，第一按类处理模块306，还包括：

定时处理子模块，用于若所述失败类型订单为网络拥堵订单，则生成重启扣费指令，并根据所述重启扣费指令对所述网络拥堵订单进行批量处理，得到处理成功结果，作为第一补扣处理结果。

上述基于ETC系统的行程扣费装置，通过定时扫描支付订单的状态，按照状态对支付订单进行分类，然后再对失败订单按照失败类型进行分类，并根据不同的失败类型按照不同的处理方式对因网络拥堵等造成的支付失败的失败订单进行异步批量处理，无需按照原来的方式依次顺序处理，解决了现有技术中对所有类型的失败订单都进行按照顺序批处理，造成的ETC系统订单处理效率低下的技术问题。

在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图4所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储用户订单数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种基于ETC系统的行程扣费方法。

其中，本技术领域技术人员可以理解，这里的计算机设备是一种能够按照事先设定或存储的指令，自动进行数值计算和/或信息处理的设备，其硬件包括但不限于微处理器、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程门阵列(Field－Programmable Gate Array，FPGA)、数字处理器(Digital Signal Processor，DSP)、嵌入式设备等。

本领域技术人员可以理解，图4中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现上述实施例中基于ETC系统的行程扣费方法的步骤，例如图2所示的步骤202至步骤210，或者，处理器执行计算机程序时实现上述实施例中基于ETC系统的行程扣费装置的各模块/单元的功能，例如图3所示模块302至模块310的功能。为避免重复，此处不再赘述。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述实施例中基于ETC系统的行程扣费方法的步骤，例如图2所示的步骤202至步骤210，或者，处理器执行计算机程序时实现上述实施例中基于ETC系统的行程扣费装置的各模块/单元的功能，例如图3所示模块302至模块310的功能。为避免重复，此处不再赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，仅以上述各功能单元、模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能单元、模块完成，即将所述装置的内部结构划分成不同的功能单元或模块，以完成以上描述的全部或者部分功能。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形、改进或者对部分技术特征进行等同替换，而这些修改或者替换，并不使相同技术方案的本质脱离本发明个实施例技术方案地精神和范畴，都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种基于ETC系统的行程扣费方法，其特征在于，所述方法包括：

定时扫描订单数据库上的用户高速过关的支付订单状态，并根据所述支付订单状态将支付订单划分为成功订单和失败订单；

获取所述失败订单的失败类型，并根据所述失败类型对所述失败订单进行分组，得到失败类型订单；

若所述失败类型订单的数量在第一预设数量内，则根据所述失败类型订单的失败类型对所述失败类型订单进行处理，得到第一补扣处理结果；

若所述失败类型订单的数量在第二预设数量内，则根据所述失败类型订单的失败类型生成支付告警，并将所述支付告警作为第二补扣处理结果；

若所述失败类型订单的数量在第三预设数量内，则合并所述失败类型订单为失败合并订单，并对所述失败合并订单进行批量处理，得到第三补扣处理结果。

2.根据权利要求1所述的方法，其特征在于，所述定时扫描用户高速过关的支付订单状态，包括：

获取支付订单的请求状态接口的状态值，并将所述状态值作为所述支付订单状态。

3.根据权利要求1所述的方法，其特征在于，所述获取所述失败订单的失败类型，包括：

获取所述失败订单的支付订单状态，并从所述支付订单状态获取所述失败订单的失败类型。

4.根据权利要求3所述的方法，其特征在于，所述根据所述失败类型对所述失败订单进行分组，得到失败类型订单包括：

按照所述失败类型对所述失败订单进行标记分组，得到所述失败类型订单。

5.根据权利要求1所述的方法，其特征在于，所述若所述失败类型订单的数量在第一预设数量内，则根据所述失败类型订单的失败类型对所述失败类型订单进行处理，得到第一补扣处理结果，包括：

若所述失败类型订单为网络拥堵订单，则生成重启扣费指令，并根据所述重启扣费指令对所述网络拥堵订单进行批量处理，得到处理成功结果，作为所述第一补扣处理结果。

6.根据权利要求1所述的方法，其特征在于，所述若所述失败类型订单的数量在第一预设数量内，则根据所述失败类型订单的失败类型对所述失败类型订单进行处理，得到第一补扣处理结果，包括：

若所述失败类型订单为余额不足订单，则生成余额告警指令，并根据所述预设告警指令向与所述余额不足订单对应的用户发送告警指示；

生成所述重启扣费指令，并定时根据所述重启扣费指令对所述余额不足订单进行批量处理；

当得到所述处理成功结果，则停止对所述余额不足订单进行批量处理，并将所述处理成功结果作为所述第一补扣处理结果。

7.根据权利要求1所述的方法，其特征在于，所述若所述失败类型订单的数量在第三预设数量内，则合并所述失败类型订单为失败合并订单，并对所述失败合并订单进行批量处理，得到第三补扣处理结果，包括：

获取所述失败类型订单在第三预设数量内的失败订单，作为合并待处理订单；

合并所述合并待处理订单，并对所述合并待处理订单进行批量处理，得到所述第三补扣处理结果。

8.一种基于ETC系统的行程扣费装置，其特征在于，包括：

订单划分模块，用于定时扫描订单数据库上的用户高速过关的支付订单状态，并根据所述支付订单状态将支付订单划分为成功订单和失败订单；

类型划分模块，用于获取所述失败订单的失败类型，并根据所述失败类型对所述失败订单进行分组，得到失败类型订单；

按类处理模块，用于若所述失败类型订单的数量在第一预设数量内，则根据所述失败类型订单的失败类型对所述失败类型订单进行处理，得到第一补扣处理结果；

第二按类处理模块，用于若所述失败类型订单的数量在第二预设数量内，则根据所述失败类型订单的失败类型生成支付告警，并将所述支付告警作为第二补扣处理结果；

第三按类处理模块，用于若所述失败类型订单的数量在第三预设数量内，则合并所述失败类型订单为失败合并订单，并对所述失败合并订单进行批量处理，得到第三补扣处理结果。

9.一种计算机设备，包括存储器和处理器，所述存储器存储有计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法的步骤。

Images