一种交易请求的处理方法、装置及交易转接系统与流程

1.本技术涉及金融技术领域，尤其涉及一种交易请求的处理方法、装置及交易转接系统。


背景技术：

2.现有的清算平台在对交易请求进行处理时，主要采用如下方式：首先目标数据中心中的服务器在接收到交易请求之后，由服务器中的交易转接系统根据交易请求的报文编号确定该交易的业务逻辑；之后，将交易请求的数据发送至交易核验系统进行合法性和业务逻辑核验，对于核验不通过的交易请求拒绝处理，对于核验通过的交易请求可以将交易数据转发至本数据中心的银行前置模块，由银行前置模块对报文进行加密和组装后发送至目标银行；目标银行接收到组装后的报文后，对报文进行解析，得到报文信息，最后根据报文中的交易信息和业务逻辑进行校验和出入账处理。
3.然而，现有的交易请求的处理方法存在着交易请求不能幂等处理、交易损失率较高等问题。


技术实现要素：

4.本技术实施例提供了一种交易请求的处理方法、装置及交易转接系统，以降低交易损失率和交易风险。
5.本技术实施例采用下述技术方案：
6.第一方面，本技术实施例提供一种交易请求的处理方法，应用于交易转接系统中的各交易转接服务器，其中，所述方法包括：
7.获取系统策略标识，所述系统策略标识为生效于所述交易转接系统的策略标识；
8.根据所述系统策略标识更新本地策略标识，所述本地策略标识为生效于各交易转接服务器的策略标识；
9.根据更新后的本地策略标识，对接收到的交易请求进行处理；
10.根据交易请求处理结果确定上报信息。
11.可选地，所述交易转接系统还包括预设的redis数据库，所述系统策略标识保存在所述redis数据库中，所述获取系统策略标识包括：
12.确定所述redis数据库的redis状态标识；
13.在所述redis状态标识指示所述redis数据库正常的情况下，向所述redis数据库请求获取所述系统策略标识。
14.可选地，所述方法还包括：
15.根据向所述redis数据库请求的结果确定请求失败的次数；
16.若预设时间内所述请求失败的次数达到第一阈值，则将所述redis状态标识更新为redis故障标识，所述redis故障标识用于指示所述redis数据库故障。
17.可选地，所述方法还包括：
18.将所述上报信息上报至所述redis数据库，以使所述redis数据库能够根据所述上报信息更新所述系统策略标识；
19.根据上报结果确定上报失败的次数；
20.若所述上报失败的次数达到第二阈值，则将所述redis状态标识更新为redis故障标识。
21.可选地，所述系统策略标识包括降级标识，所述降级标识包括系统异常降级标识，所述根据所述系统策略标识更新本地策略标识包括：
22.若所述系统策略标识为所述系统异常降级标识，则将所述本地策略标识更新为所述系统异常降级标识；
23.所述根据更新后的本地策略标识对应的交易请求处理策略，对接收到的交易请求进行处理包括：
24.根据所述系统异常降级标识，将接收到的交易请求放行至交易处理系统进行交易处理。
25.可选地，所述交易请求中携带有机构标识，在根据所述系统异常降级标识，将接收到的交易请求放行至交易处理系统进行交易处理之前，所述方法还包括：
26.确定所述交易请求中携带的机构标识是否在黑名单列表中；
27.若在，则直接拒绝所述交易请求；
28.若不在，则将所述交易请求放行至所述交易处理系统。
29.可选地，所述系统策略标识包括降级标识，所述降级标识包括业务拒绝降级标识，所述根据所述系统策略标识更新本地策略标识包括：
30.若所述系统策略标识为所述业务拒绝降级标识，则将所述本地策略标识更新为所述业务拒绝降级标识；
31.所述根据更新后的本地策略标识对应的交易请求处理策略，对接收到的交易请求进行处理包括：
32.根据所述业务拒绝降级标识，直接拒绝所述交易请求。
33.可选地，所述系统策略标识包括不降级标识，所述根据所述系统策略标识更新本地策略标识包括：
34.若所述系统策略标识为所述不降级标识，则将所述本地策略标识更新为所述不降级标识；
35.所述根据更新后的本地策略标识对应的交易请求处理策略，对接收到的交易请求进行处理包括：
36.根据所述不降级标识，将接收到的交易请求转发至交易核验系统进行核验。
37.可选地，所述根据交易请求处理结果确定上报信息包括：
38.接收所述交易核验系统返回的交易核验结果，所述交易核验结果的种类包括交易核验通过、交易核验系统异常和业务拒绝；
39.根据所述交易核验结果统计系统异常次数和业务拒绝次数，以及根据接收到的交易请求统计接口访问次数；
40.将所述系统异常次数、所述业务拒绝次数和所述接口访问次数中至少一项作为所述上报信息。
41.可选地，所述方法还包括：
42.若无法获取所述系统策略标识，则直接根据所述上报信息确定所述本地策略标识。
43.可选地，所述上报信息包括系统异常次数、业务拒绝次数和接口访问次数，所述若无法获取所述系统策略标识，则直接根据所述上报信息确定所述本地策略标识包括：
44.根据所述系统异常次数和所述接口访问次数，计算所述交易请求的第一失败率；
45.若所述系统异常次数触发系统异常次数阈值，且所述第一失败率触发第一失败率阈值，则更新所述本地策略标识为所述系统异常降级标识。
46.可选地，所述若无法获取所述系统策略标识，则直接根据所述上报信息确定所述本地策略标识包括：
47.根据所述业务拒绝次数和所述接口访问次数，计算所述交易请求的第二失败率；
48.若所述业务拒绝次数触发业务拒绝次数阈值，且所述第二失败率触发第二失败率阈值，则更新所述本地策略标识为所述业务拒绝降级标识。
49.第二方面，本技术实施例提供一种交易请求的处理装置，应用于交易转接系统中的各交易转接服务器，其中，所述装置用于实现前述之任一所述方法。
50.第三方面，本技术实施例提供一种交易转接系统，包括多个交易转接服务器，所述交易转接服务器包括：
51.处理器；以及
52.被安排成存储计算机可执行指令的存储器，所述可执行指令在被执行时使所述处理器执行前述之任一所述方法。
53.第四方面，本技术实施例提供一种交易系统，包括：交易转接系统，交易核验系统和交易处理系统，
54.所述交易转接系统包括若干个交易转接服务器，各交易转接服务器包括前述所述装置。
55.第五方面，本技术实施例提供一种计算机可读存储介质，所述计算机可读存储介质存储一个或多个程序，所述一个或多个程序当被包括多个应用程序的交易转接服务器执行时，使得所述交易转接服务器执行前述之任一所述方法。
56.本技术实施例采用的上述至少一个技术方案能够达到以下有益效果：本技术实施例的交易请求的处理方法，应用于交易转接系统中的各交易转接服务器，在对交易请求进行处理时，先获取系统策略标识，系统策略标识为生效于交易转接系统的策略标识；然后根据系统策略标识更新本地策略标识，本地策略标识为生效于各交易转接服务器的策略标识；之后根据更新后的本地策略标识，对接收到的交易请求进行处理；最后根据交易请求处理结果确定上报信息。本技术通过针对整个交易转接系统设置统一的系统策略标识，保证了交易转接系统中的各交易转接服务器均能够获取到相同的本地策略标识，这种系统降级机制相比于现有的本地自动降级机制，能够在一定程度下降低交易损失率，同时保证了对同一个交易请求处理的一致性，避免了交易请求不能幂等处理等问题。
附图说明
57.此处所说明的附图用来提供对本技术的进一步理解，构成本技术的一部分，本申
请的示意性实施例及其说明用于解释本技术，并不构成对本技术的不当限定。在附图中：
58.图1为本技术实施例的一种交易系统的结构示意图；
59.图2为现有技术中的一种本地自动降级机制的逻辑框图；
60.图3为本技术实施例中一种交易请求的处理方法的流程示意图；
61.图4为本技术实施例中一种交易转接系统的结构示意图；
62.图5为本技术实施例中一种交易请求的处理逻辑框图；
63.图6为本技术实施例中一种交易请求的处理装置的结构示意图；
64.图7为本技术实施例中另一种交易转接系统的结构示意图。
具体实施方式
65.为使本技术的目的、技术方案和优点更加清楚，下面将结合本技术具体实施例及相应的附图对本技术技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
66.以下结合附图，详细说明本技术各实施例提供的技术方案。
67.如图1所示，提供了本技术实施例的一种交易系统的结构示意图，主要涉及以下三个子系统：交易转接系统、交易核验系统和交易处理系统，交易转接系统主要用于接收用户端发送过来的交易请求，并将交易请求转发至交易核验系统进行核验；交易核验系统主要用于对交易请求的内容进行合法性以及业务类型、业务逻辑等的核验，例如交易请求的金额是否超过最大限额，交易请求的业务类型是否符合要求等等；交易处理系统则主要用于对通过交易核验系统核验的请求进行具体的业务处理。在本技术实施例中，主要涉及到的是上述交易转接系统和交易核验系统。
68.在实际业务场景下，当交易转接系统调用交易核验系统时，如果出现有多笔交易请求超时或者有多笔交易请求被拒绝等情况，会造成该笔交易损失掉。为了降低交易损失率，引入了本地自动降级机制对交易请求进行处理。
69.如图2所示，提供了一种本地自动降级机制的逻辑框图，首先确定本地交易转接服务器的降级标识，如果为降级标识，则将交易请求中携带的机构标识与黑名单列表进行比对，如果不在黑名单列表内，则直接放行该交易请求，如果在黑名单列表内，则直接拒绝该交易请求。如果为不降级标识，则将交易请求发送至交易核验系统，然后同步等待交易核验系统的响应，若出现交易核验系统异常或者业务拒绝等问题，会统计交易核验系统异常或者业务拒绝的总次数，当总次数达到次数阈值时，自动触发本地交易转接服务器的自动降级，最后更新本地交易转接服务器的降级标识。对于交易核验系统异常的情况，可以进一步采用兜底策略进行判断，兜底策略可以理解为是根据机构、交易类型等事先约定好的处理规则，对于交易核验系统异常情况下的交易请求，可以通过兜底策略确定是放行该交易请求还是拒绝该交易请求。
70.然而，上述方案可能存在如下问题：
71.1)目前的自动降级为单台交易转接服务器范围(通常交易转接系统所在的机房内有上百台服务器)，容易出现交易转接系统在一段时间内持续损失交易的情况，导致交易损失率较高，原因在于这些损失的交易可能分布在各台交易转接服务器上，均没有触发单台
交易转接服务器的自动降级；
72.2)自动降级机制是在各台交易转接服务器的本地生效的，也就可能造成同一机房内的不同服务器上的交易转接应用的降级状态不一致，导致交易请求不能幂等处理，同时也会给运维处理造成困难；
73.3)当前的交易请求的处理方法同时统计了业务拒绝(即交易核验系统明确应答拒绝的情况)和交易核验系统异常(如通信异常等)，随着交易核验系统的逐渐完善和稳定，有可能出现因为正常的业务拒绝导致自动降级而放行该交易请求，进而可能疏漏一些真正有风险的交易。
74.基于此，本技术实施例提供了一种交易请求的处理方法，由交易转接系统中的交易转接服务器执行，其中，如图3所示，所述方法包括如下的步骤s310至步骤s340：
75.步骤s310，获取系统策略标识，所述系统策略标识为生效于所述交易转接系统的策略标识。
76.如图4所示，本技术实施例的交易转接系统包括多个交易转接服务器，每个交易转接服务器都可以用来执行本技术实施例的交易请求的处理方法。考虑到跨机房处理交易请求所带来的访问开销的问题，上述这些交易转接服务器可以部署在同一个机房内。
77.对于上述任意一个交易转接服务器来说，在接收到交易请求后，可以先获取该交易转接服务器所在的交易转接系统的系统策略标识，这里的系统策略标识可以理解为是整个交易转接系统对接收到的交易请求所采用的处理策略标识，也即系统策略标识面向的对象是一个机房内的所有交易转接服务器，即整个机房维度。
78.步骤s320，根据所述系统策略标识更新本地策略标识，所述本地策略标识为生效于各交易转接服务器的策略标识。
79.每个交易转接服务器会对应有自己的本地策略标识，这里的本地策略标识可以理解为是任意一个交易转接服务器对其接收到的交易请求所采用的处理策略标识，也即本地策略标识面向的对象是某一个交易转接服务器，即单台机器维度。
80.在实际业务场景下，由于网络延迟或故障等原因，可能会出现用户端针对同一笔交易发起了多次交易请求的情况，而每次发起的交易请求可能会到达不同的交易转接服务器上，如果这些交易转接服务器的本地策略标识不一致，那么针对同一个交易请求就会出现不同的处理结果。因此，为了避免上述问题的产生，对于上述任意一个交易转接服务器来说，在获取到交易转接系统的系统策略标识后，需要根据系统策略标识来更新本地策略标识，这样一个机房内的所有交易转接服务器的本地策略标识都可以保持一致，进而保证了对同一个交易请求的幂等处理。
81.步骤s330，根据更新后的本地策略标识，对接收到的交易请求进行处理。
82.每个交易转接服务器对接收到的交易请求可以进行多种处理，例如将交易请求转发至交易核验系统进行核验，或者将交易请求直接发送至交易处理系统进行具体的业务处理，又或者直接拒绝该交易请求，具体采用哪种处理方式，可以根据更新后的本地策略标识来确定。
83.步骤s340，根据交易请求处理结果确定上报信息。
84.本技术实施例的系统策略标识可以根据各交易转接服务器对交易请求的处理结果进行更新，以满足不同业务场景下对于交易请求的处理需求。这里的交易请求处理结果
可以包括交易请求通过的结果、交易请求拒绝的结果或者不明确的处理结果。实际业务场景下，由于交易转接系统异常等原因会导致交易转接系统当前的交易损失率较高，因此这里可以将上述交易请求处理结果上报信息进行上报，以便于后续根据上报信息确定是否要更新交易转接系统的系统策略标识，以调整对交易请求的处理策略，降低交易损失率。
85.本技术通过针对整个交易转接系统设置统一的系统策略标识，保证了交易转接系统中的各交易转接服务器均能够获取到相同的本地策略标识，这种系统降级机制相比于现有的本地自动降级机制，保证了对同一个交易请求处理的一致性，避免了交易请求不能幂等处理等问题。
86.实际业务场景下，可以通过执行异步任务的方式，例如每秒执行一次异步任务，来获取交易转接系统的系统策略标识，进而可以保证其他进程不受影响。
87.在本技术的一个实施例中，所述交易转接系统还包括预设的redis数据库，所述系统策略标识保存在所述redis数据库中，所述获取系统策略标识包括：确定所述redis数据库的redis状态标识；在所述redis状态标识指示所述redis数据库正常的情况下，向所述redis数据库请求获取所述系统策略标识。
88.如图4所示，本技术实施例的交易转接系统还包括一个预设的redis数据库(一种键值数据库)，redis数据库与交易转接系统中的各交易转接服务器均可以建立连接，主要用于接收并处理各交易转接服务器上报的信息并对交易转接系统的系统策略标识进行单独管理和更新。
89.在实际业务场景下，由于数据库故障或者其他原因等会导致redis数据库暂时无法使用，因此在获取redis数据库中存储的系统策略标识时，可以先确定redis数据库的redis状态标识，redis状态标识主要用于表征redis数据库的当前状态，如正常状态或故障状态。然后根据redis数据库的redis状态标识来确定redis数据库的当前状态，如果redis数据库当前处于正常状态，则可以向redis数据库发送请求，以获取系统策略标识。
90.在本技术的一个实施例中，所述方法还包括：根据向所述redis数据库请求的结果确定请求失败的次数；若预设时间内所述请求失败的次数达到第一阈值，则将所述redis状态标识更新为redis故障标识，所述redis故障标识用于指示所述redis数据库故障。
91.向redis数据库请求的结果可以包括请求成功的结果，即成功获取到交易转接系统的系统策略标识，也可以包括请求失败的结果，即没有获取到交易转接系统的系统策略标识。造成请求失败的原因可能是由于交易转接服务器或者redis数据库本身发生故障所导致的，也可能是由于网络连接异常所导致的，因此这里为了确定请求失败的结果是否与redis数据库本身故障有关，以降低误判的可能性，可以对一段时间内请求失败的次数进行统计，如果该段时间内向redis数据库请求失败的次数达到第一阈值，则说明很有可能是由于redis数据库本身发生故障导致请求失败，所以这时可以将redis状态标识更新为redis故障标识，指示redis数据库发生故障。
92.在本技术的一个实施例中，所述方法还包括：将所述上报信息上报至所述redis数据库，以使所述redis数据库能够根据所述上报信息更新所述系统策略标识；根据上报结果确定上报失败的次数；若所述上报失败的次数达到第二阈值，则将所述redis状态标识更新为redis故障标识。
93.如前所述，redis数据库主要用于对系统策略标识进行单独管理和更新，因此在根
据交易请求处理结果得到上报信息后，可以将该上报信息上报给redis数据库，然后由redis数据库进一步分析是否需要更新系统策略标识。
94.然而，由于上报过程同样涉及交易转接服务器和redis数据库之间的数据传输，因此可能会出现上报失败的情况，即上报信息没有成功写入redis数据库中。同理，造成上报失败的原因也可能是由于交易转接服务器故障、redis数据库故障或者网络连接异常所导致的，因此这里为了确定上报失败的结果是否与redis数据库本身故障有关，以降低误判的可能性，可以对上报失败的次数进行统计，如果上报失败的次数达到第二阈值，则说明很有可能是由于redis数据库本身发生故障导致上报失败，所以这时也可以将redis状态标识更新为redis故障标识。
95.需要说明的是，上述实施例中的“第一阈值”和“第二阈值”的大小可根据实际业务需求灵活设置，当然也可以仅设置一个阈值，以对请求失败的次数和上报失败的次数之和统一进行判断。
96.在本技术的一个实施例中，所述系统策略标识包括降级标识，所述降级标识包括系统异常降级标识，所述根据所述系统策略标识更新本地策略标识包括：若所述系统策略标识为所述系统异常降级标识，则将所述本地策略标识更新为所述系统异常降级标识；所述根据更新后的本地策略标识对应的交易请求处理策略，对接收到的交易请求进行处理包括：根据所述系统异常降级标识，将接收到的交易请求放行至交易处理系统进行交易处理。
97.正常情况下，交易转接系统接收到交易请求会转发到交易核验系统进行交易合法性的验证以及业务逻辑的验证等等，但由于某些异常情况的出现会导致交易请求无法得到及时响应或者多次被拒绝，进而会导致该笔交易损失掉，导致整个交易转接系统的交易损失率较高，因此为了降低交易损失率，可以通过降级的方式来应对，具体降级的对象是每台交易转接服务器上部署的交易转接应用，具体是否对交易转接应用进行降级可以通过其对应的降级标识或不降级标识来确定，降级标识又进一步细分为由于交易核验系统异常而得到的系统异常降级标识，以及由于交易请求被拒绝而得到的业务拒绝降级标识。
98.当然，需要说明的是，上述对交易转接应用进行降级的过程仅仅是暂时性的，为了保证交易的安全性，在触发降级后，可通知运维人员及时进行故障排查，以恢复正常的交易核验过程。
99.降级标识和不降级标识均是针对整个交易转接系统的维度来说的，如果本技术实施例获取到的交易转接系统的系统策略标识为系统异常降级标识，说明交易核验系统本身发生了异常情况，为了降低交易损失，可以暂时省去交易核验步骤，即可以将本地策略标识更新为系统异常降级标识，交易转接系统内的所有交易转接服务器的本地策略标识都会同步更新为系统异常降级标识，这样各交易转接服务器对接收到的交易请求都会采用直接放行至交易处理系统的处理策略，进而保证同一交易请求的处理结果的一致性。
100.在本技术的一个实施例中，所述交易请求中携带有机构标识，在根据所述系统异常降级标识，将接收到的交易请求放行至交易处理系统进行交易处理之前，所述方法还包括：确定所述交易请求中携带的机构标识是否在黑名单列表中；若在，则直接拒绝所述交易请求；若不在，则将所述交易请求放行至所述交易处理系统。
101.如前所述，一般情况下，如果本地策略标识已经更新为系统异常降级标识，则会对后续接收到的交易请求采用直接放行至交易处理系统的处理策略，但是考虑到交易的安全
性，避免出现重大的交易损失，在后续接收到的交易请求放行至交易处理系统进行交易处理之前，可以利用黑名单列表对这些交易请求的合法性等进行验证，黑名单列表中通常存储了不允许进行交易的机构名单，如果接收到的交易请求中所携带的机构标识在黑名单列表内，则直接拒绝该交易请求，后续可由人工介入进行处理，如果不在黑名单列表内，则可以将交易请求放行至交易处理系统进行具体的业务处理。
102.在本技术的一个实施例中，所述系统策略标识包括降级标识，所述降级标识包括业务拒绝降级标识，所述根据所述系统策略标识更新本地策略标识包括：若所述系统策略标识为所述业务拒绝降级标识，则将所述本地策略标识更新为所述业务拒绝降级标识；所述根据更新后的本地策略标识对应的交易请求处理策略，对接收到的交易请求进行处理包括：根据所述业务拒绝降级标识，直接拒绝所述交易请求。
103.如果本技术实施例获取到的交易转接系统的系统策略标识为业务拒绝降级标识，说明交易核验系统已经多次明确拒绝了该交易请求，为了避免后续交易核验系统再次接收到同样的交易请求，可以将本地策略标识更新为业务拒绝降级标识，交易转接系统内的所有交易转接服务器的本地策略标识都会同步更新为业务拒绝降级标识，这样各交易转接服务器对后续接收到的交易请求都会采取直接拒绝的处理策略，进而保证同一交易请求的处理结果的一致性。
104.在本技术的一个实施例中，所述系统策略标识包括不降级标识，所述根据所述系统策略标识更新本地策略标识包括：若所述系统策略标识为所述不降级标识，则将所述本地策略标识更新为所述不降级标识；所述根据更新后的本地策略标识对应的交易请求处理策略，对接收到的交易请求进行处理包括：根据所述不降级标识，将接收到的交易请求转发至交易核验系统进行核验。
105.如果获取到的交易转接系统的系统策略标识为不降级标识，则将本地策略标识也更新为不降级标识，对于后续接收到的交易请求正常转发至交易核验系统进行核验即可。
106.在本技术的一个实施例中，所述根据交易请求处理结果确定上报信息包括：接收所述交易核验系统返回的交易核验结果，所述交易核验结果的种类包括交易核验通过、交易核验系统异常和业务拒绝；根据所述交易核验结果统计系统异常次数和业务拒绝次数，以及根据接收到的交易请求统计接口访问次数；将所述系统异常次数、所述业务拒绝次数和所述接口访问次数中至少一项作为所述上报信息。
107.交易核验系统返回的核验结果可以包括交易核验通过、交易核验系统异常和业务拒绝三种情况。交易核验通过说明该交易请求符合合法性以及业务逻辑等的要求，可以进行后续的业务处理；交易核验系统异常说明交易核验系统发生了故障，导致无法及时对交易请求做出响应。业务拒绝说明经过交易核验系统对交易请求的合法性以及业务逻辑等的验证后，认为该交易请求不符合合法性或者业务逻辑等的要求，则直接拒绝该交易请求，暂时不能进行后续的业务处理。
108.当出现交易核验系统异常或者业务拒绝的情况时，说明这笔交易没有成功，即出现了交易损失，因此为了降低交易损失率，提高了业务的成交量，可以根据交易核验系统返回的核验结果，按照一定时间例如每分钟，对系统异常次数、业务拒绝次数进行统计，同时根据接收到的交易请求对接口访问次数进行统计，然后将系统异常次数、业务拒绝次数和接口访问次数这三个指标作为上报信息上报给交易核验系统中的redis数据库，以使redis
数据库对上报信息分析处理后确定是否要调整系统策略标识，以降低交易损失率。
109.如果redis数据库对系统策略标识的更新失败，需要尽可能的使该次更新补偿成功，例如可以调用重试机制，在第一次更新失败后会重试两次，使更新补偿尽可能成功。如果采用重试机制也不能成功，则触发告警，由人工介入处理。
110.在本技术的一个实施例中，所述方法还包括：若无法获取所述系统策略标识，则直接根据所述上报信息确定所述本地策略标识。
111.如前述实施例，系统策略标识可以存储在redis数据库中进行管理，如果redis数据库发生故障，将无法从redis数据库中获取到系统策略标识，此时可以调用本地自动降级机制对交易请求进行处理，本地自动降级机制针对的是单个交易转接服务器，虽然本地自动降级机制会存在前述的不同的交易转接服务器的降级标识不一致导致交易请求不能幂等处理等问题，但是这里出于降低交易损失率的考虑，可以在redis数据库故障等异常情况下，采用本地自动降级机制，避免对系统降级机制的强依赖。
112.默认情况下，本地的自动降级机制的优先级低于系统降级机制，即优先调用系统降级机制，仅在系统降级机制出现异常如redis数据库发生故障等情况下，才会调用本地的自动降级机制。
113.在本技术的一个实施例中，所述上报信息包括系统异常次数、业务拒绝次数和接口访问次数，所述若无法获取所述系统策略标识，则直接根据所述上报信息确定所述本地策略标识包括：根据所述系统异常次数和所述接口访问次数，计算所述交易请求的第一失败率；若所述系统异常次数触发系统异常次数阈值，且所述第一失败率触发第一失败率阈值，则更新所述本地策略标识为所述系统异常降级标识。
114.具体地，如果出现交易核验系统异常的情况，说明该笔交易失败，此时可以根据系统异常次数，以及系统异常次数与接口访问次数的比值即第一失败率确定是否更新本地策略标识为系统异常降级标识。
115.上述采用系统异常次数和第一失败率两个指标来综合确定本地策略标识的原因主要是出于以下两点的考虑：1)由于系统异常次数仅仅是一定时间段如每分钟的统计，若仅通过系统异常次数进行判断，如果每分钟都仅仅只有一个或者少数几个交易请求由于交易核验系统的异常而交易失败，但都没有触发系统异常次数阈值，就会导致持续的交易损失；2)当一分钟内的交易请求的数量较少时，只要有一个或者少数几个交易请求由于交易核验系统的异常而交易失败，可能就会导致较高的第一失败率，因此若仅通过第一失败率进行判断，就会出现频繁触发本地自动降级机制的情况。
116.因此为了避免出现上述问题，在交易核验系统异常的情况下更新本地策略标识时，可以采用系统异常次数和第一失败率两个指标来综合确定本地策略标识。具体地，如果系统异常次数触发系统异常次数阈值，并且第一失败率也触发了第一失败率阈值，则将本地策略标识更新为系统异常降级标识。
117.在本技术的一个实施例中，所述若无法获取所述系统策略标识，则直接根据所述上报信息确定所述本地策略标识包括：根据所述业务拒绝次数和所述接口访问次数，计算所述交易请求的第二失败率；若所述业务拒绝次数触发业务拒绝次数阈值，且所述第二失败率触发第二失败率阈值，则更新所述本地策略标识为所述业务拒绝降级标识。
118.具体地，如果出现业务拒绝的情况，同样说明该笔交易失败，为了避免上述提及的
持续的交易损失或者频繁触发本地自动降级机制的情况，在业务拒绝的情况下更新本地策略标识时，可以根据业务拒绝次数，以及业务拒绝次数与接口访问次数的比值即第二失败率确定是否更新本地策略标识为业务拒绝降级标识。如果业务拒绝次数触发业务拒绝次数阈值，并且第二失败率也触发了第二失败率阈值，则可以将本地策略标识更新为业务拒绝降级标识。
119.现有的本地自动降级方案并未区分交易核验系统异常和业务拒绝两种情况，而是根据系统异常次数和业务拒绝次数之和是否触发阈值来确定是否要调用本地自动降级机制。这样存在的问题是，系统异常次数和业务拒绝次数在统计时会相互影响，如果由于业务拒绝次数较高，导致两者之和触发阈值，就会出现放行本应该拒绝的交易请求的问题，进而疏漏真正的交易风险。而本技术的本地自动降级机制在上述实施例中对交易核验系统异常和业务拒绝两种情况进行了区分，分别设置了相应的阈值进行判断，进而可以避免疏漏真正的交易风险。
120.如图5所示，提供了一种交易请求的处理逻辑框图。对于任意一个交易转接服务器来说，先开启异步任务，获取redis数据库的redis状态标识，如果redis状态标识为正常状态，则向redis数据库请求获取系统策略标识；如果能够正常获取到系统策略标识，则根据获取到的系统策略标识更新本地策略标识；根据更新后的本地策略标识对应的交易请求处理策略，对接收到的交易请求进行处理，这里如果系统策略标识为降级标识，则直接结束本次异步任务，如果系统策略标识为不降级标识，则获取系统异常次数、业务拒绝次数和接口访问次数，并将系统异常次数、业务拒绝次数和接口访问次数等上报信息上报给redis数据库，由redis数据库计算分析是否触发系统降级机制对应的阈值，如果触发，则更新系统策略标识为降级标识。
121.上述过程中，如果从redis数据库中无法获取到系统策略标识，或者无法将上报信息上报给redis数据库，则统计redis数据库的异常次数，如果该异常次数触发相应的异常次数阈值，则更新redis状态标识为redis故障标识。
122.如果获取到的redis状态标识为redis故障标识，则可以调用本地自动降级机制对交易请求进行处理，然后直接获取系统异常次数、业务拒绝次数和接口访问次数，并根据系统异常次数、业务拒绝次数和接口访问次数确定是否触发本地自动降级机制对应的阈值，如果触发，则更新本地策略标识为降级标识，然后确定接收到的交易请求中携带的机构标识是否在黑名单列表中，如果在，则直接拒绝该交易请求；如果没有触发本地自动降级机制对应的阈值，则调用交易核验系统，对接收到的交易请求进行核验，得到交易核验通过、业务拒绝或者不明确的处理结果，并以此更新系统异常次数、业务拒绝次数和接口访问次数。
123.本技术实施例还提供了一种交易请求的处理装置600，应用于交易转接系统中的各交易转接服务器，其中，如图6所示，所述装置600包括：
124.获取单元610，用于获取系统策略标识，所述系统策略标识为生效于所述交易转接系统的策略标识；
125.第一更新单元620，用于根据所述系统策略标识更新本地策略标识，所述本地策略标识为生效于各交易转接服务器的策略标识；
126.交易请求处理单元630，用于根据更新后的本地策略标识，对接收到的交易请求进行处理；
127.第一确定单元640，用于根据交易请求处理结果确定上报信息。
128.在本技术的一个实施例中，所述交易转接系统还包括预设的redis数据库，所述系统策略标识保存在所述redis数据库中，所述获取单元610具体用于：确定所述redis数据库的redis状态标识；在所述redis状态标识指示所述redis数据库正常的情况下，向所述redis数据库请求获取所述系统策略标识。
129.在本技术的一个实施例中，所述装置还包括：第二确定单元，用于根据向所述redis数据库请求的结果确定请求失败的次数；第二更新单元，用于若预设时间内所述请求失败的次数达到第一阈值，则将所述redis状态标识更新为redis故障标识，所述redis故障标识用于指示所述redis数据库故障。
130.在本技术的一个实施例中，所述装置还包括：上报单元，用于将所述上报信息上报至所述redis数据库，以使所述redis数据库能够根据所述上报信息更新所述系统策略标识；第三确定单元，用于根据上报结果确定上报失败的次数；第三更新单元，用于若所述上报失败的次数达到第二阈值，则将所述redis状态标识更新为redis故障标识。
131.在本技术的一个实施例中，所述系统策略标识包括降级标识，所述降级标识包括系统异常降级标识，所述第一更新单元620具体用于：若所述系统策略标识为所述系统异常降级标识，则将所述本地策略标识更新为所述系统异常降级标识；所述交易请求处理单元630具体用于：根据所述系统异常降级标识，将接收到的交易请求放行至交易处理系统进行交易处理。
132.在本技术的一个实施例中，所述交易请求中携带有机构标识，在根据所述系统异常降级标识，将接收到的交易请求放行至交易处理系统进行交易处理之前，所述装置还包括：第四确定单元，用于确定所述交易请求中携带的机构标识是否在黑名单列表中；拒绝单元，用于若在，则直接拒绝所述交易请求；放行单元，用于若不在，则将所述交易请求放行至所述交易处理系统。
133.在本技术的一个实施例中，所述系统策略标识包括降级标识，所述降级标识包括业务拒绝降级标识，所述第一更新单元620具体用于：若所述系统策略标识为所述业务拒绝降级标识，则将所述本地策略标识更新为所述业务拒绝降级标识；所述交易请求处理单元630具体用于：根据所述业务拒绝降级标识，直接拒绝所述交易请求。
134.在本技术的一个实施例中，所述系统策略标识包括不降级标识，所述第一更新单元620具体用于：若所述系统策略标识为所述不降级标识，则将所述本地策略标识更新为所述不降级标识；所述交易请求处理单元630具体用于：根据所述不降级标识，将接收到的交易请求转发至交易核验系统进行核验。
135.在本技术的一个实施例中，所述第一确定单元630具体用于：接收所述交易核验系统返回的交易核验结果，所述交易核验结果的种类包括交易核验通过、交易核验系统异常和业务拒绝；根据所述交易核验结果统计系统异常次数和业务拒绝次数，以及根据接收到的交易请求统计接口访问次数；将所述系统异常次数、所述业务拒绝次数和所述接口访问次数中至少一项作为所述上报信息。
136.在本技术的一个实施例中，所述装置还包括：第五确定单元，用于若无法获取所述系统策略标识，则直接根据所述上报信息确定所述本地策略标识。
137.在本技术的一个实施例中，所述上报信息包括系统异常次数、业务拒绝次数和接
口访问次数，所述第五确定单元具体用于：根据所述系统异常次数和所述接口访问次数，计算所述交易请求的第一失败率；若所述系统异常次数触发系统异常次数阈值，且所述第一失败率触发第一失败率阈值，则更新所述本地策略标识为所述系统异常降级标识。
138.在本技术的一个实施例中，所述第五确定单元具体用于：根据所述业务拒绝次数和所述接口访问次数，计算所述交易请求的第二失败率；若所述业务拒绝次数触发业务拒绝次数阈值，且所述第二失败率触发第二失败率阈值，则更新所述本地策略标识为所述业务拒绝降级标识。
139.能够理解，上述交易请求的处理装置，能够实现前述实施例中提供的由交易转接服务器执行的交易请求的处理方法的各个步骤，关于交易请求的处理方法的相关阐释均适用于交易请求的处理装置，此处不再赘述。
140.图7是本技术的另一个实施例交易转接系统的结构示意图。请参考图7，该交易转接系统包括多个交易转接服务器，在硬件层面，各交易转接服务器均包括处理器，可选地还包括内部总线、网络接口、存储器。其中，存储器可能包含内存，例如高速随机存取存储器(random-access memory，ram)，也可能还包括非易失性存储器(non-volatile memory)，例如至少1个磁盘存储器等。当然，该电子设备还可能包括其他业务所需要的硬件。
141.处理器、网络接口和存储器可以通过内部总线相互连接，该内部总线可以是isa(industry standard architecture，工业标准体系结构)总线、pci(peripheral component interconnect，外设部件互连标准)总线或eisa(extended industry standard architecture，扩展工业标准结构)总线等。所述总线可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一个双向箭头表示，但并不表示仅有一根总线或一种类型的总线。
142.存储器，用于存放程序。具体地，程序可以包括程序代码，所述程序代码包括计算机操作指令。存储器可以包括内存和非易失性存储器，并向处理器提供指令和数据。
143.处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成交易对账装置。处理器，执行存储器所存放的程序，并具体用于执行以下操作：
144.获取系统策略标识，所述系统策略标识为生效于所述交易转接系统的策略标识；
145.根据所述系统策略标识更新本地策略标识，所述本地策略标识为生效于各交易转接服务器的策略标识；
146.根据更新后的本地策略标识，对接收到的交易请求进行处理；
147.根据交易请求处理结果确定上报信息。
148.上述如本技术图6所示实施例揭示的交易请求的处理装置执行的方法可以应用于处理器中，或者由处理器实现。处理器可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器可以是通用处理器，包括中央处理器(central processing unit，cpu)、网络处理器(network processor，np)等；还可以是数字信号处理器(digital signal processor，dsp)、专用集成电路(application specific integrated circuit，asic)、现场可编程门阵列(field－programmable gate array，fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本技术实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处
理器等。结合本技术实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成上述方法的步骤。
149.该交易转接系统还可执行图6中交易请求的处理装置执行的方法，并实现交易请求的处理装置在图6所示实施例的功能，本技术实施例在此不再赘述。
150.本技术实施例还提出了一种计算机可读存储介质，该计算机可读存储介质存储一个或多个程序，该一个或多个程序包括指令，该指令当被包括多个应用程序的交易转接服务器执行时，能够使该交易转接服务器执行图6所示实施例中交易请求的处理装置执行的方法，并具体用于执行：
151.获取系统策略标识，所述系统策略标识为生效于所述交易转接系统的策略标识；
152.根据所述系统策略标识更新本地策略标识，所述本地策略标识为生效于各交易转接服务器的策略标识；
153.根据更新后的本地策略标识，对接收到的交易请求进行处理；
154.根据交易请求处理结果确定上报信息。
155.本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
156.本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
157.这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
158.这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
159.在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。
160.内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flash ram)。内存是计算机可读介质的
示例。
161.计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
162.还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
163.本领域技术人员应明白，本技术的实施例可提供为方法、系统或计算机程序产品。因此，本技术可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本技术可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
164.以上所述仅为本技术的实施例而已，并不用于限制本技术。对于本领域技术人员来说，本技术可以有各种更改和变化。凡在本技术的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本技术的权利要求范围之内。