调用请求的处理方法、装置和计算机存储介质与流程

本发明涉及信息处理技术领域，特别涉及一种调用请求的处理方法、装置和计算机存储介质。

背景技术：

随着电子信息技术的发展，由多个通过互联网连接的服务组成的交易系统得到了广泛的应用。客户端可以向交易系统提交交易请求，使得交易系统的各个服务依次按自身的业务处理逻辑处理交易请求。

上述处理过程中，各个服务通过服务调用的方式进行交互，上游服务会将需要下游服务处理的业务数据以调用请求的方式发送给下游服务，使下游服务处理并反馈处理结果。

现有的服务调用过程中，针对一笔交易，下游服务超过一定时间未反馈(即服务超时)后，上游服务会再次发送这笔交易对应的调用请求，若下游服务接收这笔交易对应的每一次调用请求，并对每次收到的调用请求均进行相应的处理，就会导致这笔交易出现错误，例如重复扣款，重复下单等。因此，目前亟需一种避免服务超时后同一笔交易的多次调用请求被重复处理的方法。

技术实现要素：

基于上述现有技术的缺点，本申请提供一种调用请求的处理方法、装置和计算机存储介质，以解决交易系统中下游服务重复处理相同的调用请求的问题。

本申请第一方面提供一种调用请求的处理方法，应用于第一服务，所述第一服务是由多个服务构成的交易系统中的任意一个服务，所述处理方法包括：

接收第二服务生成的与客户端提交的交易请求对应的第一调用请求；其中，所述第一调用请求包括业务数据和基于所述交易请求生成的交易标识，所述第二服务是所述第一服务的上游服务；

分别在所述第一服务的数据缓存区和数据库中查找所述交易标识；

若所述数据缓存区和所述数据库中均未存储所述交易标识，确定所述第一调用请求是所述第一服务首次接收的与所述交易请求对应的调用请求，按所述第一服务的业务处理逻辑处理所述业务数据，并将所述交易标识写入所述数据缓存区和所述数据库中；

若所述数据缓存区和/或所述数据库中存储所述交易标识，确定所述第一调用请求不是所述第一服务首次接收的与所述交易请求对应的调用请求，并删除所述第一调用请求；

将所述第一服务首次接收的与所述交易请求对应的调用请求的处理结果反馈给所述第二服务。

可选的，所述将所述第一服务首次接收的与所述交易请求对应的调用请求的处理结果反馈给所述第二服务，包括：

判断所述第一服务首次接收的与所述交易请求对应的调用请求是否处理成功；

若处理成功，获取所述第一服务首次接收的与所述交易请求对应的调用请求的处理结果并将所述处理结果反馈给所述第二服务；

若未处理成功，按当前的处理进度继续处理所述第一服务首次接收的与所述交易请求对应的调用请求的业务数据，并在处理成功后将处理结果反馈给所述第二服务。

本申请第二方面提供一种调用请求的处理方法，应用于第二服务，所述第二服务是由多个服务构成的交易系统中的任意一个服务，所述处理方法包括：

响应于客户端提交的交易请求，生成与所述交易请求对应的第一调用请求；其中，所述第一调用请求包括业务数据和基于所述交易请求生成的交易标识；

将所述第一调用请求发送至第一服务，使所述第一服务根据所述交易标识判断是否处理所述第一调用请求携带的所述业务数据，并等待所述第一服务反馈所述业务数据的处理结果；其中，所述第二服务是所述第一服务的上游服务；

判断等待时间是否大于或等于预设的超时时长；

若所述等待时间大于或等于所述超时时长，向所述客户端发送第一提示信息，并再次将所述第一调用请求发送至所述第一服务，直至所述第一服务反馈所述业务数据的处理结果为止；其中，所述第一提示信息用于指示所述交易请求正在被处理。

可选的，所述响应于客户端提交的交易请求，生成与所述交易请求对应的第一调用请求，包括：

接收第三服务基于客户端提交的交易请求生成的第二调用请求，并根据所述第二调用请求携带的业务数据生成所述交易请求对应的第一调用请求；其中，所述第三服务是所述第二服务的上游服务。

可选的，所述生成与所述交易请求对应的第一调用请求，包括：

按所述第二服务的业务处理逻辑处理所述交易请求携带的业务数据，并将得到的处理结果作为所述交易请求对应的第一调用请求的业务数据；

利用所述客户端提交所述交易请求的时间和处理所述业务数据的服务器的服务器编号生成所述交易请求的交易标识；

组合所述业务数据和所述交易标识，得到所述交易请求对应的第一调用请求。

本申请第三方面提供一种调用请求的处理装置，应用于第一服务，所述第一服务是由多个服务构成的交易系统中的任意一个服务，所述处理装置包括：

接收单元，用于接收第二服务生成的与客户端提交的交易请求对应的第一调用请求；其中，所述第一调用请求包括业务数据和基于所述交易请求生成的交易标识，所述第二服务是所述第一服务的上游服务；

查找单元，用于分别在所述第一服务的数据缓存区和数据库中查找所述交易标识；

处理单元，若所述数据缓存区和所述数据库均未存储所述交易标识，用于确定所述第一调用请求是所述第一服务首次接收的与所述交易请求对应的调用请求，并按预设的业务处理逻辑处理所述业务数据；

写入单元，若所述第一调用请求是所述第一服务首次接收的与所述交易请求对应的调用请求，用于将所述交易标识写入所述数据缓存区和所述数据库中；

删除单元，若所述数据缓存区和/或所述数据库存储所述交易标识，用于确定所述第一调用请求不是所述第一服务首次接收的与所述交易请求对应的调用请求，并删除所述第一调用请求；

反馈单元，用于将所述第一服务首次接收的与所述交易请求对应的调用请求的处理结果反馈给所述第二服务。

可选的，所述反馈单元将所述第一服务首次接收的与所述交易请求对应的调用请求的处理结果反馈给所述第二服务时，具体用于：

判断所述第一服务首次接收的与所述交易请求对应的调用请求是否处理成功；

若处理成功，获取所述第一服务首次接收的与所述交易请求对应的调用请求的处理结果并将所述处理结果反馈给所述第二服务；

若未处理成功，按当前的处理进度继续处理所述第一服务首次接收的与所述交易请求对应的调用请求的业务数据，并在处理成功后将处理结果反馈给所述第二服务。

本申请第四方面提供一种调用请求的处理装置，应用于第二服务，所述第二服务是由多个服务构成的交易系统中的任意一个服务，所述处理装置包括：

生成单元，用于响应于客户端提交的交易请求，生成与所述交易请求对应的第一调用请求；其中，所述第一调用请求包括业务数据和基于所述交易请求生成的交易标识；

发送单元，用于将所述第一调用请求发送至第一服务，使所述第一服务根据所述交易标识判断是否处理所述第一调用请求携带的所述业务数据，并等待所述第一服务反馈所述业务数据的处理结果；其中，所述第二服务是所述第一服务的上游服务；

判断单元，用于判断等待时间是否大于或等于预设的超时时长，若等待时间大于或等于所述超时时长，触发所述发送单元再次将所述第一调用请求发送至所述第一服务，直至所述第一服务反馈所述业务数据的处理结果为止；

提示单元，用于若所述等待时间大于或等于所述超时时长，向所述客户端发送第一提示信息；其中，所述第一提示信息用于指示所述交易请求正在被处理。

可选的，所述生成单元响应于客户端提交的交易请求，生成与所述交易请求对应的第一调用请求时，具体用于：

接收第三服务基于客户端提交的交易请求生成的第二调用请求，并根据所述第二调用请求携带的业务数据生成所述交易请求对应的第一调用请求；其中，所述第三服务是所述第二服务的上游服务。

本申请第五方面提供一种计算机存储介质，其特征在于，用于存储程序，所述程序被执行时，具体用于实现本申请第一方面任意一项所提供的调用请求的处理方法，或者用于实现本申请第二方面任意一项所提供的调用请求的处理方法。

本申请提供一种调用请求的处理方法、装置和计算机存储介质，第一服务接收上游的第二服务根据客户的交易请求生成的第一调用请求；分别在数据缓存区和数据库中查找第一调用请求携带的交易标识，并根据查找结果判断第一调用请求是否为首次接收的与交易请求对应的调用请求；若第一调用请求是首次接收的与交易请求对应的调用请求，基于业务处理逻辑处理其中的业务数据，将交易标识写入数据缓存区和数据库中；若第一调用请求不是首次接收的与交易请求对应的调用请求，删除第一调用请求；将第一服务首次接收的与交易请求对应的调用请求的处理结果反馈给第二服务。第一服务通过记录首次收到的调用请求的交易标识，避免重复处理同一笔交易的多次调用请求，从而防止由于重复操作引起的交易错误。

附图说明

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

图1为本申请实施例提供的一种调用请求的处理方法的流程图；

图2为本申请实施例提供的一种调用请求的处理装置的结构示意图；

图3为本申请实施例提供的一种调用请求的处理装置的结构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了方便理解本申请实施例提供的方法，下面首先对本申请提供的方法的背景进行简要介绍。

一个网络上的交易系统(例如，各个商业银行的网上银行平台)包括多个相互之间具有一定业务关联的服务，在客户向交易系统提出一个交易请求后，交易系统中的各个服务会按自身预先设定的业务处理逻辑，以及各个服务之间的业务关联选择性的参与交易请求的处理。在处理过程中，若一个服务进行处理时需要用到另一个服务提供的业务数据，那么在这两个服务中，前者就可以成为下游服务，后者则成为上游服务，上游服务可以通过向下游服务发送调用请求的方式将需要下游服务处理的业务数据传递给下游服务。

例如，在购物流程中涉及生成商品订单的订单服务，以及依据订单中的金额进行扣款的支付服务，显然，支付服务需要用到订单服务提供的商品订单，因此，订单服务是支付服务的上游服务，支付服务是订单服务的下游服务。

可以理解的，一个服务可以在某一个处理步骤中是下游服务，在另一个处理步骤中则是上游服务。也就是说，对于交易系统中的任意一个服务，该服务可以被某个服务a调用，此时该服务作为下游服务，同时，在被服务a调用处理特定业务数据的过程中，该服务也可以调用另一个服务b，此时该服务作为上游服务。一个交易系统中具体哪些服务在什么情况是上游服务，在什么情况下是下游服务由各个服务的业务处理逻辑以及服务间的业务关联性决定。

在交易系统中，当上游服务调用下游服务时，下游服务可能会出现服务超时的现象。服务超时是指，上游服务向下游服务发送调用请求，经过一段预设的超时时长后下游服务仍未反馈与这一调用请求对应处理结果，这种情况下就认为下游服务出现服务超时。

可以理解的，下游服务的服务超时可能由两方面原因造成，一方面，下游服务和上游服务的通信链路出现故障，导致下游服务未能接收到上游服务发送的调用请求，因此下游服务无法给出反馈。另一方面，下游服务需要处理的数据量较大，导致上游服务发送的调用请求被处理的速度比标准的处理速度慢，或者调用请求被暂停处理。

现有技术中，在下游服务出现服务超时现象时，上游服务会再次发送相同的调用请求，若第二次发送的调用请求又出现服务超时，则上游服务第三次发送相同的调用请求，以此类推，直至下游服务返回调用请求对应的处理结果为止。在服务超时后多次发送相同的调用请求的过程称为上游服务的超时重试。

两个调用请求相同，是指，这两个调用请求基于客户端提交的同一个交易请求生成，也就是说，这两个调用请求对应于同一笔交易，可以理解的，两个相同的调用请求所携带的业务数据也是完全一致的。

例如，某个时间，用户甲订购商品a，于是向交易系统提交一个交易请求，也就是发起一笔订购商品a的交易，订单服务会产生的对应的商品订单，其中显示用户甲需要为商品a支付对应的金额x，然后向下游的支付服务发送携带该订单的调用请求，若对于这一调用请求支付服务超时未给出反馈，则订单服务再次发送携带该订单的调用请求。

可以理解的，在上游服务对一笔交易执行超时重试时，可能会出现以下情况：

上游服务前一次对这笔交易发送的调用请求被下游服务成功接收，但是由于下游服务负载较重，前一次接收的这个调用请求处理速度较慢，以至于发生了服务超时。此时，下游服务再次收到同样的调用请求时，若下游服务也按自身的业务处理逻辑处理本次收到的调用请求，就相当于同一笔交易被下游服务重复处理了两次(或多次，取决于下游服务收到相同的调用请求的次数)，进而引起交易错误。

结合前述购物的例子，若支付服务接收了订单服务第一次发送的调用请求，但是处理速度较慢，于是订单服务在支付服务发生服务超时后又发送携带同一订单的调用请求，支付服务对两次调用请求均进行处理之后，就会对用户甲的账户进行重复扣款。

针对上述问题，本申请实施例提供一种调用请求的处理方法，请参考图1，该方法包括以下步骤：

s101、第二服务响应于客户端提交的交易请求，生成与交易请求对应的第一调用请求。

客户端提交一次交易请求，相当于发起了一笔交易。

所述第一调用请求，包括需要由第一服务处理的业务数据，以及第二服务生成的，与客户端本次提交的交易请求对应的交易标识。也就是说，第二服务生成第一调用请求，其实就是将自身处理当前这笔交易时产生的需要第一服务处理的业务数据和自身生成的交易标识组合，就可以得到第一调用请求。

其中，第一调用请求包括业务数据和基于交易请求生成的交易标识。

如前文所述，交易系统由多个服务构成，根据不同服务之间的业务关联，每个服务既可以被其他服务调用，也可以调用其他服务。因此，步骤s101所述的响应客户端的交易请求并生成对应的第一调用请求，可以是第二服务直接接收客户端发送的交易请求，然后根据这个交易请求中的业务数据生成对应的调用请求，特别的，当第二服务是交易系统中专门用于与客户端对接的接口服务时就会出现这种情况；也可以是，客户端向交易系统提交的交易请求由交易系统的第三服务直接接收，所述第三服务是第二服务的上游服务，第三服务按预设的业务逻辑处理交易请求携带的业务数据，从而产生这个交易请求对应的第二调用请求，然后将第二调用请求发送给第二服务，第二服务处理第二调用请求携带的业务数据，从而产生这个交易请求对应的第一调用请求。

需要说明的是，所述第一调用请求携带的业务数据，可以是第二服务执行完自身的业务逻辑产生的结果，也可以是第二服务执行自身的业务逻辑中产生的一些需要由第一服务处理的中间数据。

针对一笔交易生成对应的交易标识的方法有很多，本申请对此不作限定，只要能确保在交易系统的整个生命周期内，每一笔交易都能生成一个区别于其他交易的唯一的交易标识即可。

在实际的交易系统中，为了提高系统的承载能力，一般会将每个服务部署于多个服务器组成的服务器集群中。在这种架构中，作为一种可选的生成方法，第二服务可以将用于处理当前这一笔交易的业务数据(可以是交易请求携带的业务数据，也可以是第三服务发送的第二调用请求携带的业务数据)的服务器的服务器编号，以及自身收到对应的请求(交易请求或者第三服务发送的第二调用请求)的时间组合得到当前这笔交易的交易标识，还可以利用一个随机数生成器为每一笔交易生成一个随机数，然后将这个随机数与前述时间和服务器编号组合成这笔交易的交易标识。

s102、第二服务向第一服务发送第一调用请求。

s103、第一服务查找是否存储第一调用请求的交易标识。

需要说明的是，步骤s103所述的查找，是分别在第一服务的数据缓存区，和第一服务的数据库中查找所述第一调用请求的交易标识。可以理解的，得到的查找结果包括数据缓存区和数据库中均存储有上述交易标识，数据缓存区存储而数据库未存储上述交易标识，数据缓存区未存储而数据库存储上述交易标识，以及数据缓存区和数据库均未存储上述交易标识。其中，前三种情况可以概括为数据缓存区和/或数据库中存储有第一调用请求的交易标识。

若第一服务发现数据缓存区和/或数据库中存储有第一调用请求的交易标识，那么第一服务确定本次接收的第一调用请求不是第一服务首次接收的与这一笔交易对应的调用请求。换言之，就是说第一服务之前已经成功接收过与当前接收的这个第一调用请求相同的(也就是对应于同一笔交易的)另一个第一调用请求，当前接收的这个第一调用请求，是第二服务在第一服务发生服务超时之后重复发送的第一调用请求。

若第一服务发现数据缓存区和数据库中均未存储有本次接收的第一调用请求的交易标识，则第一服务确定这个第一调用请求是第一服务首次接收的与当前客户端发起的这一笔交易对应的调用请求。

其中，若数据缓存区和/或数据库中存储有第一调用请求的交易标识，则执行步骤s104，反之，若数据缓存区和数据库中均未存储有第一调用请求的交易标识，则执行步骤s105。

可选的，步骤s103的具体执行过程可以是，首先在数据库中查找是否存储有第一调用请求的交易标识，若有，则执行步骤s104，若数据库中未存储第一调用请求的交易标识，或者数据库发生读写故障导致无法执行在数据库中查找交易标识的操作，则在数据缓存区中继续查找第一调用请求的交易标识，若在数据缓存区中查找出第一调用请求的交易标识，则执行步骤s104，若在数据缓存区中仍未查找出第一调用请求的交易标识，则确定数据缓存区和数据库中均未存储第一调用请求的交易标识，执行步骤s105。

可选的，由于数据缓存区的数据存储能力有限，第一服务可以定期对数据缓存区存储的各个交易标识进行清理。例如，可以每经过120分钟，第一服务就遍历数据缓存区当前存储的每一个交易标识，针对每一个交易标识，判断第一服务是否已经向第二服务反馈，携带有这个交易标识的第一调用请求的处理结果，若已经反馈，则删除这个交易标识，反之则保留这个交易标识。

s104、第一服务删除当前接收的第一调用请求。

可以理解的，对于相同的第一调用请求，第一服务应该只处理一次，这样才能防止出现第一服务重复执行多次相同操作导致的交易错误(例如重复扣款等)。若识别出第一服务之前已经收到过与当前的这个第一调用请求相同的另一个第一调用请求，那么第一服务只需要处理已经收到的相同的第一调用请求并反馈处理结果即可，不应该继续处理当前接收的这个第一调用请求，因此将当前收到的这个第一调用请求删除。

s105、第一服务按预设业务逻辑处理第一调用请求并记录第一调用请求的交易标识。

具体的，所述记录第一调用请求的交易标识，是指，将第一调用请求的交易标识分别写入数据缓存区和数据库中。具体的，若当前不可执行数据库的写入操作，那么第一服务可以现在数据缓存区写入第一调用请求的交易标识，等待数据库可以写入之后再将第一调用请求的交易标识写入数据库。

通过采用如步骤s104和步骤s105所述的同时在数据缓存区和数据库存储以及查找交易标识的方法，本申请可以有效的避免数据库突然宕机导致无法验证交易标识。例如，若只在数据库中存储交易标识，就可能出现第一服务接收到一个已经收到过的重复的第一调用请求时，由于数据库宕机，导致第一服务无法从数据库中找到这个第一调用请求的交易标识，使得第一服务错误的判断当前收到的这个第一调用请求是第一服务首次接收的对应于一笔新的交易的调用请求，进而引起重复操作。而采用本申请提供的数据缓存区和数据库双存储的方法，即使在数据库临时宕机的情况下也不会出现上述情况。

s106、第一服务向第二服务反馈第一调用请求的处理结果。

第一方面，步骤s106所述的第一调用请求的处理结果，可以是在第一服务识别出当前接收的这个第一调用请求是第一服务首次接收的与客户端的交易请求对应的调用请求之后，触发相应的业务逻辑对第一调用请求的业务数据进行处理，处理完成之后生成的处理结果。

第二方面，第一服务识别出当前接收的这个第一调用请求是第一服务重复接收的与客户端的交易请求对应的调用请求之后，会执行步骤s104删除这个第一调用请求。此时，第一服务可以检测自身首次接收的，并且与本次接收的第一调用请求相同的第一调用请求是否已经处理成功，若这个首次接收的相同的第一调用请求已经处理成功，则第一服务直接从对应的处理结果存储区域读取相应的处理结果并向第二服务反馈，若这个首次接收的相同的第一调用请求还未处理成功，则第一服务按当前的处理进度继续调用自身的业务处理逻辑处理这个首次接收的相同的第一调用请求，直至处理成功，然后再将处理结果反馈给第二服务。

可选的，若发现首次接收的，与本次收到的第一调用请求相同的第一调用请求当前处于排队等待状态，那么第一服务可以将这个第一调用请求在等待队列中的位置前移，以便尽快处理完首次接收的这个相同的第一调用请求。

s107、第二服务检测第一服务是否反馈处理结果。

所述处理结果，指代第一服务按自身的业务逻辑对第二服务发送的第一调用请求进行处理后得到的处理结果。

若第一服务未反馈处理结果，则执行步骤s108，若第一服务反馈处理结果，则执行步骤s110。

s108、第二服务判断第一服务是否服务超时。

若判断出第一服务发生服务超时，则第二服务执行步骤s109，步骤s109执行结束后，第二服务返回执行前述步骤s102,，再次向第一服务发送客户端提交的交易请求所对应的第一调用请求，也就是针对客户端本次提交的交易请求向第一服务发起服务重试。

若判断出第一服务未发生服务超时，则第二服务再次执行前述步骤s107，直至判断出第一服务发生服务超时，或者检测到第一服务反馈了处理结果为止。

需要理解的是，步骤s107和步骤s108组成的判断过程，与前述步骤s103至步骤s106所述的第一服务处理第一调用请求的过程同时进行的，也就是说，第二服务发送第一调用请求之后，第二服务就立即执行步骤s107和步骤s108，并根据判断结果执行对应步骤，同时第一服务收到第一调用请求之后立即执行步骤s103至步骤s106所述的处理过程，两个过程之间没有先后顺序。

s109、第二服务向客户端反馈第一提示信息。

其中，所述第一提示信息用于提示用户提交的交易请求当前正在处理。具体的，所述第一提示信息可以是：“交易正在处理，请稍候”。

可选的，为了防止用户反复提交多个完全相同的交易请求，输出的第一提示信息还可以提示用户不要再次提交交易请求，例如，第一提示信息可以是：“交易处理中，请不要重复发起交易”。

可以理解的，步骤s109所述向客户端反馈第一提示信息，是指，若第二服务是交易系统中可以直接与客户端进行通信的服务，例如，接口服务，则第二服务直接生成上述第一提示信息，并直接向提交交易请求的客户端发送所述第一提示信息，若第二服务是交易系统中不直接与客户端通信的服务，则第二服务可以触发交易系统中直接与客户端通信的接口服务，使其生成第一提示信息并向客户端发送，也可以由第二服务自身生成第一提示信息，然后通过接口服务将第一提示信息转发给客户端。

s110、第二服务向客户端或者上游服务反馈第二服务的处理结果。

步骤s110所述的上游服务，指代所述第二服务的上游服务。

具体的，若第二服务是交易系统中直接与客户端通信的接口服务，那么步骤s110就是向客户端反馈处理结果，这种情况下，所述处理结果可以是用于提示用户交易处理成功的提示信息。

若第二服务不是直接与客户端通信的接口服务，那么步骤s110就是向第二服务的上游服务反馈第二服务的处理结果。

其中，所述第二服务的处理结果，可以是第二服务对自身收到的业务数据进行处理后的处理结果，以及第一服务对第二服务下发的第一调用请求中的业务数据进行处理后的处理结果的组合，或者是两者中的一种。也可以是获得第一服务对第一调用请求的业务数据进行处理得到的处理结果后，基于所述第一服务反馈的处理结果进一步进行处理得到的处理结果。

例如，假设一个交易系统包括接口服务，订单服务和支付服务。接口服务获取用户身份信息和用户选择的商品信息，然后将携带有这些信息的调用请求发送给订单服务，订单服务基于这些信息生成数字订单，然后向支付服务发送第一调用请求，所述数字订单就是第一调用请求的业务数据，支付服务处理成功后，向订单服务反馈处理结果，也就是订单扣款成功，订单服务收到表示订单扣款成功的处理结果后，生成本次交易成功的处理结果，并发送给接口服务，最后接口服务再转发给客户端。

其中，若以接口服务作为本实施例中的第二服务，那么步骤s110所述的处理结果就是接口服务向客户端发送的本次交易成功的信息，若以订单服务作为本实施例中的第二服务，那么步骤s110所述的处理结果，就是订单服务根据支付服务反馈的扣款成功的处理结果而生成的本次交易成功的信息。

本申请提供一种调用请求的处理方法，第一服务接收上游的第二服务根据交易请求生成的第一调用请求；分别在数据缓存区和数据库中查找第一调用请求携带的交易标识，从而判断第一调用请求是否为首次接收的与交易请求对应的调用请求；若第一调用请求是首次接收的与交易请求对应的调用请求，基于业务处理逻辑处理其中的业务数据，将交易标识写入数据缓存区和数据库中；若第一调用请求不是首次接收的与交易请求对应的调用请求，删除第一调用请求；将首次接收的与交易请求对应的调用请求的处理结果反馈给第二服务。

本申请实施例提供的方法具有如下有益效果：

第一方面，本申请中，第一服务对于一笔交易对应的首次接收的第一调用请求，分别在数据缓存区和数据库中记录这个第一调用请求的交易标识，以便在后续再次收到这笔交易对应的第一调用请求时通过在数据缓存区和数据库中查找交易标识来识别出后续的第一调用请求是重复请求，从而实现服务重试过程的幂等性，也就是避免针对同一笔交易发起重试时引起的重复操作。并且，分别在数据缓存区和数据库中记录和查找交易标识，能够避免其中任意一方(一般是数据库)临时宕机导致无法准确的查找和记录交易标识的问题。

第二方面，本申请中，第二服务在判断出第一服务发生服务超时之后，及时的向客户端输出提示信息以提示用户交易正在处理，避免用户提交了交易请求之后长时间未收到交易的处理结果而执行不必要的操作，达到提高用户体验的效果。

第三方面，本申请可以采用用户发起交易的时间戳以及第二服务中用于发起第一调用请求的服务器的服务器编号生成对应的交易的交易标识，在交易系统比较繁忙的情况下，交易系统可能在很短的一段时间内(例如，一毫秒内)同时接收多个交易请求，本申请所采用的交易标识的生成方法在这种情况下能够有效的避免对同时发生的多笔交易生成相同的交易标识，从而确保交易修通处理的每一笔交易的交易标识的唯一性。

结合本申请实施例提供的调用请求的处理方法，本申请实施例还提供一种调用请求的处理装置，具体的，该装置可以是交易系统中的第一服务，也就是被调用的下游服务，也可以是交易系统中的第二服务，也就是调用其他服务的上游服务。

具体的，若所述处理装置是第一服务，参考图2，该装置具体包括以下单元：

接收单元201，用于接收第二服务生成的与客户端提交的交易请求对应的第一调用请求。

其中，第一调用请求包括业务数据和基于交易请求生成的交易标识，第二服务是第一服务的上游服务。

查找单元202，用于分别在第一服务的数据缓存区和数据库中查找交易标识。

处理单元203，用于若数据缓存区和数据库中均未存储第一调用请求的交易标识，确定第一调用请求是第一服务首次接收的与交易请求对应的调用请求，按预设的业务处理逻辑处理业务数据。

写入单元204，用于若第一调用请求是第一服务首次接收的与交易请求对应的调用请求，将交易标识写入数据缓存区和数据库中。

删除单元205，用于若数据缓存区和/或数据库中存储第一调用请求的交易标识，确定第一调用请求不是第一服务首次接收的与交易请求对应的调用请求，删除第一调用请求。

反馈单元206，用于将第一服务首次接收的与交易请求对应的调用请求的处理结果反馈给第二服务。

反馈单元206将第一服务首次接收的与交易请求对应的调用请求的处理结果反馈给第二服务时，具体用于：

判断第一服务首次接收的与交易请求对应的调用请求是否处理成功；

若处理成功，获取第一服务首次接收的与交易请求对应的调用请求的处理结果并将处理结果反馈给第二服务；

若未处理成功，按当前的处理进度继续处理第一服务首次接收的与交易请求对应的调用请求的业务数据，并在处理成功后将处理结果反馈给第二服务。

判断单元202分别在第一服务的数据缓存区和数据库中查找交易标识，并根据查找结果判断第一调用请求是否为第一服务首次接收的与交易请求对应的调用请求时，具体用于：

分别在第一服务的数据缓存区和数据库中查找交易标识；

若数据缓存区和数据库均未存储交易标识，则判断出第一调用请求为第一服务首次接收的与交易请求对应的调用请求；

若数据缓存区和/或数据库存储有交易标识，则判断出第一调用请求不是第一服务首次接收的与交易请求对应的调用请求。

若所述处理装置是第二服务，参考图3，该装置具体包括以下单元：

生成单元301，用于响应于客户端提交的交易请求，生成与交易请求对应的第一调用请求。

其中，第一调用请求包括业务数据和基于交易请求生成的交易标识。

发送单元302，用于将第一调用请求发送至第一服务，使第一服务根据交易标识判断是否处理第一调用请求携带的业务数据，并等待第一服务反馈业务数据的处理结果。

其中，第二服务是第一服务的上游服务。

判断单元303，用于判断等待时间是否大于或等于预设的超时时长，若等待时间大于或等于超时时长，触发发送单元再次将第一调用请求发送至第一服务，直至第一服务反馈业务数据的处理结果为止。

提示单元304，用于若等待时间大于或等于超时时长，向客户端发送第一提示信息。

其中，第一提示信息用于指示交易请求正在被处理。

具体的，生成单元301响应于客户端提交的交易请求，生成与交易请求对应的第一调用请求时，具体用于：

接收第三服务基于客户端提交的交易请求生成的第二调用请求，并根据第二调用请求携带的业务数据生成交易请求对应的第一调用请求；其中，第三服务是第二服务的上游服务。

具体的，生成单元301生成与交易请求对应的第一调用请求，具体用于：

按第二服务的业务处理逻辑处理交易请求携带的业务数据，并将得到的处理结果作为交易请求对应的第一调用请求的业务数据；

利用客户端提交交易请求的时间和处理业务数据的服务器的服务器编号生成交易请求的交易标识；

组合业务数据和交易标识，得到交易请求对应的第一调用请求。

本申请实施例提供的调用请求的处理装置的具体工作原理可以参考本申请实施例提供的处理方法中的对应步骤，此处不再赘述。

需要说明的是，如图2和图3所示的各个单元，可以属于同一个服务，这个服务被其他服务调用时触发图2所示的单元，作为第一服务运行，这个服务调用其他服务时，触发图3所示的单元，从而作为第二服务运行。

本申请提供一种调用请求的装置，所述处理装置可以是被调用的第一服务或者调用第一服务的第二服务，其中，所述装置第一服务时，包括接收单元201，用于接收上游的第二服务根据交易请求生成的第一调用请求；查找单元202，分别在数据缓存区和数据库中查找第一调用请求携带的交易标识，从而判断第一调用请求是否为首次接收的与交易请求对应的调用请求；处理单元203，若第一调用请求是首次接收的与交易请求对应的调用请求，基于业务处理逻辑处理其中的业务数据，写入单元204将交易标识写入数据缓存区和数据库中；若第一调用请求不是首次接收的与交易请求对应的调用请求，删除单元205删除第一调用请求；最后，第一服务首次接收的与交易请求对应的调用请求处理成功后，反馈单元206将首次接收的与交易请求对应的调用请求的处理结果反馈给第二服务。第一服务通过记录首次收到的调用请求的交易标识，避免重复处理同一笔交易的多次调用请求，从而防止由于重复操作引起的交易错误。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

需要注意，本发明中提及的“第一”、“第二”等概念仅用于对不同的装置、模块或单元进行区分，并非用于限定这些装置、模块或单元所执行的功能的顺序或者相互依存关系。

专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。