具体实施方式

此处参考附图描述本公开的各种方案以及特征。

应理解的是，可以对此处申请的实施例做出各种修改。因此，上述说明书不应该视为限制，而仅是作为实施例的范例。本领域的技术人员将想到在本公开的范围和精神内的其他修改。

包含在说明书中并构成说明书的一部分的附图示出了本公开的实施例，并且与上面给出的对本公开的大致描述以及下面给出的对实施例的详细描述一起用于解释本公开的原理。

通过下面参照附图对给定为非限制性实例的实施例的优选形式的描述，本公开的这些和其它特性将会变得显而易见。

还应当理解，尽管已经参照一些具体实例对本公开进行了描述，但本领域技术人员能够确定地实现本公开的很多其它等效形式，它们具有如权利要求的特征并因此都位于借此所限定的保护范围内。

当结合附图时，鉴于以下详细说明，本公开的上述和其他方面、特征和优势将变得更为显而易见。

此后参照附图描述本公开的具体实施例；然而，应当理解，所申请的实施例仅仅是本公开的实例，其可采用多种方式实施。熟知和/或重复的功能和结构并未详细描述以避免不必要或多余的细节使得本公开模糊不清。因此，本文所申请的具体的结构性和功能性细节并非意在限定，而是仅仅作为权利要求的基础和代表性基础用于教导本领域技术人员以实质上任意合适的详细结构多样地使用本公开。

本说明书可使用词组“在一种实施例中”、“在另一个实施例中”、“在又一实施例中”或“在其他实施例中”，其均可指代根据本公开的相同或不同实施例中的一个或多个。

在现有的网络应用中，用户可以通过各种应用程序发送服务请求到对应的服务器中，以获取或实现相应功能。但是在通信过程中，可能基于网络原因或链路原因导致某一个请求通道存在延迟或处于失效状态，对于需要通过该通道进行传输的服务请求来说，通道失效会导致重复请求或切换请求方式情况发生，在这种情况下，容易造成系统负载不断增加，影响系统整体性能。下面结合图1中实际实施例进行具体描述。

图1示出了现有技术中用户在使用应用程序的过程中需要进行支付时的支付系统架构示意图，用户通过支付系统提供的收银台选择某一支付方式(A银行卡、B银行卡、信用付等)并提交支付请求，支付系统最终通过系统中的渠道对接模块将用户的支付请求发送给对应的支付渠道。因为涉及到外部服务提供方(支付渠道)，对于支付系统来说无法保证其服务的稳定性，因此对于支付系统来说，在其确定某一个支付渠道存在问题时，该用户将无法实现支付操作，但是在某些情况下支付渠道仅为瞬时不可用，用户此时实现的重复支付操作或切换支付方式的操作，会影响支付效率，导致系统负载提升，影响支付系统整体性能。

为了解决现有技术中存在的问题，本公开的第一实施例提供了一种服务器请求的处理方法，其可以应用于任意一种服务请求的系统或网路中，其流程示意图如图2所示，主要包括步骤S1至S5：

S1，更新通道的通道状态。

从用户使用的请求端到提供服务的服务端之间可能存在多个服务通道，或者在存在多个服务端时，请求端通过不同的服务通道与多个服务端之间实现互通。本实施例中对各个通道的通道状态进行检测更新，实际上可以按照预先设定的第一时间间隔对每个通道进行通道状态的检测。通道状态表示各个通道当前是否可用，具体包括可用状态和不可用状态，其中，通道状态可以通过标记位进行表示，例如0表示通道处于可用状态，1表示通道处于不可用状态，而可用状态是指通过当前通道所发出的服务请求可以正确到达相应服务器，并及时接收到反馈的状态，而不可用状态则为服务请求无法到达该服务器，或者无法接收到服务器反馈的状态。

具体地，本实施例通过以下几种方式来确定并更新通道的通道状态：(1)通过测试请求确定；请求端可以按照第一预定时间间隔通过各个通道向服务器发送测试请求，该测试请求可以为一个心跳包；若针对某一个通道，当请求端接收到服务器的反馈结果后，并确定该反馈结果为该测试请求对应的正确的反馈内容时，可以确定该相应通道可用并对应更新该通道的通道状态；若在一定时间内未接到反馈结果，或者接收到的反馈内容与测试请求不对应，则可确定相应通道不可用，并更新未接收到所述测试请求的反馈的通道状态为不可用状态。(2)通过模拟服务请求确定；请求端可以按照第一预定时间间隔通过各个通道向服务器发送模拟服务请求，该模拟服务请求可以具有与服务请求具有相同的格式或要求，并基于服务器对于该模拟服务请求的响应时间来确定通道的通道状态，该响应时间可以是服务器在接到模拟服务请求时向请求端发送的确认信息的时间，也可以是服务器基于模拟服务请求执行相应操作后反馈对应内容的时间；在某个通道的响应时间未超过预设阈值的情况下，确定并更新该通道的通道状态为可用状态；若通道的响应时间超过预设阈值，则确定并更新该通道的通道状态为不可用状态，其中，预设阈值根据实际情况设定即可。(3)通过通道的服务数据确定；服务数据可以为在第一预定时间内各个通道的服务成功率，也可以为在第一预定时间内通过某一个通道所发送的所有服务请求的平均响应时间，或者可以代表该通道是否可用的其他数据指标，可以根据不同的服务数据内容设定对应的合格条件，当服务数据符合合格条件时，则证明该通道可用并更新通道状态为可用状态，否则确定该通道不可用。

需要注意的是，本实施例中每个通道的通道状态都是实时变化的，在当前一个检测周期中，某个通道的通道状态为不可用，那么在下一个检测周期中该通道的通道状态也可以切换为可用，反之亦然；第一预定时间间隔可以根据实际通道的数量、实际可能发出的请求数量或者服务器与请求端之间的其他限定进行设置，本实施例中优选可以将第一时间间隔设置为一分钟，即每隔一分钟检测更新一次通道的通道状态。

另外，上述检测通道状态的方式，可以单一使用也可以结合使用，或者根据不同的需求在不同的情况下使用不同的检测方式，本实施例在此不进行限制。

S2，响应于请求端的当前服务请求，确定当前服务请求所请求的通道的当前通道状态。

请求端基于用户操作或需求，发起服务请求，该服务请求基于用户希望获取的服务生成，在正常情况下通过与相应服务器之间的通道进行传输。在通过当前服务请求所请求的通道传输请求端生成的当前服务请求时，首先确定当前服务请求所请求的通道的当前通道状态，并基于当前通道状态确定是否进行当前服务请求的发送。

S3，在当前通道状态为不可用状态时，将当前服务请求存储在数据库中。

在当前服务请求所请求的通道的通道状态为不可用状态时，说明该通道可能存在通信故障，或者对应服务器无法正确提供服务，此时即便将当前服务请求发送出去，也有较大概率无法得到正确的反馈，而为了避免向请求端的用户直接反馈服务请求发送失败或者无法提供服务等负面结果，同时避免因发送失败导致的频繁请求问题，本实施例将当前服务请求存储至数据库中进行挂起，存储在数据库中的当前服务请求被暂停处理，并可以在相应通道的通道状态变为可用状态后进行发送。另外，该数据库可以为该指定通道对应的数据库，其主要用于保存所有经过该指定通道的所有服务请求及其对应的反馈内容，或者，该数据库为所有通道统一使用的通道，在保存需要进行挂起的服务请求时，将其与对应的指定通道的通道ID或者通道标记进行关联，以便后续进行区分。

另外，在当前服务请求所请求的通道为可用状态时，说明在上一个时间间隔内，该通道的通信状况良好，服务器也可以正常提供相应服务，此时直接通过该通道将当前服务请求发送给相应服务器即可。

S4，基于通道的通道状态，对数据库中存储的服务请求进行处理。

对于其所使用的通道处于不可用状态的服务请求来说，其在存储至数据库后，通过标记的形式表征当前服务请求为未发送服务请求；具体地，上述标记的实现形式可以为通过独立的数据库字段进行表示，或通过修改服务请求的名称、属性的具体内容实现标记，或者在数据库中划分出一个独立列表用于存储未发送的服务请求。

在实际实现时，通道的通道状态不断更新变化，上一个周期内处于不可用状态的通道也有可能在下一个周期内变为可用状态，反之亦然，因此，对于存储在数据库中的未发送服务请求来说，可以根据每次通道的通道状态的更新结果，进行相应的处理。

在一些实施例中，对通道的通道状态进行检测更新，在更新之后，确定本次更新后，所有通道中是否存在当前通道状态由不可用状态变为可用状态的第一通道；若存在第一通道，则响应于该第一通道的通道状态变化，将存储在数据库中的所有未发送服务请求中，请求通道为第一通道的未发送服务请求通过第一通道进行发送，实现被挂起的服务请求在通道可用的情况下进行发送，保证服务请求的处理成功率，并且降低了服务请求的请求次数。在将相应的未发送服务请求发送后，可以修改该服务请求对应的标记，以将服务请求记录为已发送的服务请求。应当了解的是，第一通道可以是所有通道中的任意一个通道或多个通道，其实际表征的是在当前通道状态更新之后通道状态由不可用状态变为可用状态的一类通道，本实施例并不限制其具体是哪一个特定的通道。

在一些实施例中，在通道状态检测更新后还可以检测所有通道中是否存在连续预定次数或预定时长内的通道状态更新的更新结果均为不可用状态的第二通道；若存在第二通道，即第二通道的通道状态在连续多次的检测更新中一直处于不可用的状态，或者在预定时间段内的所赐检测更新中一直处于不可用状态，此时，将数据库中存储的所有未发送服务请求中请求通道为第二通道的未发送服务请求记录为停止处理服务请求，不再对其进行处理，同时及时告知相应请求端服务请求处理失败，并且可以提示请求端暂缓请求或通过其他通道进行请求。具体地，可以直接将停止处理的服务请求从数据库中删除以节省数据库空间，防止因停止处理的服务请求不断增加造成数据库存储压力。需要注意的是，本实施例中的第二通道可以是所有通道中的任意一个通道或多个通道，其实际表征的是在多次通道状态更新后一直处于不可用状态的一类通道，本实施例不限制其具体是哪一个特定的通道；另外，预定次数和预定时长均可以根据通道状态的更新间隔、通道负载情况、系统整体负载情况等内容进行调整，本实施例不进行具体限制。

S5，向请求端返回第一处理结果。

第一处理结果用于表征当前服务请求的处理状态，例如当前服务请求正在处理中，或处理成功、处理失败等。在当前服务请求被挂起存储到数据库中还未进行发送时，实际可能是由于通道异常或者对侧服务器无法提供服务，此时向请求端返回用于表征当前服务请求的处理状态为处理中的第一处理结果。在实际实现时，可根据通道状态的更新情况、服务请求的发送情况以及服务请求的反馈情况进行第一处理结果的更新，保证请求端可以收到及时准确的反馈内容，达到良好的提醒效果。

在一些实施例中，若存在当前通道状态由不可用状态变为可用状态的第一通道，则通过第一通道对应发送请求通道为第一通道的未发送服务请求，此时可根据发送出去的服务请求的处理结果，向请求端返回不同的第一处理结果。

具体地，若请求通道为第一通道的服务请求处理成功后，即通过第一通道接收到服务器基于服务请求反馈的内容，则向请求端返回用于表征所述服务请求处理成功的第一处理结果；若请求通道为第一通道的服务请求处理失败，即未接收到服务器反馈的请求内容或接收到的请求内容并未服务请求对应的请求内容，则向请求端返回用于表征所述服务请求处理失败的第一处理结果。在实际向请求端返回处理失败的第一处理结果时，还可以向请求端返回失败原因并提示请求端再次进行请求或通过其他通道发起请求。

在一些实施例中，在存在上述的第二通道的情况下，数据库中存储的请求通道为第二通道的相应未发送服务请求会被终止处理，此时可向请求端返回用于表征所述服务请求处理失败的第一处理结果，并可以向请求端返回失败原因并提示请求端再次进行请求或通过其他通道发起请求。

本实施例通过定期更新通道的通道状态，确定通道的可用性，在当前服务请求所请求的通道处于不可用状态时将服务请求进行存储，避免出现请求失败或重复请求的情况发生，降低系统整体负载情况，提升系统整体性能。

应当了解的是，在实际执行过程中，步骤S1实际上是在请求端和服务器通信过程中不断执行的，其实际和后续的步骤S2至S5之间没有限定的先后顺序，每间隔第一预定时间间隔所确定的通道状态，都会作为下一个周期内当有新的服务请求到来的时候，进行通道的通道状态确认的依据。

进一步地，在按照一定时间间隔更新通道的通道状态之后，若在一个通道的通道状态为可用时，尤其是当该通道的上一个检测周期所确定的通道状态为不可用的情况下，可以将数据库中该通道对应的未发送服务请求通过该通道进行发送，避免被挂起的服务请求长时间未处理影响用户的正常使用。

在一些实施例中，响应于基于指定通道的当前服务请求，在确定当前通道状态为不可用状态时，还可以执行如图3所示处理方法的另一种实施方式的步骤：S6，在预定时间内按照第二预定时间间隔检测通道的当前通道状态，例如在服务请求扎堆出现的高峰时间段，可以设定第二预定时间间隔小于第一预定时间间隔，以缩短通道状态的更新间隔，在通道由不可用转换为可用时，可以进一步缩短服务请求的等待时间，例如，第一预定时间间隔为一分钟，第二预定时间间隔为五秒钟；S7，在满足预定条件的情况下，可以将当前通道状态由不可用状态切换为可用状态，此时检测通道状态的方式可以通过测试请求或者模拟服务请求的方式进行，而预定条件则为接收到测试请求的反馈，或者响应时间未超过阈值，在满足上述条件时，说明当前通道可用，则可以将当前通道状态切换为可用状态；S8，在当前通道状态切换为可用状态后，可以基于切换为可用状态的通道发送相应的服务请求，这里的服务请求可以是之前存储在数据库中该指定通道对应的未发送服务请求以及在通道可用后新生产的当前服务请求。

在一些实施例中，还可能出现以下状况，例如，第一预定时间间隔为一分钟，假设第10分钟时确定第9到第10分钟之间的通道状态为可用，那么对于第10分钟到第11分钟之内所有新来的服务请求来说，当前通道的通道状态均为可用状态，假设在第10分30秒时网络故障，服务请求无法到达服务器，那么在第10分30秒之前的服务请求均可以正常发送，第10分30秒之后的网络请求虽然进行了发送操作，但是该请求并没有到达服务器，对于这些请求，本实施例也可以将其存储至数据库中，并向用户返回第一处理结果，并且在第11分钟进行通道状态更新时，上述发送失败的服务请求也会作为统计数据一同进行服务数据的计算，并最终对第11分钟的更新结果产生影响。

本公开第二实施例提供了一种服务请求的处理装置，该装置可安装与任意一种服务请求的处理系统中，作为请求端或请求端与服务端之间的中转设备或中转装置使用。其结构示意图如图4所示，主要包括更新模块10、确定模块20、存储模块30、处理模块40以及反馈模块50，其中，更新模块10用于更新通道的通道状态，通道状态至少包括不可用状态或者可用状态；确定模块20用于响应于请求端的当前服务请求，确定当前服务请求所请求的通道的当前通道状态；存储模块30用于在当前通道状态为不可用状态时，将当前服务请求存储在数据库中；处理模块40用于基于通道的通道状态，对数据库中存储的服务请求进行处理；反馈模块50用于向请求端返回第一处理结果，第一处理结果用于表征当前服务请求的处理状态。

在一些实施例中，处理模块40具体用于当前通道状态为不可用状态时，将存储至数据库中的当前服务请求进行标记，标记用于保证当前服务请求为未发送服务请求；反馈模块50具体用于向请求端反馈用于表征当前服务请求的处理状态为处理中的第一处理结果。

在一些实施例中，处理模块40还用于检测所有通道中是否存在当前通道状态由不可用状态变为可用状态的第一通道；在存在第一通道的情况下，将数据库中存储的所有未发送服务请求中请求通道为第一通道的未发送服务请求通过第一通道进行发送；将数据库中存储的请求通道为第一通道的未发送服务请求记录为已发送服务请求。

进一步地，反馈模块50还用于在请求通道为第一通道的服务请求处理成功后，向请求端返回用于表征服务请求处理成功的第一处理结果；或，在请求通道为第一通道的服务请求处理失败后，向请求端返回用于表征服务请求处理失败的第一处理结果。

在一些实施例中，处理模块40还用于检测所有通道中是否存在连续预定次数或预定时长内的通道状态更新的更新结果均为不可用状态的第二通道；在存在第二通道的情况下，将数据库中存储的所有未发送服务请求中请求通道为第二通道的未发送服务请求记录为停止处理服务请求；反馈模块50还用于向请求端返回用于表征服务请求处理失败的第一处理结果。

在一些实施例中，更新模块10具体用于按照第一预定时间间隔通过每个通道发送测试请求；将未接收到测试请求的反馈的通道的通道状态更新为不可用状态；将接收到测试请求的反馈的通道的通道状态更新为可用状态。

在一些实施例中，更新模块10具体用于按照第一预定时间间隔通过每个通道发送模拟服务请求并确定模拟服务请求的响应时间；将响应时间未超过预设阈值的通道的通道状态更新为可用状态；将响应时间超过预设阈值的通道的通道状态更新为不可用状态。

在一些实施例中，更新模块10具体用于按照第一预定时间间隔获取第一预定时间内的每个通道的服务数据；基于每个通道的服务数据，确定每个通道的通道状态。

在一些实施例中，确定模块20还用于在当前通道状态为可用状态时，通过当前服务请求所基于的通道发送当前服务请求。

本实施例通过定期更新通道的通道状态，确定通道的可用性，在当前服务请求所基于的通道处于不可用状态时将服务请求进行存储，避免出现请求失败或重复请求的情况发生，降低系统整体负载情况，提升系统整体性能。

本公开第三实施例提供了一种存储介质，该存储介质可安装于任意一种可以安装应用程序的请求端中，其具体为计算机可读介质，存储有计算机程序，该计算机程序被处理器执行时实现本公开任意实施例提供的方法，包括如下步骤S21至S25：

S21，更新通道的通道状态，通道状态至少包括不可用状态或者可用状态；

S22，响应于请求端的当前服务请求，确定当前服务请求所请求的通道的当前通道状态；

S23，在当前通道状态为不可用状态时，将当前服务请求存储在数据库中；

S24，基于通道的通道状态，对数据库中存储的服务请求进行处理；

S25，向请求端返回第一处理结果，第一处理结果用于表征当前服务请求的处理状态。

计算机程序被处理器执行基于通道的通道状态，对数据库中存储的服务请求进行处理时，具体被处理器执行如下步骤：在当前通道状态为不可用状态时，将存储至数据库中的当前服务请求进行标记，标记用于保证当前服务请求为未发送服务请求；计算机程序被处理器执行向请求端返回第一处理结果时，具体被处理器执行如下步骤：向请求端反馈用于表征当前服务请求的处理状态为处理中的第一处理结果。

计算机程序被处理器执行在更新通道的通道状态之后，还被处理器执行如下步骤：检测所有通道中是否存在当前通道状态由不可用状态变为可用状态的第一通道；在存在第一通道的情况下，将数据库中存储的所有未发送服务请求中请求通道为第一通道的未发送服务请求通过第一通道进行发送；将数据库中存储的请求通道为第一通道的未发送服务请求记录为已发送服务请求。

计算机程序被处理器执行向请求端返回第一处理结果时，具体被处理器执行如下步骤：在请求通道为第一通道的服务请求处理成功后，向请求端返回用于表征服务请求处理成功的第一处理结果；或，在请求通道为第一通道的服务请求处理失败后，向请求端返回用于表征服务请求处理失败的第一处理结果。

计算机程序被处理器执行在更新通道的通道状态之后，还被处理器执行如下步骤：检测所有通道中是否存在连续预定次数或预定时长内的通道状态更新的更新结果均为不可用状态的第二通道；在存在第二通道的情况下，将数据库中存储的所有未发送服务请求中请求通道为第二通道的未发送服务请求记录为停止处理服务请求；向请求端返回用于表征服务请求处理失败的第一处理结果。

计算机程序被处理器执行更新通道的通道状态时，具体被处理器执行如下步骤：按照第一预定时间间隔通过每个通道发送测试请求；将未接收到测试请求的反馈的通道的通道状态更新为不可用状态；将接收到测试请求的反馈的通道的通道状态更新为可用状态。

计算机程序被处理器执行更新通道的通道状态时，具体被处理器执行如下步骤：按照第一预定时间间隔通过每个通道发送模拟服务请求并确定模拟服务请求的响应时间；将响应时间未超过预设阈值的通道的通道状态更新为可用状态；将响应时间超过预设阈值的通道的通道状态更新为不可用状态。

计算机程序被处理器执行更新通道的通道状态时，具体被处理器执行如下步骤：按照第一预定时间间隔获取第一预定时间内的每个通道的服务数据；基于每个通道的服务数据，确定每个通道的通道状态。

计算机程序被处理器执行响应于请求端的当前服务请求，确定当前服务请求所基于的通道的当前通道状态之后，还被处理器执行如下步骤：在当前通道状态为可用状态时，通过当前服务请求所基于的通道发送当前服务请求。

本实施例通过定期更新通道的通道状态，确定通道的可用性，在当前服务请求所基于的通道处于不可用状态时将服务请求进行存储，避免出现请求失败或重复请求的情况发生，降低系统整体负载情况，提升系统整体性能。

本公开的第四实施例提供了一种电子设备，该电子设备可以作为任意一种可以安装应用程序的用户端设备使用，其结构示意图如图5所示，至少包括存储器100和处理器200，存储器100上存储有计算机程序，处理器200在执行存储器100上的计算机程序时实现本公开任意实施例提供的方法。示例性的，电子设备计算机程序步骤如下S31至S35：

S31，更新通道的通道状态，通道状态至少包括不可用状态或者可用状态；

S32，响应于请求端的当前服务请求，确定当前服务请求所请求的通道的当前通道状态；

S33，在当前通道状态为不可用状态时，将当前服务请求存储在数据库中；

S34，基于通道的通道状态，对数据库中存储的服务请求进行处理；

S35，向请求端返回第一处理结果，第一处理结果用于表征当前服务请求的处理状态。

处理器在执行存储器上存储的基于通道的通道状态，对数据库中存储的服务请求进行处理时，具体执行如下计算机程序：在当前通道状态为不可用状态时，将存储至数据库中的当前服务请求进行标记，标记用于保证当前服务请求为未发送服务请求；处理器在执行存储器上存储的向请求端返回第一处理结果时，具体执行如下计算机程序：向请求端反馈用于表征当前服务请求的处理状态为处理中的第一处理结果。

处理器在执行存储器上存储的更新通道的通道状态之后，还执行如下计算机程序：检测所有通道中是否存在当前通道状态由不可用状态变为可用状态的第一通道；在存在第一通道的情况下，将数据库中存储的所有未发送服务请求中请求通道为第一通道的未发送服务请求通过第一通道进行发送；将数据库中存储的请求通道为第一通道的未发送服务请求记录为已发送服务请求。

处理器在执行存储器上存储的向请求端返回第一处理结果时，具体执行如下计算机程序：在请求通道为第一通道的服务请求处理成功后，向请求端返回用于表征服务请求处理成功的第一处理结果；或，在请求通道为第一通道的服务请求处理失败后，向请求端返回用于表征服务请求处理失败的第一处理结果。

处理器在执行存储器上存储的更新通道的通道状态之后，还执行如下计算机程序：检测所有通道中是否存在连续预定次数或预定时长内的通道状态更新的更新结果均为不可用状态的第二通道；在存在第二通道的情况下，将数据库中存储的所有未发送服务请求中请求通道为第二通道的未发送服务请求记录为停止处理服务请求；向请求端返回用于表征服务请求处理失败的第一处理结果。

处理器在执行存储器上存储的更新通道的通道状态时，具体执行如下计算机程序：按照第一预定时间间隔通过每个通道发送测试请求；将未接收到测试请求的反馈的通道的通道状态更新为不可用状态；将接收到测试请求的反馈的通道的通道状态更新为可用状态。

处理器在执行存储器上存储的更新通道的通道状态时，具体执行如下计算机程序：按照第一预定时间间隔通过每个通道发送模拟服务请求并确定模拟服务请求的响应时间；将响应时间未超过预设阈值的通道的通道状态更新为可用状态；将响应时间超过预设阈值的通道的通道状态更新为不可用状态。

处理器在执行存储器上存储的更新通道的通道状态时，具体执行如下计算机程序：按照第一预定时间间隔获取第一预定时间内的每个通道的服务数据；基于每个通道的服务数据，确定每个通道的通道状态。

处理器在执行存储器上存储的响应于请求端的当前服务请求，确定当前服务请求所基于的通道的当前通道状态之后，还执行如下计算机程序：在当前通道状态为可用状态时，通过当前服务请求所基于的通道发送当前服务请求。

本实施例通过定期更新通道的通道状态，确定通道的可用性，在当前服务请求所基于的通道处于不可用状态时将服务请求进行存储，避免出现请求失败或重复请求的情况发生，降低系统整体负载情况，提升系统整体性能。

下面结合图6至图8以支付系统架构为例进行说明。

图6示出了支付系统架构的整体设计流程图。具体地，渠道对接模块为每个服务渠道增加一个可用性开关，通过定期检查服务渠道的请求处理成功率以及请求服务渠道，检查渠道可用性，并更新可用性开关。在请求终端发出服务请求时，渠道对接模块查看渠道的可用性开关，当可用性开关不可用时，停止向对应服务渠道发送请求，并将本次服务请求写入渠道数据库中，向请求终端返回请求处理中。当可用性开关为可用时，扫描渠道数据库，将之前暂存在数据库中的服务器你去取出并通过相应渠道进行发送，并等待服务渠道返回的请求结果，通知请求终端。

图7示出了渠道对接模块与服务渠道之间的可用性检测流程示意图。其具体示出了通过检测渠道服务请求成功率的方式进行渠道可用性更新的方案。其中，渠道对接模块通过检查当前渠道的请求成功率作为渠道可用性更新依据，若成功率突降(例如成功率降到90％以下)，则更新可用性开关为不可用，若成功率未发生突降或提升，则请求服务渠道可用性接口，并根据请求结果更新可用性开关状态。具体地，可用性开关的具体状态被更新至动态配置中心TCC中。

图8示出了服务渠道可用后渠道对接模块进行补单任务流程示意图。在执行时，首先从TCC中获取渠道可用性，判断其是否可用，若依旧不可用，则进行快速结束，即跳过当前服务渠道补单任务，进行其他渠道补单任务执行。若服务渠道当前可用，则扫描数据库中状态为未发送服务请求，通过可用的服务渠道进行发送，服务渠道接收到服务请求后进行请求处理，并将请求结果反馈至渠道对接模块，同时更新数据库中相应服务请求的状态。

以上对本公开多个实施例进行了详细说明，但本公开不限于这些具体的实施例，本领域技术人员在本公开构思的基础上，能够做出多种变型和修改实施例，这些变型和修改都应落入本公开所要求保护的范围之内。