一种残膜回收机防缠绕挑膜装置的制 一种秧草收获机用电力驱动行走机构

一种业务指标的处理方法及装置与流程

2021-10-23 00:29:00 来源:中国专利 TAG:装置 指标 数据库 业务 方法


1.本发明涉及数据库技术领域,具体涉及一种业务指标的处理方法及装置。


背景技术:

2.随着互联网的普及,很多应用(app)和网站承载的都是高并发的业务请求,在高峰期可能每秒并发量几千以上的业务请求。
3.互联网业务的一种常见场景为,根据业务需要的控制指标进行业务控制。例如,某项产品的投放总量控制、某个业务账户的额度等。随着互联网的普及,互联网的应用大都具有高并发的需求背景,不再适合直接将业务请求在业务数据库中进行数值计算操作。因此,亟需一种能够在上述业务场景下,减轻业务数据库的计算压力的解决方案。


技术实现要素:

4.本发明的至少一个实施例提供了一种业务指标的处理方法及装置,可以减轻业务数据库的计算压力,提高业务系统的可靠性和稳定性。
5.根据本发明的一个方面,至少一个实施例提供了一种业务指标的处理方法,包括:
6.在接收到业务请求时,根据所述业务请求对内存数据库中的指标使用量的第一增量值进行累加,得到所述指标使用量的第二增量值,并计算所述内存数据库中的业务指标的第一指标值和所述指标使用量的第二增量值的差值;
7.在所述差值大于或等于0时,返回所述业务请求通过所述内存数据库控制处理的响应消息;
8.在所述差值小于0时,返回所述业务请求未通过所述内存数据库控制处理的响应消息,并将所述指标使用量恢复为累加前的所述第一增量值。
9.根据本发明的至少一个实施例,在业务数据库的更新时机到达时,所述方法还包括:
10.生成所述内存数据库的指标增量快照,所述指标增量快照包括所述内存数据库中业务指标的指标使用量的第二增量值;
11.根据所述指标增量快照,更新所述业务数据库中的所述业务指标;
12.根据所述指标使用量的第二增量值和所述业务数据库中更新后的所述业务指标,更新所述内存数据库。
13.根据本发明的至少一个实施例,根据所述指标增量快照,更新所述业务数据库中的所述业务指标,包括:
14.利用所述业务数据库中的所述业务指标当前的第二指标值减去所述第二增量值,得到第三指标值;根据所述第三指标值,更新所述业务数据库中的所述业务指标。
15.根据本发明的至少一个实施例,根据所述指标使用量的第二增量值和所述业务数据库中更新后的所述业务指标,更新所述内存数据库,包括:
16.将所述内存数据库中所述业务指标的数值更新为所述第三指标值;以及,利用所
述内存数据库中所述指标使用量当前的第三增量值减去所述第二增量值,得到第四增量值;根据所述第四增量值,更新所述内存数据库中的所述指标使用量。
17.根据本发明的至少一个实施例,所述业务数据库和内存数据库中还分别维护有所述业务指标的版本号;所述指标增量快照中还包括有所述述内存数据库中业务指标的第一版本号;
18.根据所述指标增量快照,更新所述业务数据库中的所述业务指标,包括:
19.在所述业务数据库中业务指标的当前版本号与所述指标增量快照中的第一版本号相同的情况下,利用所述业务数据库中的所述业务指标当前的第二指标值减去所述第二增量值,得到第三指标值;根据所述第三指标值,更新所述业务数据库中的所述业务指标;,以及,更新所述业务数据库中的业务指标的当前版本号,得到所述业务数据库中更新后的所述业务指标的第二版本号;
20.在所述业务数据库中业务指标的当前版本号与所述指标增量快照中的第一版本号不同的情况下,产生数据库异常的告警信息。
21.根据本发明的至少一个实施例,根据所述指标使用量的第二增量值和所述业务数据库中更新后的所述业务指标,更新所述内存数据库,包括:
22.将所述内存数据库中所述业务指标的数值更新为所述第三指标值,将所述内存数据库中所述业务指标的版本号更新为所述第二版本号;以及,利用所述内存数据库中所述指标使用量当前的第三增量值减去所述第二增量值,得到第四增量值;根据所述第四增量值,更新所述内存数据库中的所述指标使用量。
23.根据本发明的至少一个实施例,所述业务数据库的更新时机包括:预设的更新周期;和/或,所述内存数据库中的所述指标使用量达到预设门限。
24.根据本发明的另一方面,还提供了一种业务指标的处理装置,包括:
25.业务请求处理模块,用于在接收到业务请求时,根据所述业务请求对内存数据库中的指标使用量的第一增量值进行累加,得到所述指标使用量的第二增量值,并计算所述内存数据库中的业务指标的第一指标值和所述指标使用量的第二增量值的差值;
26.第一反馈模块,用于在所述差值大于或等于0时,返回所述业务请求通过所述内存数据库控制处理的响应消息;
27.第二反馈模块,用于在所述差值小于0时,返回所述业务请求未通过所述内存数据库控制处理的响应消息,并将所述指标使用量恢复为累加前的所述第一增量值。
28.根据本发明的另一方面,还提供了一种业务指标的处理装置,包括:处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序,所述程序被所述处理器执行时实现如上所述的方法的步骤。
29.根据本发明的另一方面,至少一个实施例提供了一种计算机可读存储介质,所述计算机可读存储介质上存储有程序,所述程序被处理器执行时,实现如上所述的方法的步骤。
30.与现有技术相比,本发明实施例提供的业务指标的处理方法及装置,由内存数据库进行业务请求的控制处理,可以减轻业务数据库的计算压力,提高业务系统的可靠性和稳定性。并按照预设的更新时机对业务数据库进行更新,将原本由业务数据库进行的指标数值计算,改为在内存数据库中进行,保证了在高并发压力下业务指标数据处理的实时性,
同时避免了对业务数据库的频繁存取操作,可以大大降低业务数据库的处理压力,提高业务系统的稳定性和可靠性。
附图说明
31.通过阅读下文优选实施方式的详细描述,各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的,而并不认为是对本发明的限制。而且在整个附图中,用相同的参考符号表示相同的部件。在附图中:
32.图1为高并发的业务指标值处理的一种示例图;
33.图2为本发明实施例的业务指标的处理方法的一种流程图;
34.图3为本发明实施例的业务指标的处理方法的另一种流程图;
35.图4为本发明实施例的业务指标的处理方法的另一种流程图;
36.图5为本发明实施例的业务指标的处理方法的一种软件架构实现示例图;
37.图6为本发明实施例的业务指标的处理装置的一种结构示意图;
38.图7为本发明实施例的业务指标的处理装置的另一结构示意图。
具体实施方式
39.下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例,然而应当理解,可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反,提供这些实施例是为了能够更透彻地理解本发明,并且能够将本发明的范围完整的传达给本领域的技术人员。
40.本技术的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,以便这里描述的本技术的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,意图在于覆盖不排他的包含,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。说明书以及权利要求中“和/或”表示所连接对象的至少其中之一。
41.以下描述提供示例而并非限定权利要求中阐述的范围、适用性或者配置。可以对所讨论的要素的功能和布置作出改变而不会脱离本公开的精神和范围。各种示例可恰适地省略、替代、或添加各种规程或组件。例如,可以按不同于所描述的次序来执行所描述的方法,并且可以添加、省去、或组合各种步骤。另外,参照某些示例所描述的特征可在其他示例中被组合。
42.如背景技术所述的,高并发业务请求的场景下,不再适合直接将业务请求在业务数据库中进行数值计算操作,通常可以在诸如远程字典服务(redis,remote dictionary server)这类的内存数据库中进行指标数值的计算操作,再将指标的数值保存到业务数据库。
43.以redis为例进行说明,redis是一个开源的使用ansi c语言编写、支持网络、基于内存的高性能关键码值(key-value)数据库。redis提供了各种丰富的数据类型和访问应用程序接口(api,application programming interface),据此可以构建更高级的数据存取
服务。
44.如图1所示,对高并发的业务指标值处理的一种方案为:业务系统先载入业务数据指标到redis的内存数据库中,在业务流量请求到达业务系统时,业务系统在redis内存数据库中计算指标数值,业务系统根据指标数值计算结果进入不同的业务控制流程,同时业务系统还将指标数值计算结果保存到业务数据库(db)中。
45.本发明实施例提供了一种业务指标的处理方法,本发明实施例在业务系统中引入内存数据库,利用内存数据库对业务系统接收到的业务请求进行控制处理,可以减轻业务数据库的计算压力,提高业务系统的可靠性和稳定性。
46.本发明实施例中,内存数据库是独立于业务系统的业务数据库的数据库,主要用来进行业务指标的存取和计算。通常,相比于业务数据库,内存数据库能够更快捷的进行数据存取。具体的,本发明实施例的内存数据库可以为redis内存数据库或其他能够提供快速数据存取服务的数据库。
47.如图2所示,本发明实施例提供了一种业务指标的处理方法,包括:
48.步骤21,在接收到业务请求时,根据所述业务请求对内存数据库中的指标使用量的第一增量值进行累加,得到所述指标使用量的第二增量值,并计算所述内存数据库中的业务指标的第一指标值和所述指标使用量的第二增量值的差值。
49.这里,业务请求通常携带有对业务指标的请求量(即请求的数量),例如,某个购物请求携带有用户希望购买的特定商品的数量。本发明实施例在内存数据库维护有业务指标的指标使用量,所述指标使用量用于表示所述内存数据库中已使用的,且尚未计入业务数据库的业务指标的使用量。本文中,将所述指标使用量的数值称为增量值。所述内存数据库的指标使用量的初始增量值为0。内存数据库对接收到的业务请求进行处理,根据业务请求中携带的对业务指标的请求量,对其所维护的指标使用量进行累加更新。
50.步骤22,在所述差值大于或等于0时,返回所述业务请求通过所述内存数据库控制处理的响应消息。
51.步骤23,在所述差值小于0时,返回所述业务请求未通过所述内存数据库控制处理的响应消息,并将所述指标使用量恢复为累加前的所述第一增量值。
52.这里,在所述差值大于或等于0时,表示所述业务指标的当前数值能够满足所述业务请求对业务指标的请求量,例如,本次业务请求所购买的商品数量与所述内存数据库中的指标使用量(已售出商品数量)的和,没有超出所述内存数据库中的业务指标的当前数值(当前的可售商品数量),此时向业务系统返回所述业务请求通过控制处理的响应消息;而在所述差值小于0时,表示所述业务指标的当前数值不能满足所述业务请求的请求量,例如,本次业务请求所购买的商品数量与所述内存数据库中的指标使用量(已售出商品数量)的和,已超出所述内存数据库中的业务指标的当前数值(当前的可售商品数量),此时向业务系统返回所述业务请求未通过控制处理的响应消息,并将所述指标使用量恢复为所述第一增量值。
53.通过以上步骤,本发明实施例实现了利用内存数据库对业务请求进行控制处理,通过将业务请求的控制处理转移到内存数据库中进行,而不再在业务数据库中进行,从而减轻了业务数据库对高并发业务的计算压力。
54.根据本发明的一些实施例,本发明实施例还实现了在内存数据库和业务数据库之
间进行业务指标的同步处理。以图1所示的方案为例,引入了redis减轻了数据库的计算压力,但是redis每次计算得到的业务指标数值都需持久化到业务数据库,因此业务数据库的指标数值的写入次数没有减少。另外,如果多个业务都是使用同一个业务指标数值,各个业务请求在保存时都需获取业务数据库的行锁,在大并发压力下,业务数据库竞争行锁的开销会非常大。
55.为了保证了在高并发压力下业务指标数据处理的实时性,同时避免了对业务数据库的频繁存取操作,降低业务数据库的处理压力,本发明实施例提供的上述业务指标的处理方法,按照业务数据库的更新时机,在业务数据库和内存数据库之间进行数据同步处理。具体的,所述业务数据库的更新时机包括以下一种或多种:
56.1)预设的更新周期,例如,按照预设的更新周期,周期性进行更新。
57.2)所述内存数据库中的指标使用量达到预设门限,例如,指标使用量的当前增量值达到100,此时,将触发执行步骤21。
58.3)预设的更新周期,且内存数据库中的指标使用量不为0。
59.根据本发明的至少一个实施例,如图3所示,在业务数据库的更新时机到达时,所述方法还包括:
60.步骤31,生成所述内存数据库的指标增量快照,所述指标增量快照包括所述内存数据库中业务指标的指标使用量的第二增量值。
61.这里,在更新时机到达时,本发明实施例生成所述内存数据库的指标增量快照,所述指标增量快照包括:所述内存数据库中所述业务指标在该快照生成时刻时的增量值(为了便于描述,这里称之为第二增量值)。
62.步骤32,根据所述指标增量快照,更新所述业务数据库中的所述业务指标。
63.这里,更新所述业务数据库中的所述业务指标,具体包括:利用所述业务数据库中的所述业务指标当前的第二指标值减去所述第二增量值,得到第三指标值;根据所述第三指标值,更新所述业务数据库中的所述业务指标。
64.步骤33,根据所述指标使用量的第二增量值和所述业务数据库中更新后的所述业务指标,更新所述内存数据库。
65.本发明实施例需要对内存数据库中的业务指标进行更新。另外,由于业务数据库的指标使用量随着业务请求的到达而实时更新,步骤31的生成指标增量快照时刻与步骤33中的更新数据库的时刻之间,可能有一个或多个业务请求到达,导致内存数据库中的指标使用量发生了更新,因此,在步骤33中,所述指标使用量当前的第三增量值,可能与步骤31中生成指标增量快照时的第二增量值不同,所以本发明实施例需要对内存数据库中的指标使用量进行更新。
66.这里,更新所述内存数据库,具体包括:将所述内存数据库中所述业务指标的数值更新为所述第三指标值;以及,利用所述内存数据库中所述指标使用量当前的第三增量值减去所述第二增量值,得到第四增量值;根据所述第四增量值,更新所述内存数据库中的所述指标使用量。
67.通过以上步骤,本发明实施例实现了由内存数据库进行业务请求的控制处理,并按照预设的更新时机对业务数据库进行更新,将原本由业务数据库进行的指标数值计算,改为在内存数据库中进行,保证了在高并发压力下业务指标数据处理的实时性,同时避免
了对业务数据库的频繁存取操作,可以大大降低业务数据库的处理压力,提高业务系统的稳定性和可靠性。另外,本发明实施例使用数据库定义控制指标,可以非常灵活的新增控制指标,在不重启业务服务情况下动态调整指标数值。另外,本发明实施例可以支持应用的随时准热重启和程序版本升级,提高了业务响应速度。
68.根据本发明的另一些实施例,除了在业务数据库和内存数据库中各自维护同一个业务指标外,本发明实施例还可以在业务数据库和内存数据库中各自维护所述业务指标的版本号,业务数据库和内存数据库中业务指标的版本号可能并不相同,但可以通过更新内存数据库的方式,同步两者的业务指标的版本号。
69.根据本发明的至少一个实施例,所述业务数据库和内存数据库中还分别维护有所述业务指标的版本号,在进行数据库之间的同步时:
70.上述步骤31中,在业务数据库的更新时机到达时,生成所述内存数据库的指标增量快照时,在所述指标增量快照中还包括有所述内存数据库中所述业务指标在该快照生成时刻时的版本号(为了便于描述,这里称之为第一版本号)。
71.上述步骤32中,根据所述指标增量快照,更新所述业务数据库中的所述业务指标,具体可以包括:1)在所述业务数据库中业务指标的当前版本号与所述指标增量快照中的第一版本号相同的情况下,利用所述业务数据库中的所述业务指标当前的第二指标值减去所述第二增量值,得到第三指标值;根据所述第三指标值,更新所述业务数据库中的所述业务指标;,以及,更新所述业务数据库中的业务指标的当前版本号,得到所述业务数据库中更新后的所述业务指标的第二版本号;2)在所述业务数据库中业务指标的当前版本号与所述指标增量快照中的第一版本号不同的情况下,产生数据库异常的告警信息。
72.这里,本发明实施例可以按照预设的版本号更新方式,更新所述业务指标的版本号,例如,将业务数据库中业务指标的当前版本号加1,得到更新后的版本号(即所述第二版本号)。如果所述业务数据库中业务指标的版本号与所述指标增量快照中的第一版本号不同,则说明出现了异常情况,此时可以按照异常情况进行处理,例如发出数据库运行异常的告警信息等。
73.上述步骤33中,根据所述指标使用量的第二增量值和所述业务数据库中更新后的所述业务指标,更新所述内存数据库,具体可以包括:将所述内存数据库中所述业务指标的数值更新为所述第三指标值,将所述内存数据库中所述业务指标的版本号更新为所述第二版本号;以及,利用所述内存数据库中所述指标使用量当前的第三增量值减去所述第二增量值,得到第四增量值;根据所述第四增量值,更新所述内存数据库中的所述指标使用量。
74.另外,在上述步骤21之前,本发明实施例还可以通过以下步骤,对内存数据库中的业务指标进行初始化,具体的,在业务系统启动时,可以从业务系统的业务数据库中加载所述业务指标的版本号和指标值到内存数据库中,从而对所述内存数据库中的业务指标进行初始化。这样,本发明实施例通过在业务系统启动时从业务数据库中加载应用的各种业务控制指标,并将指标数值、版本号初始化进内存数据库,确保了指标数值在业务系统重启后的连续性控制。
75.以上实施例在内存数据库的数据结构包含有业务指标的版本号,可以避免更新内存数据库时版本不一致所导致的数据库异常问题。
76.为了便于理解以上参数以及理解下文的方法,下面通过提供一个具体示例。以某
购物网站出售的某种商品的应用场景为例,通过一个商品购买的示例,对本发明实施例的以上方法进行说明。
77.以业务数据库中的某个商品的可售数量作为业务指标,假设:
78.在初始的第一时刻t1:业务数据库中的该商品的可售数量的版本号为v1,可售数量的数值为10000;内存数据库中初始化该商品的可售数量的版本号为v1,数值为10000;所述业务指标(可售数量)的指标使用量的初始值为0。
79.从第一时刻t1开始,内存数据库对接收到的业务请求进行业务控制处理,每通过一个业务请求,对该业务请求对业务指标的使用量(如购买2件该商品)进行累计,更新所述指标使用量的数值,假设在第二时刻t2时,所述指标使用量的数值为1000。
80.假设在第二时刻t2,业务数据库的更新时机到达,此时生成内存数据库中的指标增量快照,具体包括内存数据库中所述可售数量这一指标的版本号v1以及指标使用量的当前值1000。
81.然后,根据上述指标增量快照,对业务数据库进行更新。具体的,指标增量快照中的版本号和内存数据库中的版本号相同,表明所述指标增量快照是在业务数据库的可售数量基础上的增量数据,因此可以利用该指标增量快照对业务数据库进行更新。由于指标增量快照中的指标使用量为1000,因此,需要将业务数据库中的可售数量更新为10000-1000=9000,同时更新可售数量的版本号,例如,从v1更新为v2。这样,获得了所述业务数据库中的可售数量这一指标的新版本号v2和更新后的可售数量9000。
82.然后,根据所述可售数量的新版本号v2、可售数量的数值9000、以及所述指标使用量的数值1000,对内存数据库进行更新,假设更新发生在第三时刻t3。而从第二时刻t2到第三时刻t3之间,内存数据库仍然进行对接收到的业务请求进行处理,并更新内存数据库中的指标使用量,假设在第三时刻t3,指标使用量已由之前第二时刻t2的1000,增加到1200,即,在第三时刻内存数据库中的指标使用量的数值为1200。那么在对内存数据库进行更新时,需要根据所述可售数量的新版本号v2、可售数量的数值9000,更新内存数据库中的可售数量的版本号和数值,即将内存数据库中的可售数量的版本号和数值分别更新为v2和9000。另外,由于所述指标增量快照中的指标使用量的数值1000已更新到业务数据库中的可售数量中,因此,需要根据所述指标增量快照中的指标使用量,进一步更新内存数据库中的指标使用量,具体的,利用内存数据库中的指标使用量的数值1200减去指标增量快照中的指标使用量的数值1000,从而得到内存数据库中更新后的指标使用量的数值为200。
83.通过重复执行以上步骤,本发明实施例可以在业务数据库的更新时机到达时对业务数据库和内存数据库进行更新,保证指标间的一致性和有效性。
84.图4给出了本发明实施例的业务指标的处理流程的一个示例。其中,可以在redis中初始化两个脚本,分别为指标计算脚本和指标更新脚本。这里,脚本具体可以采用lua脚本。lua脚本是一种轻量小巧的脚本语言,用标准c语言编写并开放源代码,主要用于嵌入到各种应用程序中,可以为应用程序提供灵活的扩展和自定义程序脚本功能。
85.在业务系统启动时,通过指标初始化(步骤41),从业务数据库中加载业务指标的当前指标值和当前版本号,并以hash格式初始化到redis内存数据库中。
86.然后,在业务请求到达(步骤42)时,在内存数据库中进行业务控制处理(步骤43),具体的,可以将所述业务请求对业务指标的使用量作为参数,调用上述的指标计算脚本,该
指标计算脚本先将业务请求的使用量累加到指标使用量中,再计算“业务指标的指标值”减去“指标使用量”后的剩余值。如果剩余值大于或等于零,则向业务系统返回true,表示控制处理已通过;否则将“指标使用量”恢复为脚本累加前的数值,并返回false,表示控制处理未通过,业务系统按指标计算脚本的返回布尔值进行控制。
87.在定时更新时机到达时,生成内存数据库中的指标增量快照,根据该指标增量快照对业务数据库进行业务指标的版本号和指标值的更新(步骤44),并在业务数据库更新成功后,将业务数据库中更新后的业务指标的版本号和指标值以及上述指标增量快照中的指标使用量值作为参数,调用指标更新脚本,对内存数据库中的业务指标和指标使用量进行更新。
88.图5进一步提供了本发明实施例上述业务指标的处理方法在实际应用时的软件架构的一个示例,其中,业务系统包括有业务控制功能模块和定时保存功能模块,redis包括有指标数据模块和执行脚本模块,另外上述软件架构中还包括有用于进行指标配置的指标配置模块和对脚本进行配置的脚本配置模块。具体的,
89.1)指标配置模块,使用数据库表定义控制指标,主要列名有业务指标的编码、名称、业务指标的指标值、版本号等。指标表主要字段定义如下:
[0090][0091][0092]
2)脚本配置模块:在业务系统启动时,使用redis接口载入指标计算脚本和指标更新脚本,这两个脚本具体可以是lua脚本。
[0093]
其中,指标计算脚本的处理逻辑可以参照上述步骤21或步骤31的说明,根据业务请求对业务指标的使用量,对所述内存数据库中的指标使用量的增量值进行累加,更新得到所述指标使用量的增量值,并计算所述内存数据库中的业务指标的指标值和更新后所述增量值的差值,根据所述差值是否大于或等于0,返回业务请求是否通过业务指标控制的布尔值。
[0094]
指标更新脚本的逻辑可以参照上述步骤23或步骤33的说明,即,在业务数据库更新成功后,将内存数据库中业务指标的版本号和指标值分别更新为所述业务数据库中的版本号和指标值;以及,将所述内存数据库中所述指标使用量的增量值更新为:所述内存数据库中所述指标使用量的当前值与所述指标增量快照中的增量值的差值。
[0095]
基于软件架构,本示例在业务系统启动时,读取数据库配置的指标,以hash结构写入redis,上述脚本内容也同时载入redis,完成指标的相关初始化。在业务系统收到业务请
求时,调用指标计算脚本,同时传入业务指标的编码、本次业务请求对业务指标的使用值,得到布尔结果,true表示本次业务请求所请求的业务指标的使用值通过了指定指标的控制,反之false表示本次请求不通过。另外,通过定时使用redis的hscan指令,扫描指标使用量不等于零时,生成指标增量快照保存到内存数据库中的指标表。以及,在内存数据库保存成功后,立即读取指标增量快照中的增量值以及更新后的“指标新值、指标新版本号”,调用指标更新脚本更新redis。
[0096]
以上介绍了本发明实施例的各种方法。下面将进一步提供实施上述方法的装置。
[0097]
请参照图6,本发明实施例提供了一种业务指标的处理装置60,包括:
[0098]
业务请求处理模块61,用于在接收到业务请求时,根据所述业务请求对内存数据库中的指标使用量的第一增量值进行累加,得到所述指标使用量的第二增量值,并计算所述内存数据库中的业务指标的第一指标值和所述指标使用量的第二增量值的差值;
[0099]
第一反馈模块62,用于在所述差值大于或等于0时,返回所述业务请求通过所述内存数据库控制处理的响应消息;
[0100]
第二反馈模块63,用于在所述差值小于0时,返回所述业务请求未通过所述内存数据库控制处理的响应消息,并将所述指标使用量恢复为累加前的所述第一增量值。
[0101]
根据本发明的一些实施例,所述业务指标的处理装置还包括以下模块(图中未示出):
[0102]
快照生成模块,用于在业务数据库的更新时机到达时,生成所述内存数据库的指标增量快照,所述指标增量快照包括所述内存数据库中业务指标的指标使用量的第二增量值;
[0103]
业务数据库更新模块,用于根据所述指标增量快照,更新所述业务数据库中的所述业务指标;
[0104]
内存数据库更新模块,用于根据所述指标使用量的第二增量值和所述业务数据库中更新后的所述业务指标,更新所述内存数据库。
[0105]
根据本发明的一些实施例,所述业务数据库更新模块,还用于利用所述业务数据库中的所述业务指标当前的第二指标值减去所述第二增量值,得到第三指标值;根据所述第三指标值,更新所述业务数据库中的所述业务指标。所述内存数据库更新模块,还用于将所述内存数据库中所述业务指标的数值更新为所述第三指标值;以及,利用所述内存数据库中所述指标使用量当前的第三增量值减去所述第二增量值,得到第四增量值;根据所述第四增量值,更新所述内存数据库中的所述指标使用量。
[0106]
根据本发明的另一些实施例,所述业务数据库和内存数据库中还分别维护有所述业务指标的版本号;所述指标增量快照中还包括有所述述内存数据库中业务指标的第一版本号。所述业务数据库更新模块,还用于在所述业务数据库中业务指标的当前版本号与所述指标增量快照中的第一版本号相同的情况下,利用所述业务数据库中的所述业务指标当前的第二指标值减去所述第二增量值,得到第三指标值;根据所述第三指标值,更新所述业务数据库中的所述业务指标;以及,更新所述业务数据库中的业务指标的当前版本号,得到所述业务数据库中更新后的所述业务指标的第二版本号;在所述业务数据库中业务指标的当前版本号与所述指标增量快照中的第一版本号不同的情况下,产生数据库异常的告警信息。所述内存数据库更新模块,还用于将所述内存数据库中所述业务指标的数值更新为所
述第三指标值,将所述内存数据库中所述业务指标的版本号更新为所述第二版本号;以及,利用所述内存数据库中所述指标使用量当前的第三增量值减去所述第二增量值,得到第四增量值;根据所述第四增量值,更新所述内存数据库中的所述指标使用量。
[0107]
可选的,所述业务数据库的更新时机包括:预设的更新周期;和/或,所述内存数据库中的指标使用量达到预设门限。
[0108]
可选的,所述内存数据库为远程字典服务redis数据库。
[0109]
请参照图7,本发明实施例提供的业务指标的处理装置的另一种结构示意图,该处理装置700包括:处理器701、收发机702、存储器703、用户接口704和总线接口。
[0110]
在本发明实施例中,预测装置700还包括:存储在存储器上703并可在处理器701上运行的程序。
[0111]
所述处理器701执行所述程序时实现以下步骤:
[0112]
在接收到业务请求时,根据所述业务请求对内存数据库中的指标使用量的第一增量值进行累加,得到所述指标使用量的第二增量值,并计算所述内存数据库中的业务指标的第一指标值和所述指标使用量的第二增量值的差值;
[0113]
在所述差值大于或等于0时,返回所述业务请求通过所述内存数据库控制处理的响应消息;
[0114]
在所述差值小于0时,返回所述业务请求未通过所述内存数据库控制处理的响应消息,并将所述指标使用量恢复为累加前的所述第一增量值。
[0115]
可理解的,本发明实施例中,所述计算机程序被处理器701执行时可实现上述图1所示的业务指标的处理方法实施例的各个过程,且能达到相同的技术效果,为避免重复,这里不再赘述。
[0116]
在图7中,总线架构可以包括任意数量的互联的总线和桥,具体由处理器701代表的一个或多个处理器和存储器703代表的存储器的各种电路链接在一起。总线架构还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起,这些都是本领域所公知的,因此,本文不再对其进行进一步描述。总线接口提供接口。收发机702可以是多个元件,即包括发送机和接收机,提供用于在传输介质上与各种其他装置通信的单元。针对不同的用户设备,用户接口704还可以是能够外接内接需要设备的接口,连接的设备包括但不限于小键盘、显示器、扬声器、麦克风、操纵杆等。
[0117]
处理器701负责管理总线架构和通常的处理,存储器703可以存储处理器701在执行操作时所使用的数据。
[0118]
在本发明的一些实施例中,还提供了一种计算机可读存储介质,其上存储有程序,该程序被处理器执行时实现以下步骤:
[0119]
在接收到业务请求时,根据所述业务请求对内存数据库中的指标使用量的第一增量值进行累加,得到所述指标使用量的第二增量值,并计算所述内存数据库中的业务指标的第一指标值和所述指标使用量的第二增量值的差值;
[0120]
在所述差值大于或等于0时,返回所述业务请求通过所述内存数据库控制处理的响应消息;
[0121]
在所述差值小于0时,返回所述业务请求未通过所述内存数据库控制处理的响应消息,并将所述指标使用量恢复为累加前的所述第一增量值。
[0122]
该程序被处理器执行时能实现上述业务指标的处理方法中的所有实现方式,且能达到相同的技术效果,为避免重复,此处不再赘述。
[0123]
本领域普通技术人员可以意识到,结合本文中所公开的实施例描述的各示例的单元及算法步骤,能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行,取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能,但是这种实现不应认为超出本发明的范围。
[0124]
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统、装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
[0125]
在本技术所提供的实施例中,应该理解到,所揭露的装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
[0126]
所述作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本发明实施例方案的目的。
[0127]
另外,在本发明各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独物理存在,也可以两个或两个以上单元集成在一个单元中。
[0128]
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本发明各个实施例所述的方法的全部或部分步骤。而前述的存储介质包括:u盘、移动硬盘、rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
[0129]
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应以权利要求的保护范围为准。
再多了解一些

本文用于企业家、创业者技术爱好者查询,结果仅供参考。

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表

相关文献

  • 日榜
  • 周榜
  • 月榜