CN110033280B - 支付防抖方法及装置 - Google Patents

Abstract

本公开提供了一种支付防抖方法及装置。该方法包括：拦截客户端在支付过程中发送到服务端的当前业务请求，当前业务请求至少包括唯一阶段标识；基于与当前业务请求对应的防抖标记，确定针对当前业务请求的远程业务调用是否异常；在针对当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，兜底处理结果至少包括与唯一阶段标识所标识的支付阶段对应的模拟正常结果；将兜底处理结果发送给客户端。该装置包括拦截单元、异常确定单元、兜底处理单元和发送单元。利用该方法和装置，保障更高的可用率目标，保障金融级别的稳定，减少商户收款损失，减少系统抖动、故障对业务带来的影响及业务损失，提升整体业务链路的成功率，同时提升用户体验。

Description

支付防抖方法及装置

技术领域

本公开通常涉及网络应用技术领域，更具体地，涉及支付防抖方法及装置。

背景技术

如果网络发生拥塞，排队延迟将影响端到端的延迟，并导致通过同一连接传输的分组延迟各不相同，而抖动，就是用来描述这一延迟变化的程度。网络中的延迟是指信息从发送到接收经过的延迟时间，一般由传输延迟及处理延迟组成，而抖动是指最大延迟与最小延迟的时间差，如最大延迟是20毫秒，最小延迟为5毫秒，那么网络抖动就是15毫秒，它主要标识一个网络的稳定性。

移动支付是指使用手机或其他智能设备完成支付或确认支付，而不是用现金、支票或银行卡支付。兜底是指支付系统出故障时采取的救济措施。

随着移动支付的越来越普及，并发访问量和交易量呈爆发式增长态势，支付安全也是被关注的一个问题。在目前互联网规模以及复杂的企业级分布式架构体系下，当有大量用户访问时网络抖动是不可避免的，因此容易造成事务失败，或者由于事务正在进行中，锁定资源太多，比如锁定数据表记录太多，导致其他事务等待时间较长。比如在进行移动支付过程中如果链路发生抖动，可能造成支付错误，造成支付失败，导致商户收款损失，因此分布式系统需要进一步提高系统稳定性，进一步提高可用率。

发明内容

鉴于上述问题，本公开提供了一种支付防抖方法及装置。利用该方法及装置，对于本次支付从发现系统出现抖动时起的业务请求到最后一次业务请求均返回模拟的正常结果，具有支付链路多阶段防抖能力，减少系统抖动对业务带来的影响以及业务损失。

根据本公开的一个方面，提供了一种支付防抖方法，包括：拦截客户端在支付过程中发送到服务端的当前业务请求，所述当前业务请求至少包括唯一阶段标识，其中，所述支付过程包括多个支付阶段，以及所述唯一阶段标识用于唯一标识所述当前业务请求所对应的支付阶段；基于与所述当前业务请求对应的防抖标记，确定针对所述当前业务请求的远程业务调用是否异常；在针对所述当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，所述兜底处理结果至少包括与所述唯一阶段标识所标识的支付阶段对应的模拟正常结果；以及将所述兜底处理结果发送给所述客户端。

可选地，在上述方面的一个示例中，基于与所述当前业务请求对应的防抖标记，确定针对当前业务请求的远程业务调用是否异常包括：在所述防抖标记的标记值指示远程业务调用异常时，确定针对当前业务请求的远程业务调用异常。

可选地，在上述方面的一个示例中，基于与所述当前业务请求对应的防抖标记，确定针对所述当前业务请求的远程业务调用是否异常包括：在所述防抖标记的标记值指示远程业务调用正常时，根据所述当前业务请求执行远程业务调用；以及基于所述远程业务调用的返回结果是否异常，确定针对所述当前业务请求的远程业务调用是否异常。

可选地，在上述方面的一个示例中，所述支付防抖方法还包括：在所述远程业务调用的返回结果异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值并包括在所述兜底处理结果中。

可选地，在上述方面的一个示例中，在所述远程业务调用的返回结果异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值包括：在确定针对所述当前业务请求的远程业务调用异常时，识别所述远程业务调用异常是否为能够进行兜底处理的异常；以及在识别出所述远程业务调用异常是能够进行兜底处理的异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值并包括在所述兜底处理结果中。

可选地，在上述方面的一个示例中，在所述当前业务请求是首次业务请求时，所述防抖标记是在拦截到所述当前业务请求后创建的，或者在所述当前业务请求是非首次业务请求时，所述防抖标记是上一业务请求处理过程所返回的防抖标记。

可选地，在上述方面的一个示例中，在所述当前业务请求是首次业务请求时，通过下述过程来为所述当前业务请求创建防抖标记：在拦截到所述当前业务请求后，解析所拦截的当前业务请求，以确定所述当前业务请求所属的业务类型；在所确定的业务类型属于需要防抖处理的业务类型时，为所述当前业务请求创建所述防抖标记。

可选地，在上述方面的一个示例中，所述需要防抖处理的业务类型包括线下收钱码支付业务。

可选地，在上述方面的一个示例中，在所述当前业务请求是所述支付过程的最后业务请求时，所述方法还包括：在将所述兜底处理结果发送给所述客户端后，根据与所述支付过程对应的支付信息，从垫支账户中支付相应数目的支付款给卖家。

可选地，在上述方面的一个示例中，所述支付防抖方法还包括：响应于从垫支账户中支付相应数目的支付款给卖家，通知所述卖家相应数目的支付款已到账。

根据本公开的另一方面，提供一种支付防抖装置，包括：拦截单元，被配置为拦截客户端在支付过程中发送到服务端的当前业务请求，所述当前业务请求至少包括唯一阶段标识，其中，所述支付过程包括多个支付阶段，以及所述唯一阶段标识用于唯一标识所述当前业务请求所对应的支付阶段；异常确定单元，被配置为基于与所述当前业务请求对应的防抖标记，确定针对所述当前业务请求的远程业务调用是否异常；兜底处理单元，被配置为在针对所述当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，所述兜底处理结果至少包括与所述唯一阶段标识所标识的支付阶段对应的模拟正常结果；以及发送单元，被配置为将所述兜底处理结果发送给所述客户端。

可选地，在上述方面的一个示例中，所述异常确定单元进一步被配置为：在所述防抖标记的标记值指示远程业务调用异常时，确定针对当前业务请求的远程业务调用异常。

可选地，在上述方面的一个示例中，所述支付防抖装置还包括：业务调用单元，被配置为在所述防抖标记的标记值指示远程业务调用正常时，根据所述当前业务请求执行远程业务调用，其中，所述异常确定单元还被配置为：基于所述远程业务调用的返回结果是否异常，确定针对所述当前业务请求的远程业务调用是否异常。

可选地，在上述方面的一个示例中，所述支付防抖装置还包括：标记值调整单元，被配置为在所述远程业务调用的返回结果异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值并包括在所述兜底处理结果中。

可选地，在上述方面的一个示例中，所述支付防抖装置还包括：异常识别单元，被配置为在所述远程业务调用的返回结果异常时，识别所述远程业务调用异常是否为能够进行兜底处理的异常，其中，所述标记值调整单元还被配置为在识别出所述远程业务调用异常是能够进行兜底处理的异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值并包括在所述兜底处理结果中。

可选地，在上述方面的一个示例中，所述支付防抖装置还包括：防抖标记创建单元，被配置为在所述当前业务请求是首次业务请求时，在拦截到所述当前业务请求后为所述当前业务请求创建所述防抖标记。

可选地，在上述方面的一个示例中，所述支付防抖装置还包括：业务类型确定单元，被配置为在所述当前业务请求是首次业务请求时，在拦截到所述当前业务请求后，解析所拦截的当前业务请求，以确定所述当前业务请求所属的业务类型，其中，所述防抖标记创建单元还被配置为在所确定的业务类型属于需要防抖处理的业务类型时，为所述当前业务请求创建所述防抖标记。

根据本公开的又一方面，提供一种计算设备，包括：一个或多个处理器，以及与所述一个或多个处理器耦合的存储器，所述存储器存储指令，当所述指令被所述一个或多个处理器执行时，使得所述一个或多个处理器执行如上所述的支付防抖方法。

根据本公开的再一方面，提供一种非暂时性机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如上所述的支付防抖方法。

利用本公开的方法和装置，在目前互联网规模以及复杂的企业级分布式架构体系下，为未来核心业务场景达到99.999％甚至更高的可用率目标提供高可用架构层面的保障，保障金融级别的稳定性，降低系统故障造成的公众影响，减少商户收款损失。

利用本公开的方法和装置，从通用高可用架构层面减少系统抖动、故障对核心业务带来的影响以及业务损失，提升整体业务链路的成功率，同时提升用户体验。

利用本公开的方法和装置，从端的视角重新审视业务链路，通过解耦、异构、异步化等思路可以反哺优化日常的业务链路，甚至可以对于一些业务场景升级为常态整体异步化的能力。

附图说明

通过参照下面的附图，可以实现对于本公开内容的本质和优点的进一步理解。在附图中，类似组件或特征可以具有相同的附图标记。

图1为线下收钱码支付业务所包括的各个支付阶段的示例；

图2示出了本公开实施例1提供的支付防抖方法的流程图；

图3为图2中所示的当前业务请求为支付过程的首次业务请求的示例；

图4为图2中所示的当前业务请求为支付过程的非首次业务请求的示例；

图5为一个示例提供的从客户端看到的支付的中间阶段返回的模拟正常结果的示意图；

图6为图5所示的支付示例的最后返回的模拟正常结果的示意图；

图7为本公开实施例2提供的支付防抖方法的整个支付过程的流程图；

图8为本公开一个实施例提供的支付防抖装置800的结构示意图；

图9为本公开另一个实施例提供的支付防抖装置900的结构示意图；

图10为本公开的一个实施例提供的实现支付防抖的计算设备的结构框图。

具体实施方式

现在将参考示例实施方式讨论本文描述的主题。应该理解，讨论这些实施方式只是为了使得本领域技术人员能够更好地理解从而实现本文描述的主题，并非是对权利要求书中所阐述的保护范围、适用性或者示例的限制。可以在不脱离本公开内容的保护范围的情况下，对所讨论的元素的功能和排列进行改变。各个示例可以根据需要，省略、替代或者添加各种过程或组件。例如，所描述的方法可以按照与所描述的顺序不同的顺序来执行，以及各个步骤可以被添加、省略或者组合。另外，相对一些示例所描述的特征在其它例子中也可以进行组合。

如本文中使用的，术语“包括”及其变型表示开放的术语，含义是“包括但不限于”。术语“基于”表示“至少部分地基于”。术语“一个实施例”和“一实施例”表示“至少一个实施例”。术语“另一个实施例”表示“至少一个其他实施例”。术语“第一”、“第二”等可以指代不同的或相同的对象。下面可以包括其他的定义，无论是明确的还是隐含的。除非上下文中明确地指明，否则一个术语的定义在整个说明书中是一致的。

一次支付过程包括一个支付阶段或多个支付阶段，本公开主要针对包括多阶段的支付业务。可以将客户端发起一次业务请求至下一次业务请求看作一个阶段或者将客户端发起一次业务请求至客户端显示支付完成看作一个阶段。例如，对于线下收钱码支付业务，如图1所示，客户端扫卖家的收钱码为第一次业务请求，从客户端发起第一次业务请求至客户端显示服务端返回的付款金额输入框为创建交易号的阶段110；用户向客户端显示的付款金额输入框输入支付的钱数后确认提交为第二次业务请求，从客户端发起第二次业务请求到客户端显示服务端返回的支付方式选项和支付密码输入框为拉起收银台的阶段120；用户通过客户端选择支付方式并输入支付密码后确认提交则为第三次业务请求，从客户端发起第三次业务请求至客户端显示服务端返回的“正在支付”的通知为提交支付的阶段130；发起的第四次业务请求调用轮询，查询订单的交易状态，如果交易成功，则客户端收到“付款成功”的通知，因此第四阶段为轮询支付结果的阶段140。可见，线下收钱码支付业务包括上述四个阶段。

因为服务端的分布式系统业务链路较长，比较容易发生抖动，所以为了避免支付过程因抖动而中断或出现错误，对于某次业务请求一旦服务端进行远程调用发生异常则对这次业务请求及其后各次业务请求均进行兜底处理。根据远程调用返回结果的错误码、异常和/或业务参数等识别业务抖动，对业务抖动进行兜底处理，返回模拟结果，记录兜底流水。可以根据兜底的流水触发异步恢复流程，从垫支账户打款给卖家。

图2示出了本公开实施例1提供的支付防抖方法的流程图，该过程可以由支付防抖装置执行。实施例1主要考虑支付过程中一次业务请求的处理。

如图2所示，在块210中，拦截客户端在支付过程中发送到服务端的当前业务请求，当前业务请求至少包括唯一阶段标识，其中，支付过程包括多个支付阶段，以及唯一阶段标识用于唯一标识当前业务请求所对应的支付阶段。

可以通过AOP拦截客户端发送到服务端的当前业务请求，其中，AOP为AspectOriented Programming的缩写，意为面向切面编程，是通过预编译方式和运行期动态代理实现程序功能的统一维护的一种技术。AOP可以理解为一个拦截器框架，但是这个拦截器会非常武断，如果它拦截一个类，那么它就会拦截这个类中的所有方法。

在块220中，基于与当前业务请求对应的防抖标记，确定针对当前业务请求的远程业务调用是否异常。作为该实施例的一方面，对于非首次业务请求所带的防抖标记的标记值为异常的情况，确定针对当前业务请求的远程业务调用为异常。对于在首次业务请求处理期间创建的防抖标记并且防抖标记的标记值为空的情况，以及非首次业务请求所带的防抖标记的标记值为正常的情况，都确定针对当前业务请求的远程业务调用为正常。

在块230中，当针对当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，兜底处理结果至少包括与唯一阶段标识所标识的支付阶段对应的模拟正常结果。

在块240中，将兜底处理结果发送给客户端。因此，从客户端看到的返回结果都是模拟的正常结果。

图3为在当前业务请求为支付过程的首次业务请求时的支付防抖方法的示例。

在块310中，支付防抖装置拦截客户端在支付过程中发送到服务端的首次业务请求，首次业务请求至少包括唯一阶段标识。

在块320中，解析所拦截的首次业务请求，以确定首次业务请求所属的业务类型。

在块330中，在所确定的业务类型属于需要防抖处理的业务类型时，为首次业务请求创建防抖标记，防抖标记用于指示本次支付业务是需要防抖处理的业务。在本公开的一个示例中，需要防抖处理的业务类型可以包括线下收钱码支付业务。防抖标记例如为appfuse_type。因为服务端为分布式系统，所以对业务请求进行处理需要进行远程业务调用。防抖标记的标记值用于指示远程业务调用是正常还是异常，异常指远程业务调用的链路发生抖动。防抖标记的标记值例如为normal或shake，其中shake代表抖动，normal表示正常，即没发生抖动。

在块340中，根据首次业务请求进行远程业务调用。这里可以由支付防抖装置作为上游系统向服务端的下游系统进行远程业务调用，作为替换方式，也可以由支付防抖装置指示服务端的上游系统向下游系统进行远程业务调用。

在块350中，基于远程业务调用返回的调用结果，确定针对首次业务请求的远程业务调用是否异常。如果远程业务调用返回的调用结果异常，则确定针对首次业务请求的远程业务调用异常，流程进行到块360。如果远程业务调用返回的调用结果正常，则确定针对首次业务请求的远程业务调用正常，流程进行到块380。

在块360中，为防抖标记赋予用于指示远程业务调用异常的标记值，比如shake，基于与唯一阶段标识所标识的支付阶段对应的模拟正常结果和防抖标记生成兜底处理结果。与唯一阶段标识所标识的支付阶段对应的模拟正常结果保存在支付防抖装置的存储器中，支付防抖装置解析所拦截的业务请求，根据解析出来的唯一阶段标识在其存储器中找到对应的模拟正常结果，从而生成兜底处理结果。流程进行到块370。

在块370中，将兜底处理结果发送给客户端。因此，从客户端看到的返回结果都是模拟的正常结果。

在块380中，为防抖标记赋予用于指示远程业务调用正常的标记值，比如normal，基于远程业务调用返回的调用结果和防抖标记生成正常处理结果。因此，正常处理结果包括远程业务调用返回的调用结果中的信息和防抖标记。流程进行到块390。

在块390中，将正常处理结果发送给客户端。

图4为当前业务请求为支付过程的非首次业务请求时的支付防抖方法的示例。

在块400中，支付防抖装置拦截客户端在支付过程中发送到服务端的非首次业务请求，非首次业务请求至少包括唯一阶段标识和防抖标记。其中，防抖标记是上一业务请求处理过程所返回的防抖标记。

在块410中，判断非首次业务请求所包括的防抖标记的标记值指示远程业务调用是否异常。如果防抖标记的标记值指示远程业务调用异常，则确定针对非首次业务请求的远程业务调用异常，流程进行到块420。如果防抖标记的标记值指示远程业务调用正常，则流程进行到块440。

在块420中，生成兜底处理结果，兜底处理结果包括与唯一阶段标识所标识的支付阶段对应的模拟正常结果和防抖标记，防抖标记具有用于指示远程业务调用异常的标记值，比如shake。流程进行到块430。

在块430中，将兜底处理结果发送给客户端。因此，从客户端看到的返回结果都是模拟的正常结果。图5为一个示例提供的从客户端看到的支付的中间阶段返回的模拟正常结果的示意图。图6为图5所示的支付示例的最后阶段返回的模拟正常结果的示意图。

在块440中，根据非首次业务请求进行远程业务调用。流程进行到块450。

在块450中，基于远程业务调用返回的调用结果是否异常，确定针对非首次业务请求的远程业务调用是否异常。如果调用结果异常比如SYSTEM_ERROR时，则确定远程业务调用异常，流程进行到块460。如果调用结果正常，则确定远程业务调用正常，流程进行到块480。

在块460中，为防抖标记赋予用于指示远程业务调用异常的标记值，比如shake，基于与唯一阶段标识所标识的支付阶段对应的模拟正常结果和防抖标记生成兜底处理结果。流程进行到块470。

在块470中，将兜底处理结果发送给客户端。

在块480中，生成正常处理结果，正常处理结果包括远程业务调用返回的调用结果中的信息和防抖标记，防抖标记具有用于指示远程业务调用正常的标记值，比如normal。流程进行到块490。

在块490中，将正常处理结果发送给客户端。

作为一个可选实施例，在图3的块360和/或图4的块460中为防抖标记赋予用于指示远程业务调用异常的标记值之前，该实施例的支付防抖方法还可以包括抖动识别步骤。抖动识别步骤可以包括：识别远程业务调用异常是否为能够进行兜底处理的异常，在识别出远程业务调用异常是能够进行兜底处理的异常时，为防抖标记赋予用于指示远程业务调用异常的标记值并包括在兜底处理结果中。

如果当前的业务请求包括支付信息，支付防抖装置可以记录业务请求中的支付信息和多阶段上下文的状态缓存。支付信息可以包括订单金额、付款账户、以及收款账户等信息，根据支付信息生成订单，订单可以包括流水号。此外，与支付过程对应的支付信息还可以来自服务端。记录支付信息以便于在同步兜底处理之后进行防抖异步恢复。多阶段上下文的状态缓存是多阶段状态中防抖需要用到的信息。作为一个可选实施例，在当前业务请求是支付过程的最后业务请求时，该实施例的支付防抖方法还可以包括：在将兜底处理结果发送给客户端后，根据与支付过程对应的支付信息，从垫支账户中支付相应数目的支付款给卖家。从垫支账户中支付相应数目的支付款给卖家的过程可以称为异步恢复流程，因为这个过程是以异步恢复方式完成的。在从垫支账户中支付相应数目的支付款给卖家之前，该实施例的支付防抖方法还可以包括：响应于从垫支账户中支付相应数目的支付款给卖家，通知卖家相应数目的支付款已到账。通知卖家可以采用语音播报、短信通知、或者其他任何现有的方式。

在同步兜底处理之后，异步恢复流程可以通过实时、定时、或者手动等方式触发。其中，异步恢复的过程与前述业务请求的处理过程在分布式系统中经由的链路大概率是不同的链路，也有可能是相同的链路。通常异步恢复流程是以实时方式触发，大约从通知卖家支付款已到账时起的例如1～2秒钟后从垫支账户打相应数目的支付款到卖家的账户。在极少数情况下，如果以实时方式触发异步恢复流程时系统仍然有故障，则可以定时方式从通知卖家支付款已到账时起经过预设时长后从垫支账户打支付款到卖家的账户。在极特殊情况下，如果以定时方式触发异步恢复流程时系统仍然有故障，则可以人工介入以手动方式从垫支账户打支付款到卖家的账户。

整个支付过程对用户而言是有体感的，看到的是免单优惠，如图5和

图6所示，对卖家而言是无感知的，用户支付完成后，同步地使卖家收到语音播报或短信通知等，而在资金处理方面需要在防抖异步恢复的时候从支付垫资账户打款给卖家，而买家账户没有资金变动而且可以事后从买家账户追款或者不从买家账户追款。

图7为本公开实施例2提供的支付防抖方法的整个支付过程的流程图，实施例2以本次支付过程包括3个阶段为例。其中，支付防抖装置为承担防抖能力的基础功能模块，支付防抖装置可以是接入服务端中的组件，也可以是客户端和服务端之间的独立装置。

如图7所示，在700，支付防抖装置拦截客户端在支付过程中发送到服务端的第一次业务请求，第一次业务请求包括唯一阶段标识，其中，唯一阶段标识用于唯一标识当前业务请求所对应的第一支付阶段。

在705，为第一次业务请求创建防抖标记，比如appfuse_type，以标识本次支付为需要防抖的业务。

在710，根据第一次业务请求进行远程业务调用。

在715，基于远程业务调用返回的调用结果是否异常，确定针对第一次业务请求的远程业务调用是否异常。在确定远程业务调用正常时，为防抖标记赋予用于指示远程业务调用正常的标记值，比如normal，基于远程业务调用返回的调用结果和防抖标记生成正常处理结果。

在720，将正常处理结果发送给客户端。

在725，支付防抖装置拦截客户端在支付过程中发送到服务端的第二次业务请求，第二次业务请求包括唯一阶段标识和防抖标记，其中，唯一阶段标识用于唯一标识当前业务请求所对应的第二支付阶段，防抖标记具有用于指示远程业务调用正常的标记值，比如normal。

在730，根据第二次业务请求进行远程业务调用。

在735，基于远程业务调用返回的调用结果异常，确定针对第二次业务请求的远程业务调用异常。

在740，在确定远程业务调用异常时，识别远程业务调用异常是否为能够进行兜底处理的异常，即识别返回的调用结果的错误码是否在兜底的范围内，如果在兜底范围内则进行兜底处理。

在745，在识别出异常为能够进行兜底处理的异常时，为防抖标记赋予用于指示远程业务调用异常的标记值，比如shake，基于与唯一阶段标识所标识的第二支付阶段对应的模拟正常结果和防抖标记生成兜底处理结果。

在750，将兜底处理结果发送给客户端。

在755，支付防抖装置拦截客户端在支付过程中发送到服务端的最后业务请求，最后业务请求包括唯一阶段标识和防抖标记，其中，唯一阶段标识用于唯一标识当前业务请求所对应的最后支付阶段，该防抖标记具有用于指示远程业务调用异常的标记值，比如shake。

在760，基于防抖标记的标记值指示远程业务调用异常，确定针对最后业务请求的远程业务调用异常。

在765，生成兜底处理结果，兜底处理结果包括与唯一阶段标识所标识的最后支付阶段对应的模拟正常结果和防抖标记，防抖标记具有用于指示远程业务调用异常的标记值，比如shake。

在770，将兜底处理结果发送给客户端。

在775，客户端显示完成本次支付，用户看到的都是模拟正常结果。

在780，启动异步恢复过程，以实现业务的最终一致。

在785，根据与该支付过程对应的支付信息，从垫支账户中支付相应数目的支付款给卖家。

该实施例的支付防抖方法还可以包括：响应于从垫支账户中支付相应数目的支付款给卖家，通知卖家相应数目的支付款已到账。通知卖家可以采用语音播报、短信通知、或者其他任何现有的方式。

由实施例2可见，对于防抖处理的业务，除了本次支付的最后一次业务请求，对于之前的每一次业务请求，支付防抖装置均在发送返回结果给客户端的同时，发送具有标记值的防抖标记给客户端。客户端发送下一次业务请求的时候会带上该防抖标记，再次进入到支付防抖装置内，如果防抖标记的防抖值指示远程业务调用异常，则会被识别为这个支付过程上一阶段已经被兜底处理，当次阶段继续走兜底流程，直到用户完成这次支付。当然，对于本次支付的最后一次业务请求，支付防抖装置发送返回结果给客户端，也可以同时发送具有标记值的防抖标记给客户端，只是这一阶段是支付过程的最后阶段，后面不会再有客户端发送的业务请求了，因此发送防抖标记给客户端的话信息不够简洁。另外，如果对于当前业务请求进行远程业务调用异常，支付防抖装置在发送返回结果的同时发送具有用于指示远程业务调用异常的标记值的防抖标记给客户端，对于客户端后续发起的业务请求，支付防抖装置都不再发送防抖标记给客户端，则虽然发送给客户端的信息简洁，但是需要修改客户端的程序。

本公开的支付防抖方法不限于上述各实施例所公开的技术方案，上面公开的对于支付过程一次业务请求处理的各个实施例可以在不偏离发明实质的情况下做出各种组合、变形和修改，此外，整个支付过程的各个阶段的各个实施例也可以在不偏离发明实质的情况下做出各种组合、变形和修改。

利用本公开的方案，从通用高可用架构层面减少服务端的链路抖动、故障对业务带来的影响以及业务损失，提升整体业务链路的成功率，同时提升用户体验。

利用本公开的方案，在目前互联网规模以及复杂的企业级分布式架构体系下，为未来核心业务场景达到99.999％甚至更高的可用率目标提供高可用架构层面的保障，保障金融级别的稳定性，降低系统抖动造成的公众影响，减少商户收款损失。

图8为本公开一个实施例提供的支付防抖装置800的结构示意图。其中，支付防抖装置既可以为一个独立的装置，也可以为接入服务端的组件。如图8所示，该实施例的支付防抖装置800可以包括：拦截单元810、异常确定单元820、兜底处理单元830、以及发送单元840。

拦截单元810被配置为拦截客户端在支付过程中发送到服务端的当前业务请求，当前业务请求至少包括唯一阶段标识，其中，支付过程包括多个支付阶段，以及唯一阶段标识用于唯一标识当前业务请求所对应的支付阶段。拦截单元810的操作可以参照上面参考图2描述的块210的操作。

异常确定单元820被配置为基于与当前业务请求对应的防抖标记，确定针对当前业务请求的远程业务调用是否异常。异常确定单元820的操作可以参照上面参考图2描述的块220的操作。

兜底处理单元830被配置为在针对当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，兜底处理结果至少包括与唯一阶段标识所标识的支付阶段对应的模拟正常结果。兜底处理单元830的操作可以参照上面参考图2描述的块230的操作。

发送单元840被配置为将兜底处理结果发送给客户端。发送单元840的操作可以参照上面参考图2描述的块240的操作。

图9为本公开另一个实施例提供的支付防抖装置900的结构示意图。如图9所示，该实施例的支付防抖装置900可以包括：拦截单元910、防抖标记创建单元920、异常确定单元930、业务调用单元940、兜底处理单元950、标记值调整单元960、以及发送单元970。

拦截单元910被配置为拦截客户端在支付过程中发送到服务端的当前业务请求，当前业务请求至少包括唯一阶段标识，其中，支付过程包括多个支付阶段，以及唯一阶段标识用于唯一标识当前业务请求所对应的支付阶段。拦截单元910的操作可以参照上面参考图7描述的700、725和755的操作。

防抖标记创建单元920，被配置为在当前业务请求是首次业务请求时，在拦截到当前业务请求后为当前业务请求创建防抖标记。防抖标记创建单元920的操作可以参照上面参考图7描述的705的操作。

异常确定单元930被配置为基于与当前业务请求对应的防抖标记，确定针对当前业务请求的远程业务调用是否异常。异常确定单元930还可以被配置为在防抖标记的标记值指示远程业务调用异常时，确定针对当前业务请求的远程业务调用异常。异常确定单元930的操作可以参照上面参考图7描述的735和760的操作。

业务调用单元940被配置为在防抖标记的标记值指示远程业务调用正常时，根据当前业务请求执行远程业务调用。作为该实施例的一方面，对于在首次业务请求处理期间创建防抖标记并且防抖标记的标记值为空的情况，以及非首次业务请求所带的防抖标记的标记值为正常的情况，都认为防抖标记的标记值指示远程业务调用正常。业务调用单元940的操作可以参照上面参考图7描述的710和730的操作。异常确定单元930还可以被配置为基于远程业务调用的返回结果是否异常，确定针对当前业务请求的远程业务调用是否异常。异常确定单元930的操作可以参照上面参考图7描述的735的操作。

兜底处理单元950被配置为在针对当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，兜底处理结果至少包括与唯一阶段标识所标识的支付阶段对应的模拟正常结果。兜底处理单元950的操作可以参照上面参考图7描述的745和765的操作。

标记值调整单元960被配置为在远程业务调用的返回结果异常时，为防抖标记赋予用于指示远程业务调用异常的标记值并包括在兜底处理结果中。标记值调整单元960的操作可以参照上面参考图7描述的745的操作。

发送单元970被配置为将兜底处理结果发送给客户端。发送单元970的操作可以参照上面参考图7描述的750和770的操作。

作为该实施例的一方面，该实施例的支付防抖装置还可以包括正常处理单元。正常处理单元被配置为在针对当前业务请求的远程业务调用被确定为正常时，生成正常处理结果，正常处理结果至少包括远程业务调用返回的调用结果中的信息。正常处理单元的操作可以参照上面参考图7描述的715的操作。标记值调整单元960还可以被配置为在远程业务调用的返回结果正常时，确定针对当前业务请求的远程业务调用正常，为防抖标记赋予用于指示远程业务调用正常的标记值并包括在正常处理结果中。标记值调整单元960的操作可以参照上面参考图7描述的715的操作。发送单元970还可以被配置为将正常处理结果发送给客户端。发送单元970的操作可以参照上面参考图7描述的720的操作。

作为该实施例的另一方面，该实施例的支付防抖装置还可以包括业务类型确定单元。业务类型确定单元被配置为在当前业务请求是首次业务请求时，在拦截到当前业务请求后，解析所拦截的当前业务请求，以确定当前业务请求所属的业务类型。业务类型确定单元的操作可以参照上面参考图3描述的块320的操作。防抖标记创建单元920还可以被配置为在所确定的业务类型属于需要防抖处理的业务类型时，为当前业务请求创建防抖标记。标记创建单元920的操作可以参照上面参考图3描述的块330的操作。

作为该实施例的又一方面，该实施例的支付防抖装置还可以包括异常识别单元。异常识别单元被配置为在远程业务调用的返回结果异常时，识别远程业务调用异常是否为能够进行兜底处理的异常。异常识别单元的操作可以参照上面参考图7描述的740的操作。标记值调整单元960还可以被配置为在识别出远程业务调用异常是能够进行兜底处理的异常时，为防抖标记赋予用于指示远程业务调用异常的标记值并包括在兜底处理结果中。标记值调整单元960的操作可以参照上面参考图7描述的745的操作。

作为该实施例的在一方面，该实施例的支付防抖装置还可以包括支付处理单元。在当前业务请求是所述支付过程的最后业务请求时，在将兜底处理结果发送给客户端后，根据与支付过程对应的支付信息，从垫支账户中支付相应数目的支付款给卖家。支付处理单元的操作可以参照上面参考图7描述的780-785的操作。

本公开的支付防抖装置不限于上述各实施例所公开的技术方案，上面公开的各个实施例可以在不偏离发明实质的情况下做出各种组合、变形和修改。

如上参照图2-9，对本公开的支付防抖方法及装置的实施例进行了描述。应当理解的是，以上对于方法实施例的细节描述同样适用于装置实施例。以上的支付防抖装置可以采用硬件实现，也可以采用软件或者硬件和软件的组合来实现。

图10是本公开的一个实施例提供的实现支付防抖的计算设备的结构框图。

如图10所示，计算设备1000可以包括至少一个处理器1010、存储器1020、内存1030、通信接口1040以及内部总线1050，该至少一个处理器1010执行在计算机可读存储介质(即，存储器1020)中存储或编码的至少一个计算机可读指令(即，上述以软件形式实现的元素)。

在一个实施例中，在存储器1020中存储有计算机可执行指令，其当执行时使得至少一个处理器1010：拦截客户端在支付过程中发送到服务端的当前业务请求，当前业务请求至少包括唯一阶段标识，其中，支付过程包括多个支付阶段，以及唯一阶段标识用于唯一标识当前业务请求所对应的支付阶段；基于与当前业务请求对应的防抖标记，确定针对当前业务请求的远程业务调用是否异常；在针对当前业务请求的远程业务调用被确定为异常时，生成兜底处理结果，兜底处理结果至少包括与唯一阶段标识所标识的支付阶段对应的模拟正常结果；以及将兜底处理结果发送给客户端。

应该理解的是，在存储器1020中存储的计算机可执行指令当执行时使得至少一个处理器1010进行本公开的各个实施例中以上结合图2-9描述的各种操作和功能。

在本公开中，计算设备1000可以包括但不限于：个人计算机、服务器计算机、工作站、桌面型计算机、膝上型计算机、笔记本计算机、移动计算设备、智能电话、平板计算机、蜂窝电话、个人数字助理(PDA)、手持装置、消息收发设备、可佩戴计算设备、消费电子设备等等。

根据一个实施例，提供了一种例如非暂时性机器可读介质的程序产品。非暂时性机器可读介质可以具有指令(即，上述以软件形式实现的元素)，该指令当被机器执行时，使得机器执行本公开的各个实施例中以上结合图2-9描述的各种操作和功能。

具体地，可以提供配有可读存储介质的系统或者装置，在该可读存储介质上存储着实现上述实施例中任一实施例的功能的软件程序代码，且使该系统或者装置的计算机或处理器读出并执行存储在该可读存储介质中的指令。

在这种情况下，从可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能，因此机器可读代码和存储机器可读代码的可读存储介质构成了本发明的一部分。

可读存储介质的实施例包括软盘、硬盘、磁光盘、光盘(如CD-ROM、CD-R、CD-RW、DVD-ROM、DVD-RAM、DVD-RW、DVD-RW)、磁带、非易失性存储卡和ROM。可选择地，可以由通信网络从服务器计算机上或云上下载程序代码。

本领域技术人员应当理解，上面公开的各个实施例可以在不偏离发明实质的情况下做出各种变形和修改。因此，本发明的保护范围应当由所附的权利要求书来限定。

需要说明的是，上述各流程和各系统结构图中不是所有的步骤和单元都是必须的，可以根据实际的需要忽略某些步骤或单元。各步骤的执行顺序不是固定的，可以根据需要进行确定。上述各实施例中描述的装置结构可以是物理结构，也可以是逻辑结构，即，有些单元可能由同一物理实体实现，或者，有些单元可能分由多个物理实体实现，或者，可以由多个独立设备中的某些部件共同实现。

以上各实施例中，硬件单元或模块可以通过机械方式或电气方式实现。例如，一个硬件单元、模块或处理器可以包括永久性专用的电路或逻辑(如专门的处理器，FPGA或ASIC)来完成相应操作。硬件单元或处理器还可以包括可编程逻辑或电路(如通用处理器或其它可编程处理器)，可以由软件进行临时的设置以完成相应操作。具体的实现方式(机械方式、或专用的永久性电路、或者临时设置的电路)可以基于成本和时间上的考虑来确定。

上面结合附图阐述的具体实施方式描述了示例性实施例，但并不表示可以实现的或者落入权利要求书的保护范围的所有实施例。在整个本说明书中使用的术语“示例性”意味着“用作示例、实例或例示”，并不意味着比其它实施例“优选”或“具有优势”。出于提供对所描述技术的理解的目的，具体实施方式包括具体细节。然而，可以在没有这些具体细节的情况下实施这些技术。在一些实例中，为了避免对所描述的实施例的概念造成难以理解，公知的结构和装置以框图形式示出。

本公开内容的上述描述被提供来使得本领域任何普通技术人员能够实现或者使用本公开内容。对于本领域普通技术人员来说，对本公开内容进行的各种修改是显而易见的，并且，也可以在不脱离本公开内容的保护范围的情况下，将本文所定义的一般性原理应用于其它变型。因此，本公开内容并不限于本文所描述的示例和设计，而是与符合本文公开的原理和新颖性特征的最广范围相一致。

Claims (12)

1.一种由支付防抖装置执行的支付防抖方法，包括：

拦截客户端在支付过程中发送到服务端的当前业务请求，所述当前业务请求包括唯一阶段标识，其中，所述支付过程包括多个支付阶段，以及所述唯一阶段标识用于唯一标识所述当前业务请求所对应的支付阶段；

基于与所述当前业务请求对应的防抖标记，确定针对所述当前业务请求的远程业务调用是否异常；

在所述防抖标记的标记值指示所述当前业务请求的远程业务调用异常时，

从所述支付防抖装置的存储器中获取与所述唯一阶段标识对应的模拟正常结果；

基于所述模拟正常结果以及所述防抖标记生成兜底处理结果；以及

将所述兜底处理结果发送给所述客户端；

在所述防抖标记的标记值指示所述当前业务请求的远程业务调用正常时，

根据所述当前业务请求执行远程业务调用；以及

在所述远程业务调用的返回结果正常时，

基于所述远程业务调用的正常返回结果以及所述防抖标记生成正常处理结果；以及

将所述正常处理结果发送给所述客户端，

在所述远程业务调用的返回结果异常时，

为所述防抖标记赋予用于指示远程业务调用异常的标记值；

从所述支付防抖装置的存储器中获取与所述唯一阶段标识对应的模拟正常结果；

基于所述模拟正常结果以及所述防抖标记生成兜底处理结果；以及

将所述兜底处理结果发送给所述客户端，

其中，在所述当前业务请求是首次业务请求时，所述防抖标记是在拦截到所述当前业务请求后创建的，或者在所述当前业务请求是非首次业务请求时，所述防抖标记是上一支付阶段所返回的兜底处理结果或正常处理结果中的防抖标记。

2.如权利要求1所述的方法，其中，在所述远程业务调用的返回结果异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值包括：

在确定针对所述当前业务请求的远程业务调用异常时，识别所述远程业务调用异常是否为能够进行兜底处理的异常；以及

在识别出所述远程业务调用异常是能够进行兜底处理的异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值。

3.如权利要求1所述的方法，其中，在所述当前业务请求是首次业务请求时，通过下述过程来为所述当前业务请求创建防抖标记：

在拦截到所述当前业务请求后，解析所拦截的当前业务请求，以确定所述当前业务请求所属的业务类型；

在所确定的业务类型属于需要防抖处理的业务类型时，为所述当前业务请求创建所述防抖标记。

4.如权利要求3所述的方法，其中，所述需要防抖处理的业务类型包括线下收钱码支付业务。

5.如权利要求1所述的方法，其中，在所述当前业务请求是所述支付过程的最后业务请求时，所述方法还包括：

在将所述兜底处理结果发送给所述客户端后，根据与所述支付过程对应的支付信息，从垫支账户中支付相应数目的支付款给卖家。

6.如权利要求5所述的方法，还包括：响应于从垫支账户中支付相应数目的支付款给卖家，通知所述卖家相应数目的支付款已到账。

7.一种基于计算设备实现的支付防抖装置，包括：

一个或多个处理器，以及

与所述一个或多个处理器耦合的存储器，所述存储器存储指令，当所述指令被所述一个或多个处理器执行时，使得所述一个或多个处理器执行：

拦截客户端在支付过程中发送到服务端的当前业务请求，所述当前业务请求包括唯一阶段标识，其中，所述支付过程包括多个支付阶段，以及所述唯一阶段标识用于唯一标识所述当前业务请求所对应的支付阶段；

基于与所述当前业务请求对应的防抖标记，确定针对所述当前业务请求的远程业务调用是否异常；

在所述防抖标记的标记值指示所述当前业务请求的远程业务调用异常时，

从所述支付防抖装置的存储器中获取与所述唯一阶段标识对应的模拟正常结果；

基于所述模拟正常结果以及所述防抖标记生成兜底处理结果；以及

将所述兜底处理结果发送给所述客户端；

在所述防抖标记的标记值指示所述当前业务请求的远程业务调用正常时，

根据所述当前业务请求执行远程业务调用；以及

在所述远程业务调用的返回结果正常时，

基于所述远程业务调用的正常返回结果以及所述防抖标记生成正常处理结果；以及

将所述正常处理结果发送给所述客户端，

在所述远程业务调用的返回结果异常时，

为所述防抖标记赋予用于指示远程业务调用异常的标记值；

从所述支付防抖装置的存储器中获取与所述唯一阶段标识对应的模拟正常结果；

基于所述模拟正常结果以及所述防抖标记生成兜底处理结果；以及

将所述兜底处理结果发送给所述客户端，

其中，在所述当前业务请求是首次业务请求时，所述防抖标记是在拦截到所述当前业务请求后创建的，或者在所述当前业务请求是非首次业务请求时，所述防抖标记是上一支付阶段所返回的兜底处理结果或正常处理结果中的防抖标记。

8.如权利要求7所述的支付防抖装置，其中，当所述指令被所述一个或多个处理器执行时，使得所述一个或多个处理器执行：

在所述远程业务调用的返回结果异常时，识别所述远程业务调用异常是否为能够进行兜底处理的异常；以及

在识别出所述远程业务调用异常是能够进行兜底处理的异常时，为所述防抖标记赋予用于指示远程业务调用异常的标记值。

9.如权利要求7所述的支付防抖装置，其中，当所述指令被所述一个或多个处理器执行时，使得所述一个或多个处理器执行：

在所述当前业务请求是首次业务请求时，在拦截到所述当前业务请求后，解析所拦截的当前业务请求，以确定所述当前业务请求所属的业务类型；以及

在所确定的业务类型属于需要防抖处理的业务类型时，为所述当前业务请求创建所述防抖标记。

10.如权利要求7所述的支付防抖装置，其中，当所述指令被所述一个或多个处理器执行时，使得所述一个或多个处理器执行：

在所述当前业务请求是所述支付过程的最后业务请求时，在将所述兜底处理结果发送给所述客户端后，根据与所述支付过程对应的支付信息，从垫支账户中支付相应数目的支付款给卖家。

11.如权利要求10所述的支付防抖装置，其中，当所述指令被所述一个或多个处理器执行时，使得所述一个或多个处理器进一步执行：

响应于从垫支账户中支付相应数目的支付款给卖家，通知所述卖家相应数目的支付款已到账。

12.一种非暂时性机器可读存储介质，其存储有可执行指令，所述指令当被执行时使得所述机器执行如权利要求1到6中任一项所述的方法。

Images