CN110060124A - 订单处理方法、装置、存储介质及电子设备 - Google Patents
订单处理方法、装置、存储介质及电子设备 Download PDFInfo
- Publication number
- CN110060124A CN110060124A CN201910285914.XA CN201910285914A CN110060124A CN 110060124 A CN110060124 A CN 110060124A CN 201910285914 A CN201910285914 A CN 201910285914A CN 110060124 A CN110060124 A CN 110060124A
- Authority
- CN
- China
- Prior art keywords
- supply system
- order
- ticketing service
- service supply
- order information
- 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.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
- G06Q30/0635—Processing of requisition or of purchase orders
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Strategic Management (AREA)
- General Business, Economics & Management (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本公开涉及一种订单处理方法、装置、存储介质及电子设备,以在票务供应系统的接口由异常恢复为正常后,避免用户重复发送订单请求,提高订单处理效率。该订单处理方法包括:确定票务供应系统的接口异常;将用于向所述票务供应系统发起请求的订单信息保存到收单缓存中;如果所述票务供应系统的接口恢复正常,则根据所述收单缓存中的订单信息向所述票务供应系统发送请求。
Description
技术领域
本公开涉及数据处理技术领域,具体地,涉及一种订单处理方法、装置、存储介质及电子设备。
背景技术
随着计算机技术的不断发展,越来越多的人选择网上购票。但是,人们在进行网上购票时,票务供应系统可能出现系统不稳定或者高峰期购票异常的问题。相关技术中,为了应对票务供应系统出现的上述问题,通常会在监测到票务供应系统出现异常时,控制用户提交的订单交易失败,或者停止票务售卖。因此,当票务供应系统恢复正常时,需要重新向票务供应系统发送订单请求。
发明内容
本公开的目的是提供一种订单处理方法、装置、存储介质及电子设备,以避免用户重复发送订单请求,提高订单处理效率。
为了实现上述目的,第一方面,本公开提供一种订单处理方法,包括:
确定票务供应系统的接口异常;
将用于向所述票务供应系统发起请求的订单信息保存到收单缓存中;
如果所述票务供应系统的接口恢复正常,则根据所述收单缓存中的订单信息向所述票务供应系统发送请求。
可选地,所述方法还包括:
向所述票务供应系统发送模拟的订单请求;
如果所述票务供应系统对所述模拟的订单请求的响应满足预设条件,则确定所述票务供应系统的接口恢复正常。
可选地,所述预设条件包括:
所述票务供应系统连续预设次数对所述模拟的订单请求的响应为成功;或者,
所述票务供应系统对所述模拟的订单请求的响应为失败,且失败类型非接口异常类型。
可选地,所述根据所述收单缓存中的订单信息向所述票务供应系统发送请求,包括:
确定所述收单缓存中的订单信息的订单状态,其中,每一所述订单信息的订单状态为未下单状态或未支付状态;
根据所述订单状态,针对每一所述订单信息向所述票务供应系统发送下单请求或支付请求。
可选地,所述根据所述收单缓存中的订单信息向所述票务供应系统发送请求,包括:
对于所述收单缓存中的处于未下单状态的订单信息,向所述票务供应系统的下单接口发送下单请求;
如果接收到所述票务供应系统发送的下单成功响应,则向所述票务供应系统的支付接口发送支付请求;
如果在所述票务供应系统响应所述支付请求之前,所述票务供应系统再次发生接口异常,则再次保存所述订单信息到所述收单缓存中,并将所述订单信息标记为未支付状态。
可选地,所述票务供应系统支持幂等校验,所述根据所述收单缓存中的订单信息向所述票务供应系统发送请求,包括:
判断所述收单缓存中是否存在具有同一订单号且处于不同订单状态的多个订单信息;
如果所述收单缓存中存在处于未下单状态的第一订单信息以及处于未支付状态的第二订单信息,则根据所述未下单状态的第一订单信息向所述票务供应系统的下单接口发送请求,其中,所述第一订单信息和所述第二订单信息具有相同订单号;
在下单成功后,根据未支付状态的所述第二订单信息向所述票务供应系统的支付接口发送请求。
可选地,所述方法还包括:
如果所述票务供应系统对订单信息的响应为成功,则删除所述收单缓存中的所述订单信息;或者
如果超过预设时长未收到所述票务供应系统对订单信息的响应,则删除所述收单缓存中的所述订单信息。
第二方面,本公开还提供一种订单处理装置,所述装置包括:
确定模块,用于确定票务供应系统的接口异常;
保存模块,用于将用于向所述票务供应系统发起请求的订单信息保存到收单缓存中;
发送模块,用于当所述票务供应系统的接口恢复正常时,根据所述收单缓存中的订单信息向所述票务供应系统发送请求。
可选地,所述装置还包括:
请求发送模块,用于向所述票务供应系统发送模拟的订单请求;
接口确定模块,用于当所述票务供应系统对所述模拟的订单请求的响应满足预设条件时,确定所述票务供应系统的接口恢复正常。
可选地,所述预设条件包括:
所述票务供应系统连续预设次数对所述模拟的订单请求的响应为成功;或者,
所述票务供应系统对所述模拟的订单请求的响应为失败,且失败类型非接口异常类型。
可选地,所述发送模块用于:
确定所述收单缓存中的订单信息的订单状态,其中,每一所述订单信息的订单状态为未下单状态或未支付状态;
根据所述订单状态,针对每一所述订单信息向所述票务供应系统发送下单请求或支付请求。
可选地,所述发送模块用于:
对于所述收单缓存中的处于未下单状态的订单信息,向所述票务供应系统的下单接口发送下单请求;
如果接收到所述票务供应系统发送的下单成功响应,则向所述票务供应系统的支付接口发送支付请求;
如果在所述票务供应系统响应所述支付请求之前,所述票务供应系统再次发生接口异常,则再次保存所述订单信息到所述收单缓存中,并将所述订单信息标记为未支付状态。
可选地,所述票务供应系统支持幂等校验,所述发送模块用于:
判断所述收单缓存中是否存在具有同一订单号且处于不同订单状态的多个订单信息;
如果所述收单缓存中存在处于未下单状态的第一订单信息以及处于未支付状态的第二订单信息,则根据所述未下单状态的第一订单信息向所述票务供应系统的下单接口发送请求,其中,所述第一订单信息和所述第二订单信息具有相同订单号;
在下单成功后,根据未支付状态的所述第二订单信息向所述票务供应系统的支付接口发送请求。
可选地,所述装置还包括:
第一删除模块,用于当所述票务供应系统对订单信息的响应为成功时,删除所述收单缓存中的所述订单信息;或者
第二删除模块,用于当超过预设时长未收到所述票务供应系统对订单信息的响应时,删除所述收单缓存中的所述订单信息。
第三方面,本公开还提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现第一方面中任一项所述方法的步骤。
第四方面,本公开还提供一种电子设备,包括:
存储器,其上存储有计算机程序;
处理器,用于执行所述存储器中的所述计算机程序,以实现第一方面中任一项所述方法的步骤。
通过上述技术方案,当票务供应系统的接口发生异常时,用户的订单信息可以被保存到收单缓存中,然后当票务供应系统的接口恢复正常时可以根据收单缓存中的订单信息继续向票务供应系统发送订单请求,相较于相关技术中直接控制用户订单交易失败或停止售卖的方式,本公开的方法无需用户重复发起订单请求,可以提高订单处理效率。
本公开的其他特征和优点将在随后的具体实施方式部分予以详细说明。
附图说明
附图是用来提供对本公开的进一步理解,并且构成说明书的一部分,与下面的具体实施方式一起用于解释本公开,但并不构成对本公开的限制。在附图中:
图1是根据本公开一示例性实施例示出的订单处理方法的应用场景示意图;
图2是根据本公开一示例性实施例示出的一种订单处理方法的流程图;
图3是根据本公开另一示例性实施例示出的一种订单处理方法的流程图;
图4是根据本公开一示例性实施例示出的一种订单处理装置的框图;
图5是根据本公开一示例性实施例示出的一种电子设备的框图。
具体实施方式
以下结合附图对本公开的具体实施方式进行详细说明。应当理解的是,此处所描述的具体实施方式仅用于说明和解释本公开,并不用于限制本公开。
随着计算机技术的不断发展,越来越多的人选择网上购票。但是,人们在进行网上购票时,票务供应系统可能出现系统不稳定或者高峰期购票异常的问题。相关技术中,为了应对票务供应系统出现的上述问题,通常会在监测到票务供应系统出现异常时,控制用户提交的订单交易失败,或者停止票务售卖。因此,当票务供应系统恢复正常时,需要重新向票务供应系统发送订单请求。
为了解决上述问题,本公开提供一种订单处理方法、装置、存储介质及电子设备,以避免用户重复发送订单请求,提高订单处理效率。
首先说明本公开实施例的应用场景。参照图1,本公开实施例中的订单处理方法可以应用于第三方票务系统101(图1中以第三方票务系统为服务器进行示意)。其中,第三方票务系统101可以接收用户终端102(图1中以用户终端为手机进行示意)发送的订单请求,并将该订单请求发送给票务供应系统103(图1中以票务供应系统为服务器进行示意),从而完成对用户发起的订单请求的处理。应当理解的是,图1仅是对本公开提供的订单处理方法的应用场景的举例性说明,并不用于限制本公开。
下面对本公开以图1所示的应用场景为例对本公开实施例中的订单处理方法进行说明。
图2是根据本公开一示例性实施例示出的一种订单处理方法的流程图。参照图2,该订单处理方法可以包括:
步骤S201,确定票务供应系统的接口异常。
示例地,可以在检测到以下任一种情况时,确定票务供应系统的接口异常:票务供应系统的接口链接超时、从票务供应系统的接口读取数据超时、对从票务供应系统的接口获取的数据解析异常,等等,本公开实施例对此不作限定。
步骤S202,将用于向票务供应系统发起请求的订单信息保存到收单缓存中。
也即是说,在本公开实施例中,收单缓存用于在票务供应系统的接口异常时保存订单信息,比如,收单缓存可以通过队列的形式保存订单信息,或者也可以通过数组的形式保存订单信息,等等,本公开实施例对此不作限定。
步骤S203,如果所述票务供应系统的接口恢复正常,则根据所述收单缓存中的订单信息向所述票务供应系统发送请求。
通过上述方式,当票务供应系统的接口发生异常时,用户的订单信息可以被保存到收单缓存中,然后当票务供应系统的接口恢复正常时可以根据收单缓存中的订单信息继续向票务供应系统发送订单请求,无需用户重复发起订单请求,从而可以提高订单处理效率。
在一种可能的方式下,本公开实施例还可以向票务供应系统发送模拟的订单请求,如果票务供应系统对模拟的订单请求的响应满足预设条件,则确定票务供应系统的接口恢复正常。
示例地,向票务供应系统发送模拟的订单请求可以是不间断地连续发送,也可以是周期性发送,比如每间隔一分钟向票务供应系统发送一次模拟的订单请求,等等,本公开实施例对此不作限定。
在一种可能的方式下,预设条件可以包括票务供应系统连续预设次数对模拟的订单请求的响应为成功;或者,票务供应系统对模拟的订单请求的响应为失败,且失败类型非接口异常类型。
示例地,预设次数可以根据实际情况设定,等等,本公开实施例对此不作限定。比如,根据实际情况可以设定预设次数为六次,那么当票务供应系统连续六次对模拟的订单请求的响应为成功时,则可以确定票务供应系统的接口恢复正常。
又或者,在其他可能的情况下,如果模拟的订单请求不满足票务供应系统的购票要求,那么票务供应系统对该模拟的订单请求响应则为失败,此种失败不是由于票务供应系统的接口异常而导致的,即失败类型非接口异常类型,从而可以确定票务供应系统的接口恢复正常。
应当理解的是,在本公开实施例中,可以当存在一次票务供应系统对模拟的订单请求的响应为失败,且失败类型为非接口异常类型时,确定票务供应系统的接口恢复正常。又或者,为了提高判断结果的准确性,也可以当存在多次票务供应系统对模拟的订单请求的响应为失败,且失败类型为非接口异常类型时,确定票务供应系统的接口恢复正常,本公开实施例对此不作限定。
通过上述方式,如果票务供应系统的接口异常,在将订单信息保存到收单缓存中的同时,可以向票务供应系统发送模拟的订单请求,然后可以根据票务供应系统对于模拟的订单请求的响应结果,确定票务供应系统的接口是否恢复正常,从而可以自动检测票务供应系统的接口是否恢复正常,便于在接口恢复正常时及时根据收单缓存中的订单信息向票务供应系统发送请求,进一步提高订单处理效率。
在一种可能的方式中,在步骤S203中还可以先确定收单缓存中的订单信息的订单状态,其中,每一订单信息的订单状态为未下单状态或未支付状态,然后根据订单状态,针对每一订单信息向票务供应系统发送下单请求或支付请求。
在用户终端通过第三方票务系统进行网上购票时,每一订单存在下单阶段和支付阶段。其中,下单阶段指的是用户终端向第三方票务系统发送下单请求到该用户终端接收到第三方票务系统发送的下单响应消息的阶段。支付阶段指的是用户终端在接收到第三方票务系统发送的表征下单成功的响应消息后,向第三方票务系统发送支付请求到该用户终端接收到第三方票务系统发送的支付响应消息的阶段。
如果在下单阶段,票务供应系统的接口发生异常,即用户下单未成功,那么向票务供应系统发起请求的订单信息对应的订单状态则为未下单状态。如果在支付阶段,票务供应系统的接口发生异常,即用户下单成功但支付未成功,那么向票务供应系统发起请求的订单信息对应的订单状态则为未支付状态。
在确定订单信息的订单状态之后,可以根据该订单状态状态,针对每一订单信息向票务供应系统发送下单请求或支付请求。
在一种可能的情况下,如果是仅在下单阶段被保存到收单缓存中的订单信息(即订单状态为未下单状态的订单信息),则可以当票务供应系统的接口恢复正常时,向票务供应系统的下单接口发送下单请求。应当理解的是,如果未收到票务供应系统发送的下单成功响应,那么可以向用户终端返回表征下单失败的消息。
在另一种可能的情况下,如果是仅在支付阶段被保存到收单缓存中的订单信息(即订单状态为未支付状态的订单信息),则可以当票务供应系统的接口恢复正常时,向票务供应系统的支付接口发送支付请求。应当理解的是,如果未收到票务供应系统发送的下单成功响应,那么可以向用户终端返回表征支付失败的消息。
在另一种可能的情况下,当票务供应系统出现重复的系统不稳定时,可能出现在下单阶段和支付阶段均被保存到收单缓存中的订单信息。针对此种情况,可以先对于收单缓存中的处于未下单状态的订单信息,向票务供应系统的下单接口发送下单请求。如果接收到票务供应系统发送的下单成功响应,则向票务供应系统的支付接口发送支付请求。如果在票务供应系统响应支付请求之前,票务供应系统再次发生接口异常,则再次保存该订单信息到收单缓存中,并将该订单信息标记为未支付状态。
也即是说,对于在下单阶段和支付阶段均被保存到收单缓存中的订单信息,在进行订单信息的释放(根据收单缓存中的订单信息向票务供应系统发送请求)时,可以是根据订单状态进行释放的。具体地,可以是先释放收单缓存中处于未下单状态的订单信息。然后在该未下单状态的订单信息释放成功后,再释放处于未支付状态的订单信息。
并且,如果在释放处于未支付状态的订单信息的过程中(在票务供应系统响应支付请求之前),票务供应系统再次发生接口异常,则可以将该订单信息标记为未支付状态再次保存到收单缓存中,那么当票务供应系统恢复正常时,便可以直接向支付接口发送支付请求,进一步提高了订单处理效率。
应当理解的是,如果在票务供应系统响应支付请求之前,票务供应系统再次发生接口异常,在将订单信息标记为未支付状态再次保存到收单缓存中的同时,还可以向用户终端返回表征支付失败的消息。
在一种可能的情况下,如果是在向票务供应系统发送订单信息A对应的请求后,确定了票务供应系统的接口异常,那么可以将用于向票务供应系统发起请求的订单信息A保存到收单缓存中,然后当票务供应系统的接口恢复正常时,根据收单缓存中的订单信息A重新向票务供应系统发送请求。
但是,对于票务供应系统而言,已经接收过该订单信息A对应的请求,并且可能票务供应系统已经对该订单信息A对应的请求进行过成功响应,那么票务供应系统在接口恢复正常后再次接收到该订单信息A对应的请求时,会返回失败响应消息。
为了避免这种情况的发生,票务供应系统可以支持幂等校验,从而可以使得票务供应系统对于之前已经发送过的历史请求进行重新响应,保证在票务供应系统的接口发生异常时被保存到收单缓存中的第一个订单信息可以被重新响应,或者保证由于票务供应系统重复发生不稳定而被再次保存到收单缓存中的订单信息可以被重新响应。
相应地,在票务供应系统支持幂等校验的情况下,根据收单缓存中的订单信息向票务供应系统发送请求的过程可以是先判断收单缓存中是否存在具有同一订单号且处于不同订单状态的多个订单信息。如果收单缓存中存在处于未下单状态的第一订单信息以及处于未支付状态的第二订单信息,则根据未下单状态的第一订单信息向票务供应系统的下单接口发送请求,然后,在下单成功后,根据未支付状态的第二订单信息向票务供应系统的支付接口发送请求。其中,第一订单信息和第二订单信息具有相同订单号。
也即是说,在释放收单缓存中的订单信息(根据收单缓存中的订单信息向票务供应系统发送请求)时,可以根据订单号进行释放。具体地,可以是将处于同一订单号的订单信息释放后,再释放其他处于同一订单号的订单信息。而针对处于同一订单号的订单信息的释放过程,可以是先将处于未下单状态的第一订单信息进行释放,然后在第一订单信息释放成功后再释放第二订单信息。
通过上述方式,在释放收单缓存中的订单信息时,可以通过订单状态进行释放,也可以根据订单号进行释放,从而能够满足不同的应用场景和使用需求,适用范围较广。
进一步,为了避免订单信息长期被保存到收单缓存中,减少收单缓存的存储压力以及票务供应系统对于收单缓存中的订单信息的处理压力,可以删除收单缓存中的订单信息。在一种可能的情况下,如果票务供应系统对订单信息的响应为成功,则可以删除收单缓存中的订单信息;或者如果超过预设时长未收到票务供应系统对订单信息的响应,则可以删除收单缓存中的订单信息。
示例地,预设时长可以是根据预设的规则进行设定的,等等,本公开实施例对此不作限定。比如,在白天向票务供应系统发送请求,该预设时长可以设定为1小时,那么超过1小时未收到票务供应系统对订单信息的响应,则可以删除收单缓存中的该订单信息。或者,在晚上向票务供应系统发送请求,该预设时长则可以设定为2小时,那么超过2小时未收到票务供应系统对订单信息的响应,则可以删除收单缓存中的该订单信息。又或者,对于购票高峰期,以及当日需要使用的票务订单,该预设时长可以设定为10分钟,那么超过10分钟未收到票务供应系统对订单信息的响应,则可以删除收单缓存中的该订单信息。
在一种可能的方式中,在将用于向所述票务供应系统发起请求的订单信息保存到收单缓存中之后,还可以确定该订单信息保存到收单缓存的时间段,然后向发送该订单信息的用户终端显示该时间段对应的等待时长。
示例地,保存到收单缓存的时间段、以及时间段对应的等待时长可以是根据不同应用需求而设定的,等等,本公开实施例对此不作限定。比如,保存到收单缓存的时间段可以包括周末时间段,工作日时间段,相应地,周末时间段对应的等待时长可以是10分钟,工作日时间段的等待时长可以是30分钟。或者,保存到收单缓存的时间段可以包括节假日时间段,非节假日时间段,相应地,节假日时间段对应的等待时长可以是5分钟,非节假日时间段的等待时长可以是15分钟,等等。
通过上述方式,可以在票务供应系统的接口出现异常后,预估用户需要等待的订单处理时长,并向用户终端显示该订单处理时长,增加了订单处理过程的智能性。
下面以票务供应系统支持幂等校验为例,通过一个完整的实施例对本公开中的订单处理方法进行说明。参照图3,该订单处理方法可以包括以下步骤:
步骤S301,确定票务供应系统的接口异常。
步骤S302,将用于向票务供应系统发起请求的订单信息保存到收单缓存中。
步骤S303,向票务供应系统发送模拟的订单请求。
步骤S304,确定票务供应系统对模拟的订单请求的响应是否满足预设条件,如果是,则进入步骤S305,否则进入步骤S306。
应当理解的是,预设条件可以包括票务供应系统连续预设次数对模拟的订单请求的响应为成功;或者票务供应系统对模拟的订单请求的响应为失败,且失败类型非接口异常类型。
步骤S305,确定票务供应系统的接口恢复正常。
应当理解的是,如图3所示,本公开实施例中可以是先将订单信息保存到收单缓存中,再向票务供应系统发送模拟的订单请求以确定票务供应系统的接口是否恢复正常。或者,在其他可能的情况下,也可以是先向票务供应系统发送模拟的订单请求以确定票务供应系统的接口是否恢复正常,再将订单信息保存到收单缓存中。又或者,也可以同时进行将订单信息保存到收单缓存中,以及向票务供应系统发送模拟的订单请求以确定票务供应系统的接口是否恢复正常的过程,本公开实施例对此不作限定。
步骤S306,确定是否超过预设时长未接收到票务供应系统对订单信息的响应,如果是,则进入步骤S307,否则进入步骤S303。
步骤S307,删除收单缓存中超过预设时长未接收到响应的订单信息。
步骤S308,当票务供应系统的接口恢复正常时,确定收单缓存中的订单信息的订单状态。
步骤S309,判断收单缓存中是否存在具有同一订单号且处于不同订单状态的多个订单信息,如果收单缓存中存在处于未下单状态的第一订单信息以及处于未支付状态的第二订单信息,则进入步骤S310,否则进入步骤S311。其中,第一订单信息和第二订单信息具有相同订单号。
步骤S310,对于收单缓存中的处于未下单状态的第一订单信息,向票务供应系统的下单接口发送请求。
步骤S311,对于处于未下单状态的订单信息,向票务供应系统的下单接口发送请求,或者对于处于未支付状态的订单信息,向票务供应系统的支付接口发送请求。
步骤S312,在根据第一订单信息向票务供应系统的下单接口发送请求后,确定是否接收到票务供应系统发送的下单成功响应,如果是,则进入步骤S313,否则进入步骤S314。
步骤S313,向票务供应系统的支付接口发送支付请求,并删除收单缓存中被成功响应的第一订单信息。
步骤S314,向用户终端返回表征下单失败或支付失败的响应消息。
步骤S315,确定在票务供应系统响应支付请求之前,票务供应系统是否再次发送接口异常,如果是,则进入步骤S316,否则进入步骤S317。
步骤S316,再次保存订单信息到收单缓存中,并将该订单信息标记为未支付状态,进入步骤S303。
步骤S317,向用户终端返回表征支付成功的响应消息,并删除收单缓存中被成功响应的第二订单信息。应当理解的是,上述各步骤的具体实施过程已在上文进行详细说明,这里不再赘述。
通过上述方法,当票务供应系统的接口发生异常时,用户的订单信息可以被保存到收单缓存中,然后当票务供应系统的接口恢复正常时可以根据收单缓存中的订单信息继续向票务供应系统发送订单请求,无需用户重复发起订单请求,可以提高订单处理效率。
基于同一发明构思,参照图4,本公开实施例还提供一种订单处理装置400,该装置400可以通过硬件、软件或两者结合的方式成为电子设备的部分或全部,包括:
确定模块401,用于确定票务供应系统的接口异常;
保存模块402,用于将用于向所述票务供应系统发起请求的订单信息保存到收单缓存中;
发送模块403,用于当所述票务供应系统的接口恢复正常时,根据所述收单缓存中的订单信息向所述票务供应系统发送请求。
可选地,所述装置400还包括:
请求发送模块,用于向所述票务供应系统发送模拟的订单请求;
接口确定模块,用于当所述票务供应系统对所述模拟的订单请求的响应满足预设条件时,确定所述票务供应系统的接口恢复正常。
可选地,所述预设条件包括:
所述票务供应系统连续预设次数对所述模拟的订单请求的响应为成功;或者,
所述票务供应系统对所述模拟的订单请求的响应为失败,且失败类型非接口异常类型。
可选地,所述发送模块403用于:
确定所述收单缓存中的订单信息的订单状态,其中,每一所述订单信息的订单状态为未下单状态或未支付状态;
根据所述订单状态,针对每一所述订单信息向所述票务供应系统发送下单请求或支付请求。
可选地,所述发送模块403用于:
对于所述收单缓存中的处于未下单状态的订单信息,向所述票务供应系统的下单接口发送下单请求;
如果接收到所述票务供应系统发送的下单成功响应,则向所述票务供应系统的支付接口发送支付请求;
如果在所述票务供应系统响应所述支付请求之前,所述票务供应系统再次发生接口异常,则再次保存所述订单信息到所述收单缓存中,并将所述订单信息标记为未支付状态。
可选地,所述票务供应系统支持幂等校验,所述发送模块403用于:
判断所述收单缓存中是否存在具有同一订单号且处于不同订单状态的多个订单信息;
如果所述收单缓存中存在处于未下单状态的第一订单信息以及处于未支付状态的第二订单信息,则根据所述未下单状态的第一订单信息向所述票务供应系统的下单接口发送请求,其中,所述第一订单信息和所述第二订单信息具有相同订单号;
在下单成功后,根据未支付状态的所述第二订单信息向所述票务供应系统的支付接口发送请求。
可选地,所述装置400还包括:
第一删除模块,用于当所述票务供应系统对订单信息的响应为成功时,删除所述收单缓存中的所述订单信息;或者
第二删除模块,用于当超过预设时长未收到所述票务供应系统对订单信息的响应时,删除所述收单缓存中的所述订单信息。
关于上述实施例中的装置,其中各个模块执行操作的具体方式已经在有关该方法的实施例中进行了详细描述,此处将不做详细阐述说明。
通过上述任一订单处理装置,当票务供应系统的接口发生异常时,用户的订单信息可以被保存到收单缓存中,然后当票务供应系统的接口恢复正常时可以根据收单缓存中的订单信息继续向票务供应系统发送订单请求,无需用户重复发起订单请求,从而可以提高订单处理效率。
基于同一发明构思,本公开实施例还提供一种电子设备,包括:
存储器,其上存储有计算机程序;
处理器,用于执行所述存储器中的所述计算机程序,以实现上述任一订单处理方法的步骤。
在一种可能方式中,该电子设备的框图可以如图5所示。参照图5,电子设备500可以被提供为一服务器。参照图5,电子设备500包括处理器522,其数量可以为一个或多个,以及存储器532,用于存储可由处理器522执行的计算机程序。存储器532中存储的计算机程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外,处理器522可以被配置为执行该计算机程序,以执行上述的订单处理方法。
另外,电子设备500还可以包括电源组件526和通信组件550,该电源组件526可以被配置为执行电子设备500的电源管理,该通信组件550可以被配置为实现电子设备500的通信,例如,有线或无线通信。此外,该电子设备500还可以包括输入/输出(I/O)接口558。电子设备500可以操作基于存储在存储器532的操作系统,例如Windows ServerTM,Mac OSXTM,UnixTM,LinuxTM等等。
在另一示例性实施例中,还提供了一种包括程序指令的计算机可读存储介质,该程序指令被处理器执行时实现上述的订单处理方法的步骤。例如,该计算机可读存储介质可以为上述包括程序指令的存储器532,上述程序指令可由电子设备500的处理器522执行以完成上述的订单处理方法。
以上结合附图详细描述了本公开的优选实施方式,但是,本公开并不限于上述实施方式中的具体细节,在本公开的技术构思范围内,可以对本公开的技术方案进行多种简单变型,这些简单变型均属于本公开的保护范围。
另外需要说明的是,在上述具体实施方式中所描述的各个具体技术特征,在不矛盾的情况下,可以通过任何合适的方式进行组合,为了避免不必要的重复,本公开对各种可能的组合方式不再另行说明。
此外,本公开的各种不同的实施方式之间也可以进行任意组合,只要其不违背本公开的思想,其同样应当视为本公开所公开的内容。
Claims (10)
1.一种订单处理方法,其特征在于,所述方法包括:
确定票务供应系统的接口异常;
将用于向所述票务供应系统发起请求的订单信息保存到收单缓存中;
如果所述票务供应系统的接口恢复正常,则根据所述收单缓存中的订单信息向所述票务供应系统发送请求。
2.根据权利要求1所述的方法,其特征在于,所述方法还包括:
向所述票务供应系统发送模拟的订单请求;
如果所述票务供应系统对所述模拟的订单请求的响应满足预设条件,则确定所述票务供应系统的接口恢复正常。
3.根据权利要求2所述的方法,其特征在于,所述预设条件包括:
所述票务供应系统连续预设次数对所述模拟的订单请求的响应为成功;或者,
所述票务供应系统对所述模拟的订单请求的响应为失败,且失败类型非接口异常类型。
4.根据权利要求1至3中任一项所述的方法,其特征在于,所述根据所述收单缓存中的订单信息向所述票务供应系统发送请求,包括:
确定所述收单缓存中的订单信息的订单状态,其中,每一所述订单信息的订单状态为未下单状态或未支付状态;
根据所述订单状态,针对每一所述订单信息向所述票务供应系统发送下单请求或支付请求。
5.根据权利要求1至3中任一项所述的方法,其特征在于,所述根据所述收单缓存中的订单信息向所述票务供应系统发送请求,包括:
对于所述收单缓存中的处于未下单状态的订单信息,向所述票务供应系统的下单接口发送下单请求;
如果接收到所述票务供应系统发送的下单成功响应,则向所述票务供应系统的支付接口发送支付请求;
如果在所述票务供应系统响应所述支付请求之前,所述票务供应系统再次发生接口异常,则再次保存所述订单信息到所述收单缓存中,并将所述订单信息标记为未支付状态。
6.根据权利要求1至3中任一项所述的方法,其特征在于,所述票务供应系统支持幂等校验,所述根据所述收单缓存中的订单信息向所述票务供应系统发送请求,包括:
判断所述收单缓存中是否存在具有同一订单号且处于不同订单状态的多个订单信息;
如果所述收单缓存中存在处于未下单状态的第一订单信息以及处于未支付状态的第二订单信息,则根据所述未下单状态的第一订单信息向所述票务供应系统的下单接口发送请求,其中,所述第一订单信息和所述第二订单信息具有相同订单号;
在下单成功后,根据未支付状态的所述第二订单信息向所述票务供应系统的支付接口发送请求。
7.根据权利要求1至3中任一项所述的方法,其特征在于,所述方法还包括:
如果所述票务供应系统对订单信息的响应为成功,则删除所述收单缓存中的所述订单信息;或者
如果超过预设时长未收到所述票务供应系统对订单信息的响应,则删除所述收单缓存中的所述订单信息。
8.一种订单处理装置,其特征在于,所述装置包括:
确定模块,用于确定票务供应系统的接口异常;
保存模块,用于将用于向所述票务供应系统发起请求的订单信息保存到收单缓存中;
发送模块,用于当所述票务供应系统的接口恢复正常时,根据所述收单缓存中的订单信息向所述票务供应系统发送请求。
9.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现权利要求1至7中任一项所述方法的步骤。
10.一种电子设备,其特征在于,包括:
存储器,其上存储有计算机程序;
处理器,用于执行所述存储器中的所述计算机程序,以实现权利要求1至7中任一项所述方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910285914.XA CN110060124A (zh) | 2019-04-10 | 2019-04-10 | 订单处理方法、装置、存储介质及电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910285914.XA CN110060124A (zh) | 2019-04-10 | 2019-04-10 | 订单处理方法、装置、存储介质及电子设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN110060124A true CN110060124A (zh) | 2019-07-26 |
Family
ID=67318771
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910285914.XA Pending CN110060124A (zh) | 2019-04-10 | 2019-04-10 | 订单处理方法、装置、存储介质及电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110060124A (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111539869A (zh) * | 2019-12-04 | 2020-08-14 | 中国科学院信息工程研究所 | 一种车票请求方法和装置及计算机可读存储介质 |
CN111652691A (zh) * | 2020-06-09 | 2020-09-11 | 北京字节跳动网络技术有限公司 | 一种订单信息处理方法、装置和电子设备 |
CN111861626A (zh) * | 2020-01-16 | 2020-10-30 | 北京嘀嘀无限科技发展有限公司 | 一种充电处理方法及装置 |
CN112686720A (zh) * | 2019-10-17 | 2021-04-20 | 中国移动通信集团浙江有限公司 | 订单生产方法、装置、设备及计算机可读存储介质 |
-
2019
- 2019-04-10 CN CN201910285914.XA patent/CN110060124A/zh active Pending
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112686720A (zh) * | 2019-10-17 | 2021-04-20 | 中国移动通信集团浙江有限公司 | 订单生产方法、装置、设备及计算机可读存储介质 |
CN112686720B (zh) * | 2019-10-17 | 2024-03-19 | 中国移动通信集团浙江有限公司 | 订单生产方法、装置、设备及计算机可读存储介质 |
CN111539869A (zh) * | 2019-12-04 | 2020-08-14 | 中国科学院信息工程研究所 | 一种车票请求方法和装置及计算机可读存储介质 |
CN111861626A (zh) * | 2020-01-16 | 2020-10-30 | 北京嘀嘀无限科技发展有限公司 | 一种充电处理方法及装置 |
CN111652691A (zh) * | 2020-06-09 | 2020-09-11 | 北京字节跳动网络技术有限公司 | 一种订单信息处理方法、装置和电子设备 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110060124A (zh) | 订单处理方法、装置、存储介质及电子设备 | |
CN112672357B (zh) | 处理业务系统中用户账号的方法、装置及计算机设备 | |
CN108629594A (zh) | 支付方法、装置、服务器以及存储介质 | |
CN106330458B (zh) | 一种验证码的处理方法及装置 | |
CN104834602A (zh) | 一种程序发布方法、装置和程序发布系统 | |
CN109614426A (zh) | 多数据库间的切换方法、装置及电子设备 | |
CN111510493B (zh) | 分布式数据传输方法及装置 | |
CN106528333A (zh) | 一种数据备份方法和装置 | |
EP1863198A1 (en) | Push-to-talk communication system and push-to-talk communication method | |
CN101404792A (zh) | 一种手机备份短信的方法和系统 | |
CN110098920A (zh) | 一种减少节点碰撞的区块链节点负载均衡方法及装置 | |
CN110248383A (zh) | 上行链路信道调度方法和装置、介质、基站和用户终端 | |
CN117459286A (zh) | 基于sd-wan的数据通信安全预警方法及装置 | |
WO2001052487A1 (en) | System and method for inputting a web-page input data into a web page by employing a wire/wireless telephone | |
CN103188084B (zh) | 一种广播用户图片的方法、系统及广播服务器 | |
CN106295310A (zh) | 第三方程序sdk验证处理方法及装置 | |
CN109447750A (zh) | 一种服务器、订单处理方法及系统 | |
JP2000201223A (ja) | 無線通信装置 | |
CN101930575A (zh) | 电子票拆分方法和拆分系统 | |
CN109561411A (zh) | 打车服务的优化方法及装置 | |
CN101572882B (zh) | 无线通信系统及其诊断方法、以及在诊断中用的无线终端 | |
CN108347403A (zh) | 一种分配中间通信标识的方法和装置 | |
CN109327814A (zh) | 短消息的处理方法、装置、电子设备及可读存储介质 | |
CN110309112A (zh) | 一种数据处理方法、设备、服务器及可读存储介质 | |
US20070168628A1 (en) | Method for backing up personal data of a telecommunications network subscriber, server and associated device |
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 |