资源数据处理的方法及系统、设备及存储介质与流程

1.本公开涉及大数据技术领域，尤其涉及一种资源数据处理的方法及系统、设备及存储介质。


背景技术：

2.现在互联网业务中，每一次交易、展示和支付的执行过程均是非常复杂的。比如电商业务，用户在收银台进行支付时，点击确认支付按钮，其可能要调用上百个系统进行协同处理。在这么多业务协同处理时，随时可能会发生各种异常情况，比如接口超时，系统出现bug等等。每一种异常出现时都会影响到用户的当前交易流程以及用户的体验，甚至影响到gmv(gross merchandise volume，即商品交易总额)。
3.现有的技术方法中，当出现异常时，通常是对整个接口进行熔断处理。比如发生异常时，上游接口对当前调用接口进行熔断，熔断后不再进行请求访问。然而，这种通过对接口进行熔断的技术并不适用所有的业务场景，例如，在同一个与交易相关联的接口下，所述接口用于调取多个类型的资源数据或子业务场景数据，在该接口下的某一种子业务场景数据或资源数据发生了异常，若对该接口进行熔断，则导致该接口下的其他子业务场景数据或资源数据均不可用。


技术实现要素：

4.为了解决上述技术问题或者至少部分地解决上述技术问题，本公开的实施例提供了一种资源数据处理的方法及系统、设备及存储介质。
5.第一方面，本公开的实施例提供了一种资源数据处理的方法，应用于与交易相关联的接口，所述接口用于调取多个类型的资源，所述方法包括：
6.对于每个类型的资源，收集当前类型的资源的总使用次数和使用失败次数；
7.根据当前类型的资源的总使用次数和使用失败次数确定当前类型的资源的使用失败率；
8.判断所述当前类型的资源的使用失败率是否达到预设的使用失败率阈值：
9.当所述当前类型的资源的使用失败率达到使用失败率阈值时，对当前类型的资源进行熔断。
10.在一种可能的实施方式中，所述方法还包括：
11.对于已熔断的资源，累计资源的熔断时长；
12.判断资源的熔断时长是否达到预设的时长阈值：
13.当资源的熔断时长达到预设的时长阈值时，对当前资源进行熔断关闭。
14.在一种可能的实施方式中，所述收集当前类型的资源的使用失败次数，包括：响应于当前类型的资源使用失败的原因为当前资源的配置信息有误，累计当前类型的资源的使用失败次数。
15.在一种可能的实施方式中，所述方法还包括：响应于当前类型的资源使用失败的
原因为当前资源类型所对应的接口超时，对当前类型的资源所对应的接口进行熔断，不累计资源的使用失败次数。
16.在一种可能的实施方式中，在所述收集当前类型的资源的总使用次数和使用失败次数之前，所述方法还包括：
17.响应于接收到的资源查询请求，基于已知的熔断资源列表，判断与所述资源查询请求所匹配的资源是否处于熔断状态：
18.当所述资源处于熔断状态时，不显示当前资源；
19.当所述资源未处于熔断状态时，显示当前资源，用于交易使用。
20.在一种可能的实施方式中，所述已知的熔断资源列表通过以下步骤得到：
21.采集所有资源的熔断状态，将已熔断的所有资源汇集为已知的熔断资源列表，用于判断与所述资源查询请求所匹配的资源是否处于熔断状态。
22.在一种可能的实施方式中，在基于已知的熔断资源列表，判断与所述资源查询请求所匹配的资源是否处于熔断状态之前，所述方法还包括：
23.判断所述资源查询请求所匹配的资源与所述资源查询请求中的交易订单和交易者的信息是否对应：
24.当所述资源查询请求所匹配的资源与所述资源查询请求中的交易订单和交易者的信息对应时，执行判断与所述资源查询请求所匹配的资源是否处于熔断状态的步骤。
25.第二方面，本公开的实施例提供了一种资源数据处理的系统，应用于与交易相关联的接口，所述接口用于调取多个类型的资源，所述系统包括：
26.调度器，其用于对于每个类型的资源，收集当前类型的资源的总使用次数和使用失败次数；根据当前类型的资源的总使用次数和使用失败次数确定当前类型的资源的使用失败率；判断所述当前类型的资源的使用失败率是否达到预设的使用失败率阈值：当所述当前类型的资源的使用失败率达到使用失败率阈值时，对当前类型的资源进行熔断。
27.在一种可能的实施方式中，所述系统还包括：
28.使用端，其用于提供当前类型的资源的总使用次数和使用失败次数；
29.查询端，其用于响应于接收到的资源查询请求，从调度器汇集的已知的熔断资源列表中，判断与所述资源查询请求所匹配的资源是否处于熔断状态，在所述资源未处于熔断状态时，显示当前资源，用于交易使用。
30.第三方面，本公开的实施例提供了一种电子设备，包括处理器、通信接口、存储器和通信总线，其中，处理器、通信接口和存储器通过通信总线完成相互间的通信；
31.存储器，用于存放计算机程序；
32.处理器，用于执行存储器上所存放的程序时，实现上述的资源数据处理的方法。
33.第四方面，本公开的实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述的资源数据处理的方法。
34.本公开实施例提供的上述技术方案与现有技术相比至少具有如下优点的部分或全部：
35.本公开实施例所述的资源数据处理的方法及系统，应用于与交易相关联的接口，所述接口用于调取多个类型的资源，对于每个类型的资源，收集当前类型的资源的总使用次数和使用失败次数；根据当前类型的资源的总使用次数和使用失败次数确定当前类型的
资源的使用失败率；判断所述当前类型的资源的使用失败率是否达到预设的使用失败率阈值：当所述当前类型的资源的使用失败率达到使用失败率阈值时，对当前类型的资源进行熔断，能够在系统中某个业务数据、某个子场景数据甚至某种数据发生异常时对数据进行熔断，保障系统整体的可用率和稳定性，确保用户的体验不受影响，也不会对其他数据的使用产生影响。
附图说明
36.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。
37.为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
38.图1示意性示出了根据本公开实施例的资源数据处理的方法的流程示意图；
39.图2示意性示出了根据本公开另一实施例的资源数据处理的方法的流程示意图；
40.图3示意性示出了根据本公开又一实施例的资源数据处理的方法的流程示意图；
41.图4示意性示出了根据本公开又一实施例的资源数据处理的方法的流程示意图；
42.图5示意性示出了现有技术中资源数据处理的系统的结构框图；
43.图6示意性示出了根据本公开实施例的资源数据处理的系统的结构框图；
44.图7(a)示意性示出了根据本公开实施例的资源数据处理的系统的使用端的工作流程示意图；
45.图7(b)示意性示出了根据本公开实施例的资源数据处理的系统的调度器的工作流程示意图；
46.图7(c)示意性示出了根据本公开实施例的资源数据处理的系统的查询端的工作流程示意图；以及
47.图8示意性示出了根据本公开实施例的电子设备的结构框图。
具体实施方式
48.为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开的一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本公开保护的范围。
49.参见图1，本公开的实施例提供了一种资源数据处理的方法，应用于与交易相关联的接口，所述接口用于调取多个类型的资源，所述方法包括以下步骤：
50.s1，对于每个类型的资源，收集当前类型的资源的总使用次数和使用失败次数；
51.在实际应用中，多个类型的资源可以是多种优惠券，这里的总使用次数和使用失败次数为一种优惠券的总使用次数和使用失败次数。
52.s2，根据当前类型的资源的总使用次数和使用失败次数确定当前类型的资源的使用失败率；
53.s3，判断所述当前类型的资源的使用失败率是否达到预设的使用失败率阈值：
54.若是，则执行步骤s4；
55.若否，则不予响应；
56.s4，对当前类型的资源进行熔断；
57.s5，对于已熔断的资源，累计资源的熔断时长；
58.s6，判断资源的熔断时长是否达到预设的时长阈值：
59.若是，则执行步骤s7；
60.若否，则执行步骤s8；
61.s7，对已熔断的资源进行熔断关闭；
62.s8，使已熔断的资源资源保持熔断状态。
63.本实施例中，参见图2，步骤s1中，所述收集当前类型的资源的使用失败次数，包括：
64.s21，响应于当前类型的资源使用失败的原因为当前资源的配置信息有误，累计资源的使用失败次数；
65.在实际应用中，当前资源的配置信息有误包括当前资源配置的规则依赖于其他下游接口，由于下游接口出现问题导致无法对当前资源进行调用验证。
66.s22，响应于当前类型的资源使用失败的原因为资源所对应的接口超时问题，对当前类型的资源对应的接口进行熔断，不累计资源的使用失败次数。
67.在实际应用中，接口超时通过以下方式进行定义：对于资源调用方和资源提供方，可以设置接口超时时间。以资源调用方为例，资源调用方需要调用远程的一个接口，为了保证服务的质量，一般会设置调用接口的超时时间，比如将调用接口的超时时间设置为1秒，当调用远程接口后，经过1秒还未拿到结果，那么就认为是接口超时。
68.本实施例中，参见图3，步骤s1中，在所述收集当前类型的资源的总使用次数和使用失败次数之前，所述方法还包括：
69.s31，响应于接收到的资源查询请求，基于已知的熔断资源列表，判断与所述资源查询请求所匹配的资源是否处于熔断状态：
70.若是，则执行步骤s32；
71.若否，则执行步骤s33；
72.s32，不显示当前资源；
73.s33，显示当前资源，用于交易使用。
74.本实施例中，参见图4，步骤s31中，所述已知的熔断资源列表通过以下步骤得到：
75.s41，采集所有资源的熔断状态；
76.s42，将已熔断的所有资源汇集为已知的熔断资源列表，用于判断与所述资源查询请求所匹配的资源是否处于熔断状态。
77.本实施例中，步骤s33中，在基于已知的熔断资源列表，判断与所述资源查询请求所匹配的资源是否处于熔断状态之前，所述方法还包括：
78.判断所述资源查询请求所匹配的资源与所述资源查询请求中的交易订单和交易者的信息是否对应：
79.当所述资源查询请求所匹配的资源与所述资源查询请求中的交易订单和交易者的信息对应时，执行判断与所述资源查询请求所匹配的资源是否处于熔断状态的步骤。
80.基于同一发明构思，本公开的第二个示例性实施例提供的资源数据处理的系统，应用于与交易相关联的接口，所述接口用于调取多个类型的资源，所述系统包括调度器、使用端和查询端。
81.本实施例中，调度器，其用于对于每个类型的资源，收集当前类型的资源的总使用次数和使用失败次数；根据当前类型的资源的总使用次数和使用失败次数确定当前类型的资源的使用失败率；判断所述当前类型的资源的使用失败率是否达到预设的使用失败率阈值：当所述当前类型的资源的使用失败率达到使用失败率阈值时，对当前类型的资源进行熔断。
82.在实际应用中，通过对当前类型的资源的总使用次数和使用失败次数进行实时采集，保存到redis中进行存储，并进行数据的汇总和处理，在将最终结果数据保存到zookeeper(以下简称zk)中进行广播。
83.本实施例中，使用端，其用于提供当前类型的资源的总使用次数和使用失败次数；
84.本实施例中，查询端，其用于响应于接收到的资源查询请求，从调度器汇集的已知的熔断资源列表中，判断与所述资源查询请求所匹配的资源是否处于熔断状态，在所述资源未处于熔断状态时，显示当前资源，用于交易使用。
85.本实施例中，调度器还用于：
86.对于已熔断的资源，累计资源的熔断时长；
87.判断资源的熔断时长是否达到预设的时长阈值：
88.当资源的熔断时长达到预设的时长阈值时，对当前资源进行熔断关闭。
89.本实施例中，使用端还用于：
90.响应于当前类型的资源使用失败的原因为当前资源的配置信息有误，累计当前类型的资源的使用失败次数。
91.本实施例中，使用端还用于：
92.响应于当前类型的资源使用失败的原因为当前资源类型所对应的接口超时，对当前类型的资源所对应的接口进行熔断，不累计资源的使用失败次数。
93.本实施例中，查询端还用于：
94.响应于接收到的资源查询请求，基于已知的熔断资源列表，判断与所述资源查询请求所匹配的资源是否处于熔断状态：
95.当所述资源处于熔断状态时，不显示当前资源；
96.当所述资源未处于熔断状态时，显示当前资源，用于交易使用。
97.本实施例中，调度器还用于：
98.采集所有资源的熔断状态，将已熔断的所有资源汇集为已知的熔断资源列表，用于判断与所述资源查询请求所匹配的资源是否处于熔断状态。
99.本实施例中，使用端还用于：
100.在基于已知的熔断资源列表，判断与所述资源查询请求所匹配的资源是否处于熔断状态之前，判断所述资源查询请求所匹配的资源与所述资源查询请求中的交易订单和交易者的信息是否对应：
101.当所述资源查询请求所匹配的资源与所述资源查询请求中的交易订单和交易者的信息对应时，执行判断与所述资源查询请求所匹配的资源是否处于熔断状态的步骤。
102.本实施例中，参见图5和图6，在资源为优惠券的应用场景下，对比了现有技术与本公开的资源数据处理的系统的工作流程。
103.应用场景：系统提供给用户多种不同的优惠券，每一种都有其使用场景，用户购买不同商品时会用到不同的优惠券，当某一种优惠券由于数据、系统等问题发生异常时及时对其进行熔断下线，而其他优惠券不受影响。
104.参见图5，现有技术的使用场景下，分为“优惠券查询端”和“优惠券使用端”，两者的交互流程如下：
105.优惠券查询端，当交易开始时，根据订单、用户等基本信息对优惠券进行过滤，将匹配结果给用户以展示出来；
106.优惠券使用端，当用户支付时系统对展示出来的优惠券进行使用，首先，验证优惠券合法性(这里通常和查询一样，根据订单、用户信息对优惠券进行验证)，将使用结果写入db(datebase，数据库)，然后返回给调用端最终结果。
107.图5所示的系统无法达到以下效果：比如系统中目前存在a_1，a_2，a_3，a_4，a_5 5张优惠券可供用户使用，由于运营配置失误，导致a_3这张优惠券可以对用户展示，当用户在支付使用时提示失败，严重影响到用户体验。这种场景下，需要对优惠券a_3进行熔断，但其余4张优惠券a_1，a_2，a_4，a_5不受任何影响，能够正常使用。
108.因此，为系统新增基于业务的熔断降级功能，参见图6，整体交互流程如下：将系统流程分为三部分：“优惠券查询端”，“优惠券使用端”和“调度器”。这三部分从系统熔断降级的顺序出发，依次解释“优惠券使用端”，“调度器”和“优惠券查询端”。
109.参见图7(a)，优惠券使用端：
110.数据采集部分为核心内容。用户在使用优惠券时，合法性验证、写入数据库之后，对数据进行采集，采集部分主要是统计出当前优惠券的总使用次数和使用失败次数。这里，总使用次数对每一笔交易都进行记录，而使用失败记录只有在当前这笔交易使用失败时才进行统计。值得注意的是，这里统计失败时必须明确对应场景，只有是优惠券本身的信息导致消费失败时才进行统计，若系统之间的超时问题导致消费失败时，不能给予统计，否则会造成全部优惠券熔断。至于系统超时问题，使用接口级熔断器，比如hystrix，该熔断器针对接口的返回码进行熔断。
111.对需要的数据统计之后，使用redis的incr函数进行存储，总使用次数和失败次数分开保存。数据保存完成之后给调用端接口返回使用结果。需要注意的是，数据采集过程中也可能会发生异常，但这种异常通过用一个异步线程来保证不影响给调用端的返回结果。使用redis(redis是一个开源的使用ansi c语言编写、支持网络、可基于内存亦可持久化的日志型、key-value数据库，并提供多种语言的api)时的key可以是用优惠券编号作为前缀，优惠券的总使用次数和失败次数累计值作为value。
112.参见图7(b)，调度器：
113.调度器(可以执行定时任务，系统每隔一定时间执行一次代码)中，定时对“优惠券使用端”中采集到的数据进行汇总统计。首先，分析图中“获取采集数据”这条链路：调度器定时从redis中获取采集到的数据，根据失败次数和总使用次数的比例来判断某张优惠券是否达到熔断阀值。比如，预先规定当失败率达到50％时进行熔断，则当失败次数/总使用次数》＝50％时，说明达到了熔断阀值，需要对其进行熔断。
114.接下来对流程中的“获取当前以及被熔断优惠券”进行解释：因为调度器在进行处理时，可能已经存在某些优惠券处于熔断状态，这些优惠券有些依然处于需要被熔断状态，有些经过一定时间的熔断将要被释放开，不再进行熔断(类似熔断器中的打开、关闭操作)。需要对这些目前熔断中的优惠券进行分析，获取出在接下来操作中仍然需要被熔断的优惠券和需要被关闭熔断的优惠券。这里判断分析的依据可以通过某个优惠券被熔断的时长来判断，比如，预先规定一次熔断的有效期是1分钟，则根据每一个目前熔断中的优惠券的熔断时长进行判断，若其已经达到1分钟，则对其进行熔断关闭，否则依然熔断。
115.通过以上两步对数据采集之后，获得了最新需要熔断的优惠券列表，将这些优惠券推送到zk(zookeeper，zookeeper是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于zookeeper实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、master选举、分布式锁和分布式队列等功能)中。推送时附带当前的时间信息，根据时间可以计算是否熔断被关闭。
116.参见图7(c)，优惠券查询端：
117.查询端中，业务系统接收从zookeeper广播的熔断列表数据保存到服务器内存，当优惠券匹配出结果后，在对结果判定优惠券是否在熔断列表中，如果存在，则不返回当前优惠券；如果不在熔断列表中，则返回当前优惠券。
118.本实施例的系统可以是计算机软件平台等。
119.本实施例的系统通过上面的协同处理，可以实现细粒度的熔断，根据异常情况进行快速熔断，可以针对相同系统流程中不同的业务数据做特殊化处理，比如某个数据发生异常时只是对该数据进行熔断降级，其他数据不受任何影响。
120.本实施例的系统通过对比图5和图6可知，开发成本较低，系统接入成本低，学习成本低，并且对原有业务不受太大影响，无需过多改造。
121.本实施例的系统的查询端收到广播数据之后进行内存计算，对整体流程而言无任何性能损耗，并且在秒级时间内快速熔断，确保用户体验。
122.本实施例的系统不仅可以用在优惠券熔断场景中，至于其他场景同样适用。
123.在本实施例中，根据不同的异常情况确定不同的熔断方案，当发生严重超时，需要对下游接口进行熔断，以对其进行保护；当异常属于个别业务的情况，不能对整个接口进行降级，比如电商系统中经常用到优惠券，成百上千个优惠券，当某一张优惠券由于数据问题导致用户使用失败时，对其进行熔断降级，不影响其他优惠券的使用，能够针对业务系统中的不同业务类型、不同数据进行业务熔断，以通过业务熔断保证整体接口的可用率，单个数据的熔断不影响其他相关数据和业务。
124.值得说明的时，本实施例的资源可以是商品等虚拟资源。
125.上述系统中各个部分的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
126.对于系统实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本公开方案的目的。本领域普通技术人员在不付
出创造性劳动的情况下，即可以理解并实施。
127.基于同一发明构思，参照图8所示，本公开的第三个示例性实施例提供的电子设备，包括处理器1110、通信接口1120、存储器1130和通信总线1140，其中，处理器1110，通信接口1120，存储器1130通过通信总线1140完成相互间的通信；
128.存储器1130，用于存放计算机程序；
129.处理器1110，用于执行存储器1130上所存放的程序时，实现如下所示资源数据处理的方法：
130.收集资源的总使用次数和使用失败次数；
131.根据资源的总使用次数和使用失败次数确定资源的使用失败率；
132.判断所述资源的使用失败率是否达到预设的使用失败率阈值：
133.当所述资源的使用失败率达到使用失败率阈值时，对当前资源进行熔断。
134.上述的通信总线1140可以是外设部件互连标准(peripheral component interconnect，简称pci)总线或扩展工业标准结构(extended industry standard architecture，简称eisa)总线等。该通信总线1140可以分为地址总线、数据总线、控制总线等。为便于表示，图中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
135.通信接口1120用于上述电子设备与其他设备之间的通信。
136.存储器1130可以包括随机存取存储器(random access memory，简称ram)，也可以包括非易失性存储器(non-volatile memory)，例如至少一个磁盘存储器。可选的，存储器1130还可以是至少一个位于远离前述处理器1110的存储装置。
137.上述的处理器1110可以是通用处理器，包括中央处理器(central processing unit，简称cpu)、网络处理器(network processor，简称np)等；还可以是数字信号处理器(digital signal processing，简称dsp)、专用集成电路(application specific integrated circuit，简称asic)、现场可编程门阵列(field-programmable gate array，简称fpga)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。
138.基于同一发明构思，本公开的第四个示例性实施例还提供了一种计算机可读存储介质。上述计算机可读存储介质上存储有计算机程序，上述计算机程序被处理器执行时实现如上所述的资源数据处理的方法。
139.该计算机可读存储介质可以是上述实施例中描述的设备/装置中所包含的；也可以是单独存在，而未装配入该设备/装置中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的资源数据处理的方法。
140.根据本公开的实施例，计算机可读存储介质可以是非易失性的计算机可读存储介质，例如可以包括但不限于：便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
141.需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在
涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
142.以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所示的这些实施例，而是要符合与本文所申请的原理和新颖特点相一致的最宽的范围。

技术特征：
1.一种资源数据处理的方法，其特征在于，应用于与交易相关联的接口，所述接口用于调取多个类型的资源，所述方法包括：对于每个类型的资源，收集当前类型的资源的总使用次数和使用失败次数；根据当前类型的资源的总使用次数和使用失败次数确定当前类型的资源的使用失败率；判断所述当前类型的资源的使用失败率是否达到预设的使用失败率阈值：当所述当前类型的资源的使用失败率达到使用失败率阈值时，对当前类型的资源进行熔断。2.根据权利要求1所述的方法，其特征在于，所述方法还包括：对于已熔断的资源，累计资源的熔断时长；判断资源的熔断时长是否达到预设的时长阈值：当资源的熔断时长达到预设的时长阈值时，对当前资源进行熔断关闭。3.根据权利要求1所述的方法，其特征在于，所述收集当前类型的资源的使用失败次数，包括：响应于当前类型的资源使用失败的原因为当前资源的配置信息有误，累计当前类型的资源的使用失败次数。4.根据权利要求3所述的方法，其特征在于，所述方法还包括：响应于当前类型的资源使用失败的原因为当前资源类型所对应的接口超时，对当前类型的资源所对应的接口进行熔断，不累计资源的使用失败次数。5.根据权利要求1所述的方法，其特征在于，在所述收集当前类型的资源的总使用次数和使用失败次数之前，所述方法还包括：响应于接收到的资源查询请求，基于已知的熔断资源列表，判断与所述资源查询请求所匹配的资源是否处于熔断状态：当所述资源处于熔断状态时，不显示当前资源；当所述资源未处于熔断状态时，显示当前资源，用于交易使用。6.根据权利要求5所述的方法，其特征在于，所述已知的熔断资源列表通过以下步骤得到：采集所有资源的熔断状态，将已熔断的所有资源汇集为已知的熔断资源列表，用于判断与所述资源查询请求所匹配的资源是否处于熔断状态。7.根据权利要求5所述的方法，其特征在于，在基于已知的熔断资源列表，判断与所述资源查询请求所匹配的资源是否处于熔断状态之前，所述方法还包括：判断所述资源查询请求所匹配的资源与所述资源查询请求中的交易订单和交易者的信息是否对应：当所述资源查询请求所匹配的资源与所述资源查询请求中的交易订单和交易者的信息对应时，执行判断与所述资源查询请求所匹配的资源是否处于熔断状态的步骤。8.一种资源数据处理的系统，其特征在于，应用于与交易相关联的接口，所述接口用于调取多个类型的资源，所述系统包括：调度器，其用于对于每个类型的资源，收集当前类型的资源的总使用次数和使用失败次数；根据当前类型的资源的总使用次数和使用失败次数确定当前类型的资源的使用失败率；判断所述当前类型的资源的使用失败率是否达到预设的使用失败率阈值：当所述当前
类型的资源的使用失败率达到使用失败率阈值时，对当前类型的资源进行熔断。9.根据权利要求8所述的系统，其特征在于，所述系统还包括：使用端，其用于提供当前类型的资源的总使用次数和使用失败次数；查询端，其用于响应于接收到的资源查询请求，从调度器汇集的已知的熔断资源列表中，判断与所述资源查询请求所匹配的资源是否处于熔断状态，在所述资源未处于熔断状态时，显示当前资源，用于交易使用。10.一种电子设备，其特征在于，包括处理器、通信接口、存储器和通信总线，其中，处理器、通信接口和存储器通过通信总线完成相互间的通信；存储器，用于存放计算机程序；处理器，用于执行存储器上所存放的程序时，实现权利要求1-7中任一项所述的资源数据处理的方法。11.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-7中任一项所述的资源数据处理的方法。

技术总结
本公开涉及一种资源数据处理的方法及系统、设备及存储介质，所述方法及系统应用于与交易相关联的接口，所述接口用于调取多个类型的资源，所述方法包括：对于每个类型的资源，收集当前类型的资源的总使用次数和使用失败次数；根据当前类型的资源的总使用次数和使用失败次数确定当前类型的资源的使用失败率；判断所述当前类型的资源的使用失败率是否达到预设的使用失败率阈值：当所述当前类型的资源的使用失败率达到使用失败率阈值时，对当前类型的资源进行熔断，能够在系统中某个业务数据、某个子场景甚至某种数据发生异常时进行熔断，保障系统整体的可用率和稳定性，确保用户的体验不受影响，也不会对其他数据的使用产生影响。响。响。


技术研发人员：黄增荣 陈月华 招家发
受保护的技术使用者：京东科技控股股份有限公司
技术研发日：2021.12.01
技术公布日：2022/3/8