本申请涉及计算机领域，尤其涉及一种用于rpc接口调用失败处理的方法及设备。
背景技术：
在服务之间rpc接口相互调用的场景中，一旦出现接口调用失败，有以下几种场景以及处理方式：一种是，接口调用返回失败，根据接口返回的错误码进行业务处理；另一种是，接口调用超时异常，捕捉超时异常后往外抛异常。但通过上述方式处理有以下缺点：判断接口返回错误码进行业务处理时，往往没有对错误的类型进行保存和区分，只能靠人工干预，如人工查询失败日志，对错误和错误信息进行人工识别，人工处理失败记录；对于调用失败除了重试，无法根据异常失败类型进行自动化业务逻辑判断和处理；使用重试策略也会有重试次数限制，若是业务逻辑错误，则重试多少次结果都是一样的失败。
技术实现要素：
本申请的一个目的是提供一种用于rpc接口调用失败处理的方法及设备，解决现有技术中没有对调用失败的类型进行保存和区分以及需要人工干预，无法进行自动化业务逻辑判断和处理的问题。
根据本申请的一个方面，提供了一种用于rpc接口调用失败处理的方法，该方法包括：
判断rpc接口调用是否失败，若是，则确定失败类型并保存业务订单失败记录；
定时任务处理所述rpc接口调用时的业务订单失败记录，根据所述失败类型选取对应的业务处理方式进行处理，并更新所述业务订单失败记录的操作状态。
进一步地，判断rpc接口调用是否失败，包括以下任一项：
通过捕捉超时异常判断是否发生网络超时失败，若是，则rpc接口调用失败；
通过返回码判断业务操作是否失败，若是，则rpc接口调用失败。
进一步地，所述方法，包括：
调用rpc接口，判断调用是否成功，若否，则新建一个事务进行保存业务订单失败记录，并通过邮件或短信操作发送所述业务订单失败记录；
若是，则直接封装返回信息。
进一步地，所述失败类型包括业务场景调用失败类型，根据所述失败类型选取对应的业务处理方式进行处理，包括：
根据所述业务场景调用失败类型选取对应的业务处理方式进行处理。
进一步地，根据所述业务场景调用失败类型选取对应的业务处理方式进行处理，包括以下任一项：
若所述业务场景调用失败类型为购买场景的订单减库存失败，则根据业务需求进行重试，且重试次数达到预设次数前继续调用减库存rpc接口；
若所述业务场景调用失败类型为支付场景的订单付款失败，则根据业务需求进行取消订单的处理。
进一步地，更新所述业务订单失败记录的操作状态，包括：
将新增的业务订单失败记录的操作状态初始化为未操作，当定时任务对所述新增的业务订单失败记录进行自动化处理后，将所述操作状态更新为已操作。
进一步地，保存业务订单失败记录，包括：
将业务订单失败记录保存至数据表中，其中，所述数据表中包括varchar类型的业务单号。
根据本申请另一个方面，还提供了一种用于rpc接口调用失败处理的设备，该设备包括：
判断装置，用于判断rpc接口调用是否失败，若是，则确定失败类型并保存业务订单失败记录；
处理装置，用于定时任务处理所述rpc接口调用时的业务订单失败记录，根据所述失败类型选取对应的业务处理方式进行处理，并更新所述业务订单失败记录的操作状态。
根据本申请又一个方面，还提供了一种用于rpc接口调用失败处理的设备，所述设备包括：
一个或多个处理器；以及
存储有计算机可读指令的存储器，所述计算机可读指令在被执行时使所述处理器执行如前述所述方法的操作。
根据本申请再一个方面，还提供了一种计算机可读介质，其上存储有计算机可读指令，所述计算机可读指令可被处理器执行以实现如前述所述的方法。
与现有技术相比，本申请通过判断rpc接口调用是否失败，若是，则确定失败类型并保存业务订单失败记录；定时任务处理所述rpc接口调用时的业务订单失败记录，根据所述失败类型选取对应的业务处理方式进行处理，并更新所述业务订单失败记录的操作状态。通过按照业务维度来记录失败日志，方便快速定位，并区分失败类型，方便后续通过自动化处理方式去重试或作下一步业务操作。
附图说明
通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：
图1示出根据本申请的一个方面提供的一种用于rpc接口调用失败处理的方法流程示意图；
图2示出本申请一实施例中保存业务订单数据的流程示意图；
图3示出本申请一实施例中定时任务处理rpc调用失败记录的流程示意图；
图4示出本申请又一个方面提供的一种用于rpc接口调用失败处理的设备结构示意图。
附图中相同或相似的附图标记代表相同或相似的部件。
具体实施方式
下面结合附图对本申请作进一步详细描述。
在本申请一个典型的配置中，终端、服务网络的设备和可信方均包括一个或多个处理器(例如中央处理器(centralprocessingunit，cpu))、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(randomaccessmemory，ram)和/或非易失性内存等形式，如只读存储器(readonlymemory，rom)或闪存(flashram)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(phase-changeram，pram)、静态随机存取存储器(staticrandomaccessmemory，sram)、动态随机存取存储器(dynamicrandomaccessmemory，dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(electricallyerasableprogrammableread-onlymemory，eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(compactdiscread-onlymemory，cd-rom)、数字多功能光盘(digitalversatiledisk，dvd)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括非暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。
图1示出根据本申请的一个方面提供的一种用于rpc接口调用失败处理的方法流程示意图，该方法包括：步骤s11～步骤s12，其中，在步骤s11中，判断rpc接口调用是否失败，若是，则确定失败类型并保存业务订单失败记录；在步骤s12中，定时任务处理所述rpc接口调用时的业务订单失败记录，根据所述失败类型选取对应的业务处理方式进行处理，并更新所述业务订单失败记录的操作状态。通过按照业务维度来记录失败日志，方便快速定位，并区分失败类型，方便后续通过自动化处理方式去重试或作下一步业务操作。
具体地，在步骤s11中，判断rpc接口调用是否失败，若是，则确定失败类型并保存业务订单失败记录；在此，用户提交购买订单或退货订单时，订单服务先保存订单信息，随后调用后端库存服务的rpc接口来对商品库存进行变更，比如是购买则减库存，是退货则增库存，若rpc接口调用失败，则扫描记录表中未操作的失败记录进行处理，确定失败类型，并需要保存业务订单失败信息，即将本次的业务订单失败记录保存下来。
具体地，在步骤s12中，定时任务处理所述rpc接口调用时的业务订单失败记录，根据所述失败类型选取对应的业务处理方式进行处理，并更新所述业务订单失败记录的操作状态。在此，编写定时任务，扫描处理未操作的失败记录，根据记录的失败类型结合具体业务进行下一步操作，不同失败类型有不同的相应的业务处理方式，处理后更新业务订单失败记录的操作状态为已操作，从而避免重复操作，同时记录相应的操作人、操作时间、操作类型以及操作名称等操作信息，方便业务跟踪和分析。
在本申请一实施例中，在步骤s11中，可以通过捕捉超时异常判断是否发生网络超时失败，若是，则rpc接口调用失败；或，通过返回码判断业务操作是否失败，若是，则rpc接口调用失败。在此，若rpc接口调用失败，有以下两种场景：通过捕捉超时异常得知网络超时失败，或，通过返回码来判断是业务操作失败，比如库存不足。当出现上述场景时，则认为是rpc接口调用失败。
在本申请一实施例中，保存业务订单记录之后，可以调用rpc接口，判断调用是否成功，若否，则新建一个事务进行保存业务订单失败记录，并通过邮件或短信操作发送所述业务订单失败记录；若是，则直接封装返回信息。在此，如图2所示，新建一个事务用于保存业务订单记录，调用rpc接口时，若调用失败，则新建另一个事务进行保存业务单失败记录，并发送邮件或短信，随后封装返回信息；若调用成功，则直接封装返回信息。从而保证了失败日志信息得到有效记录。具体地，业务数据的保存和失败记录的保存要分开，利用事务传播性，业务方法使用注解和保存失败记录的方法使用不同的注解，新开启一个事务来保存失败日志，以免业务方法的异常回滚导致失败日志保存不成功。可能会因为数据库原因导致失败记录保存不成功，则可以通过发送失败邮件或短信等操作为补充，比如邮件发送方法要捕捉异常，不影响业务数据和失败日志的保存，从而记录表的数据和邮件相互补充，作为rpc接口调用失败的依据。
在本申请一实施例中，所述失败类型包括业务场景调用失败类型，在步骤s12中，根据所述业务场景调用失败类型选取对应的业务处理方式进行处理。其中，业务处理方式包括以下任一项：若所述业务场景调用失败类型为购买场景的订单减库存失败，则根据业务需求进行重试，当重试次数达到预设次数前继续调用减库存rpc接口；若所述业务场景调用失败类型为支付场景的订单付款失败，则根据业务需求进行取消订单的处理。在此，如图3所示，定时任务处理rpc调用失败记录，查询“未操作”的业务单失败记录，判断该失败类型，在不同业务场景下，失败类型不同，因此确定对应的业务场景调用失败类型，即订单在什么样的业务场景下进行调用rpc接口时发生了失败情况，针对不同业务场景，采取相应的业务处理方式，比如当为第一种失败类型，即减库存失败时，则处理方式为重试3次调用减库存rpc接口，在未满足3次之前需要一直重试继续调用减库存rpc接口，直至重试次数达到3次后停止调用；若为第2种失败类型，即订单支付失败时，则处理方式为取消订单，同样的，当其他种失败类型时，则进行相应的失败业务处理即可。需要说明的是，处理方式包括但不限于上述处理方式，在本申请实施例中仅为举例。
接上述实施例，在步骤s12中，将新增的业务订单失败记录的操作状态初始化为未操作，当定时任务对所述新增的业务订单失败记录进行自动化处理后，将所述操作状态更新为已操作。在此，如图3所示，业务单rpc接口调用失败后，新增的失败数据操作状态operate-status初始化为“未操作”，定时任务对失败的业务订单进行自动化处理后，更新业务单失败记录的操作状态为“已操作”，避免重复操作。
在本申请一实施例中，在步骤s11中，将业务订单失败记录保存至数据表中，其中，所述数据表中包括varchar类型的业务单号。在此，将业务订单失败记录保存至数据表中，该数据表为失败记录表，对该失败记录表进行设计，在失败记录表中业务单号设计成varchar类型，从而可以兼容不同场景的业务单号，如购买场景的订单号，支付场景的付款单号，物流场景的运单号，售后场景的退货单号等。在失败记录表中表字段fail_log为失败日志，用来记录当前业务调用失败的原因，比如rpc失败日志的入参、出参、超时信息等；失败记录表中字段fail_type为失败类型，区分不同业务场景下的rpc接口调用失败，如购买场景的订单减库存失败，支付场景的订单付款失败等。失败记录表有失败处理依据，业务单rpc接口调用失败后，新增的失败数据操作状态初始化为“未操作”，定时任务扫描失败记录表中未操作的失败记录进行处理，根据记录的失败类型，再结合具体业务进行下一步操作，定时任务对失败的业务进行自动化处理后，操作状态为“已操作”。
通过本申请所述的方法，新开启一个事务来保存失败日志，保证在rpc调用接口失败时，已有业务的事务回滚不影响当前失败日志保存事务的提交；数据库日志和邮件或短信相互补充，作为当前记录是否失败的依据，自动化定时任务根据失败记录的失败类型进行判断，结合不同业务需求做出下一步操作，取代人工分析和补救操作。
此外，本申请实施例还提供了一种计算机可读介质，其上存储有计算机可读指令，所述计算机可读指令可被处理器执行以实现前述一种用于rpc接口调用失败处理的方法。
与上文所述的方法相对应的，本申请还提供一种终端，其包括能够执行上述图1或图2或图3或各个实施例所述的方法步骤的模块或单元，这些模块或单元可以通过硬件、软件或软硬结合的方式来实现，本申请并不限定。例如，在本申请一实施例中，还提供了一种用于rpc接口调用失败处理的设备，所述设备包括：
一个或多个处理器；以及
存储有计算机可读指令的存储器，所述计算机可读指令在被执行时使所述处理器执行如前述所述方法的操作。
例如，计算机可读指令在被执行时使所述一个或多个处理器：
判断rpc接口调用是否失败，若是，则确定失败类型并保存业务订单失败记录；
定时任务处理所述rpc接口调用时的业务订单失败记录，根据所述失败类型选取对应的业务处理方式进行处理，并更新所述业务订单失败记录的操作状态。
图4示出本申请又一个方面提供的一种用于rpc接口调用失败处理的设备结构示意图，所述设备包括：判断装置11及处理装置12，其中，判断装置11用于判断rpc接口调用是否失败，若是，则确定失败类型并保存业务订单失败记录；处理装置12用于定时任务处理所述rpc接口调用时的业务订单失败记录，根据所述失败类型选取对应的业务处理方式进行处理，并更新所述业务订单失败记录的操作状态。
需要说明的是，判断装置11及处理装置12执行的内容分别与上述步骤s11和s12中的内容相同或相应相同，为简明起见，在此不再赘述。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(asic)、通用目的计算机或任何其他类似硬件设备来实现。在一个实施例中，本申请的软件程序可以通过处理器执行以实现上文所述步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，ram存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。
另外，本申请的一部分可被应用为计算机程序产品，例如计算机程序指令，当其被计算机执行时，通过该计算机的操作，可以调用或提供根据本申请的方法和/或技术方案。而调用本申请的方法的程序指令，可能被存储在固定的或可移动的记录介质中，和/或通过广播或其他信号承载媒体中的数据流而被传输，和/或被存储在根据所述程序指令运行的计算机设备的工作存储器中。在此，根据本申请的一个实施例包括一个装置，该装置包括用于存储计算机程序指令的存储器和用于执行程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发该装置运行基于前述根据本申请的多个实施例的方法和/或技术方案。
对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。
1.一种用于rpc接口调用失败处理的方法，其特征在于，所述方法包括：
判断rpc接口调用是否失败，若是，则确定失败类型保存业务订单失败记录；
定时任务处理所述rpc接口调用时的业务订单失败记录，根据所述失败类型选取对应的业务处理方式进行处理，并更新所述业务订单失败记录的操作状态。
2.根据权利要求1所述的方法，其特征在于，判断rpc接口调用是否失败，包括以下任一项：
通过捕捉超时异常判断是否发生网络超时失败，若是，则rpc接口调用失败；
通过返回码判断业务操作是否失败，若是，则rpc接口调用失败。
3.根据权利要求1所述的方法，其特征在于，所述方法包括：
调用rpc接口，判断调用是否成功，若否，则新建一个事务进行保存业务订单失败记录，并通过邮件或短信操作发送所述业务订单失败记录；
若是，则直接封装返回信息。
4.根据权利要求1所述的方法，其特征在于，所述失败类型包括业务场景调用失败类型，根据所述失败类型选取对应的业务处理方式进行处理，包括：
根据所述业务场景调用失败类型选取对应的业务处理方式进行处理。
5.根据权利要求4所述的方法，其特征在于，根据所述业务场景调用失败类型选取对应的业务处理方式进行处理，包括以下任一项：
若所述业务场景调用失败类型为购买场景的订单减库存失败，则根据业务需求进行重试，当重试次数达到预设次数前继续调用减库存rpc接口；
若所述业务场景调用失败类型为支付场景的订单付款失败，则根据业务需求进行取消订单的处理。
6.根据权利要求1或5所述的方法，其特征在于，更新所述业务订单失败记录的操作状态，包括：
将新增的业务订单失败记录的操作状态初始化为未操作，当定时任务对所述新增的业务订单失败记录进行自动化处理后，将所述操作状态更新为已操作。
7.根据权利要求1所述的方法，其特征在于，保存业务订单失败记录，包括：
将业务订单失败记录保存至数据表中，其中，所述数据表中包括varchar类型的业务单号。
8.一种用于rpc接口调用失败处理的设备，其特征在于，所述设备包括：
判断装置，用于判断rpc接口调用是否失败，若是，则确定失败类型并保存业务订单失败记录；
处理装置，用于定时任务处理所述rpc接口调用时的业务订单失败记录，根据所述失败类型选取对应的业务处理方式进行处理，并更新所述业务订单失败记录的操作状态。
9.一种用于rpc接口调用失败处理的设备，其特征在于，所述设备包括：
一个或多个处理器；以及
存储有计算机可读指令的存储器，所述计算机可读指令在被执行时使所述处理器执行如权利要求1至7中任一项所述方法的操作。
10.一种计算机可读介质，其上存储有计算机可读指令，所述计算机可读指令可被处理器执行以实现如权利要求1至7中任一项所述的方法。
技术总结