陈畅亮搞的专利在Windows上利用加解密DLL模块对数据库连接字符串进行加解密
这种专利权人是公司,个人是发明人,专利年费是申请人先垫付,然后公司报销了,这个专利本身就不属于员工的
这个是公司是专利权人, 使用权是公司 , 如果想要维持权利的话 ,需要缴纳年费 ,专利发明现在一个市面上价格都是3w+的 ,缴纳年费来维持
不是属于员工的 员工只是作为发明人,发明专利,实质审查需要5个月左右的时间, 授权的时间在1.5-2年左右,甚至更长(具体下证时间均以国家专利局通知为准)
f
f
https://www.patentguru.com/cn/inventor/%E9%99%88%E7%95%85%E4%BA%AE
https://www.patentguru.com/cn/CN111488331B
2021年10月去TIDB上班
申请号:
CN202010267283.1
申请日期:
2020-04-08 !!!!!还在虎牙
公开(公告)号:
CN111488331B
公开(公告)日:
2024-03-01
申请(专利权)人:
广州虎牙科技有限公司
发明(设计)人:
陈畅亮
刘亚丹
代理人:
刘延喜
4.6分
详情
代理机构:
北京市立方律师事务所
4.7分
详情
网址: http://www.lifanglaw.com
榜单: 全国杰出代理机构(授权率前10%)
电话: 010-64096099
典型客户: 三星电子株式会社,腾讯科技(深圳)有限公司
代理人数: 48 查看次数 :326
申请(专利权)人:
广州虎牙科技有限公司
发明(设计)人:
陈畅亮
刘亚丹
代理人:
刘延喜
4.6分
详情
代理机构:
北京市立方律师事务所
4.7分
详情
网址: http://www.lifanglaw.com
榜单: 全国杰出代理机构(授权率前10%)
电话: 010-64096099
典型客户: 三星电子株式会社,腾讯科技(深圳)有限公司
代理人数: 48 查看次数 :326
IPC分类号:
G06F 16/21; G06F 16/25;
G06F 21/60; G06F 21/62
外部链接:
Espacenet ; Global Dossier ;
摘要
本申请涉及数据库安全技术领域,尤其涉及一种数据库连接方法、装置和计算机设备,包括:根据预存的唯一的key值调用本地的DLL文件;其中,所述key值是由数据库预先生成并分配的;通过所述DLL文件获取与所述key值对应的数据库信息,并利用所述数据库信息对所述数据库进行连接测试,其中,所述DLL文件测试成功后对获取到的加密后的数据库信息进行解密得到解密字符串;获取所述DLL文件返回的所述解密字符串,根据所述解密字符串连接所述数据库;本方案中数据库的IP/域名、账号、密码不再是明文的配置方式,而是调用DLL文件并通过加解密算法得到,这样有利于加强数据库的安全性,同时,还解耦了因泄漏key值而导致大面积的数据库账号需要修改的现象。
权利要求
1.一种数据库连接方法,其特征在于,包括如下步骤:
根据预存的唯一的key值调用本地的DLL文件;其中,所述key值是由数据库预先生成并分配的;
通过所述DLL文件获取与所述key值对应的加密后的数据库信息,并通过所述DLL文件利用所述加密后的数据库信息对所述数据库进行连接测试,其中,所述DLL文件测试成功后对获取到的加密后的数据库信息进行解密得到解密字符串;
获取所述DLL文件返回的所述解密字符串,根据所述解密字符串连接所述数据库。
2.根据权利要求1所述的数据库连接方法,其特征在于,所述key值是由加解密终端根据所述数据库发送的明文的数据库信息进行加密生成。
3.根据权利要求1所述的数据库连接方法,其特征在于,还包括:
判断所述key值是否泄露,若是,则通知所述数据库,并获取由所述数据库重新生成并分配的key值;其中,所述数据库将泄漏的key值加入黑名单。
4.根据权利要求1所述的数据库连接方法,其特征在于,通过所述DLL文件获取与所述key值对应的数据库信息的步骤,包括:
通过所述DLL文件获取本地缓存中与所述key值对应的加密后的数据库信息;若获取失败,则在本地的磁盘缓存文件中获取所述数据库信息。
5.根据权利要求4所述的数据库连接方法,其特征在于,还包括:
若在所述磁盘缓存文件中获取所述数据库信息失败,则通过Web Service接口向RedisCluster缓存集群请求加密后的数据库信息,并将获取的所述数据库信息写入/更新到所述本地缓存以及所述磁盘缓存文件中。
6.根据权利要求5所述的数据库连接方法,其特征在于,所述通过Web Service接口向Redis Cluster缓存集群请求加密后的数据库信息的步骤,包括:
通过所述DLL文件调用Web Service接口,其中,所述DLL文件根据所述Web Service接口读取Redis Cluste缓存集群中存储的与所述key值对应的加密后的数据库信息,并通过所述Web Service接口进行二次加密。
7.根据权利要求5所述的数据库连接方法,其特征在于,所述通过Web Service接口向Redis Cluster缓存集群请求加密后的数据库信息的步骤之后,还包括:
通过所述DLL文件对所述Web Service接口进行线程监听,用于获取更新后的加密后的数据库信息;
并将获取到的所述数据库信息写入/更新到所述本地缓存以及所述磁盘缓存文件中。
8.根据权利要求4所述的数据库连接方法,其特征在于,所述通过所述DLL文件获取本地缓存中与所述key值对应的加密后的数据库信息;若获取失败,则在本地的磁盘缓存文件中获取所述数据库信息的步骤之后,还包括:
利用所述数据库信息对所述数据库进行连接测试;
若所述测试失败,则通过所述DLL文件调用Web Service接口请求加密后的数据库信息,并利用所述数据库信息重新对所述数据库进行连接测试。
9.一种数据库连接装置,其特征在于,包括:
调用模块,用于根据预存的唯一的key值调用本地的DLL文件;其中,所述key值是由数据库预先生成并分配的;
信息获取模块,用于通过所述DLL文件获取与所述key值对应的加密后的数据库信息,并通过所述DLL文件利用所述加密后的数据库信息对所述数据库进行连接测试,其中,所述DLL文件测试成功后对获取到的加密后的数据库信息进行解密得到解密字符串;
连接模块,用于获取所述DLL文件返回的所述解密字符串,根据所述解密字符串连接所述数据库。
10.一种计算机设备,其特征在于:所述计算机设备中存储有计算机可读指令,所述计算机可读指令被一个或多个处理器执行时,使得一个或多个处理器执行如权利要求1至8中任一项所述的数据库连接方法的步骤。
说明书
技术领域
本申请涉及数据库安全技术领域,尤其涉及一种数据库连接方法、装置和计算机设备。
背景技术
数据库是按照数据结构来组织、存储和管理数据的仓库,是一个长期存储在计算机内的、有组织的、有共享的、统一管理的数据集合。因此,为了数据库中业务数据的安全,防止信息泄露,不仅需要对数据库进行定期维护,还需要对访问数据库的应用程序进行身份验证。
目前,数据库的身份验证方法为应用程序调用存储在本地配置文件中的数据库账户及密码,依据该账户及密码向数据库进行访问身份验证,并提取相关信息。但是,由于本地配置文件使用明文进行配置,使得数据库的账户及密码容易被非法获取,从而降低数据库的安全性。
发明内容
本申请的目的旨在至少能解决上述的技术缺陷之一,特别是现有技术中本地配置文件使用明文进行配置,使得数据库的账户及密码容易被非法获取,从而降低数据库的安全性的技术缺陷。
本申请提供一种数据库连接方法,包括如下步骤:
根据预存的唯一的key值调用本地的DLL文件;其中,所述key值是由数据库预先生成并分配的;
通过所述DLL文件获取与所述key值对应的数据库信息,并利用所述数据库信息对所述数据库进行连接测试,其中,所述DLL文件测试成功后对获取到的加密后的数据库信息进行解密得到解密字符串;
获取所述DLL文件返回的所述解密字符串,根据所述解密字符串连接所述数据库。
在一个实施例中,所述key值是由加解密终端根据所述数据库发送的明文的数据库信息进行加密生成。
在一个实施例中,所述数据库连接方法,还包括:
判断所述key值是否泄露,若是,则通知所述数据库,并获取由所述数据库重新生成并分配的key值;其中,所述数据库将所述key值加入黑名单。
在一个实施例中,通过所述DLL文件获取与所述key值对应的数据库信息的步骤,包括:
通过所述DLL文件获取本地缓存中与所述key值对应的加密后的数据库信息;若获取失败,则在本地的磁盘缓存文件中获取所述数据库信息。
在一个实施例中,所述数据库连接方法,还包括:
若在所述磁盘缓存文件中获取所述数据库信息失败,则通过Web Service接口向Redis Cluster缓存集群请求加密后的数据库信息,并将获取的所述数据库信息写入/更新到所述本地缓存以及所述磁盘缓存文件中。
在一个实施例中,所述通过Web Service接口向Redis Cluster缓存集群请求加密后的数据库信息的步骤,包括:
通过所述DLL文件调用Web Service接口,其中,所述DLL文件根据所述WebService接口读取Redis Cluste缓存集群中存储的与所述key值对应的加密后的数据库信息,并通过所述Web Service接口进行二次加密。
在一个实施例中,所述通过Web Service接口向Redis Cluster缓存集群请求加密后的数据库信息的步骤之后,还包括:
通过所述DLL文件对所述Web Service接口进行线程监听,用于获取更新后的加密后的数据库信息;
并将获取到的所述数据库信息写入/更新到所述本地缓存以及所述磁盘缓存文件中。
在一个实施例中,所述通过所述DLL文件获取本地缓存中与所述key值对应的加密后的数据库信息;若获取失败,则在本地的磁盘缓存文件中获取所述数据库信息的步骤之后,还包括:
利用所述数据库信息对所述数据库进行连接测试;
若所述测试失败,则通过所述DLL文件调用Web Service接口请求加密后的数据库信息,并利用所述数据库信息重新对所述数据库进行连接测试。
本申请还提供了一种数据库连接装置,包括:
调用模块,用于根据预存的唯一的key值调用本地的DLL文件;其中,所述key值是由数据库预先生成并分配的;
信息获取模块,用于通过所述DLL文件获取与所述key值对应的数据库信息,并利用所述数据库信息对所述数据库进行连接测试,其中,所述DLL文件测试成功后对获取到的加密后的数据库信息进行解密得到解密字符串;
连接模块,用于获取所述DLL文件返回的所述解密字符串,根据所述解密字符串连接所述数据库。
本申请还提供了一种计算机设备,所述计算机设备中存储有计算机可读指令,所述计算机可读指令被一个或多个处理器执行时,使得一个或多个处理器执行如上述实施例中任一项所述的数据库连接方法的步骤。
上述数据库连接方法、装置和计算机设备,根据预存的唯一的key值调用本地的DLL文件;其中,所述key值是由数据库预先生成并分配的;通过所述DLL文件获取与所述key值对应的数据库信息,并利用所述数据库信息对所述数据库进行连接测试,其中,所述DLL文件测试成功后对获取到的加密后的数据库信息进行解密得到解密字符串;获取所述DLL文件返回的所述解密字符串,根据所述解密字符串连接所述数据库。
本方案中,DLL文件接收上层应用程序的获取数据库请求,通过应用程序传入的唯一的key值,得到一段与数据库IP/域名、帐号、密码对应的加密后的数据库信息,再通过解密算法解释出明文的数据库IP/域名、帐号、密码,通过该解密字符串对数据库进行连接测试,并在测试成功后将解密字符串发送给应用程序,以便应用程序进行安全连接;在此过程中,数据库的IP/域名、账号、密码也不再是明文方式配置在配置文件中,而是调用DLL文件并通过加解密算法得到,这样有利于加强访问数据库的安全性,另外,当key值遭遇泄露时,只需对数据库中已保存的key值作相应的处理即可,解耦了因泄漏key值而导致大面积的数据库账号需要修改的现象。
本申请附加的方面和优点将在下面的描述中部分给出,这些将从下面的描述中变得明显,或通过本申请的实践了解到。
附图说明
本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解,其中:
图1是本申请实施例的数据库连接方法的应用环境示意图;
图2为一个实施例的数据库连接方法示意图;
图3为一个实施例的通过DLL文件获取数据库信息的方法示意图;
图4为一个实施例的通过DLL文件对数据库进行连接测试的方法示意图;
图5是一个实施例的数据库连接装置结构示意图;
图6为一个实施例的计算机设备的内部结构示意图。
具体实施方式
下面详细描述本申请的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,仅用于解释本申请,而不能解释为对本申请的限制。
本技术领域技术人员可以理解,除非特意声明,这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是,本申请的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件,但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组合。
本技术领域技术人员可以理解,除非另外定义,这里使用的所有术语(包括技术术语和科学术语),具有与本申请所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是,诸如通用字典中定义的那些术语,应该被理解为具有与现有技术的上下文中的意义一致的意义,并且除非像本申请实施例中一样被特定定义,否则不会用理想化或过于正式的含义来解释。
数据库是按照数据结构来组织、存储和管理数据的仓库,是一个长期存储在计算机内的、有组织的、有共享的、统一管理的数据集合。因此,为了数据库中业务数据的安全,防止信息泄露,不仅需要对数据库进行定期维护,还需要对访问数据库的应用程序进行身份验证。
目前,数据库的身份验证方法为应用程序调用存储在本地配置文件中的数据库账户及密码,依据该账户及密码向数据库进行访问身份验证,并提取相关信息。但是,由于本地配置文件使用明文进行配置,使得数据库的账户及密码容易被非法获取,从而降低数据库的安全性。
因此,本申请提出下述实施方式,以解决本地配置文件使用明文进行配置,使得数据库的账户及密码容易被非法获取,从而降低数据库的安全性的技术缺陷。
参考图1所示,图1是本申请实施例的数据库连接方法的应用环境示意图;本实施例中,本申请的技术方案可以以计算机的操作系统连接服务器的数据库为例实现,如图1中,操作系统中的某一应用程序需要连接数据库时,调用DLL(Dynamic
Link
Library,动态链接库)文件以获取与该数据库相关的信息,以便该应用程序通过服务器实现相关功能;在本申请实施例中,操作系统中的某一应用程序在连接数据库之前,首先通过DLL文件获取该数据库的数据库信息,然后应用程序根据该数据库信息与服务器之间进行数据传输,以便服务器根据该数据库信息访问数据库,实现应用程序与数据库之间的数据连接。
在一个实施例中,如图2所示,图2为一个实施例的数据库连接方法示意图,本实施例中提供了一种数据库连接方法,可以包括如下步骤:
S110:根据预存的唯一的key值调用本地的DLL文件;其中,所述key值是由数据库预先生成并分配的。
通常,应用程序中会配置有连接数据库的域名、端口、账号、密码等的配置文件,该配置文件中使用明文的数据库信息进行配置,即使服务器处在内网机制,仍然会对数据库的安全带来一定隐患,若黑客攻破内网,将会导致数据库中的数据存在被盗取的风险。
因此,本申请中,为了克服现有技术中因应用程序中的配置文件使用明文进行配置,使得数据库存在数据丢失、泄露的风险,优先采取了利用DLL文件并基于加解密算法的方式提高数据库的安全。
可以理解的是,操作系统中的应用程序,如Windows中,许多应用程序并不是一个完整的可执行文件,它们被分割成一些相对独立的动态链接库,即DLL文件,放置于操作系统中。当我们执行某一个程序时,相应的DLL文件就会被调用。
需要说明的是,一个应用程序可使用多个DLL文件,一个DLL文件也可能被不同的应用程序使用,这样的DLL文件被称为共享DLL文件。
因而,在本步骤中,当上层的应用程序需要获取数据库信息时,可向DLL文件发送该应用程序中保存的key值,以便调用DLL文件获取与该key值对应的数据库信息。
可以理解的是,这里的key值指的是在数据库中预先生成的、分配给对应的应用程序的唯一身份标识,应用程序可利用该身份标识并通过DLL文件获取与该身份标识对应的数据库的域名、端口、账号、密码等。
S120:通过所述DLL文件获取与所述key值对应的数据库信息,并利用所述数据库信息对所述数据库进行连接测试,其中,所述DLL文件测试成功后对获取到的加密后的数据库信息进行解密得到解密字符串。
本步骤中,通过步骤S110根据预存的唯一的key值调用本地的DLL文件后,DLL文件可根据该key值查找对应的数据库信息,并尝试与数据库建立连接。
具体地,DLL文件可在本地缓存中或者本地的磁盘缓存文件中查找已缓存的数据库信息,当然,为了数据库的安全性,这里缓存的数据库信息为加密后的数据库信息,当查找到对应的加密后的数据库信息后,可利用预先配置的解密算法进行解密,即可得到解密字符串。
当得到解密字符串后,可利用该解密字符串尝试与数据库之间建立通信连接,若该测试连接成功,则表示获取到的数据库信息无误,若测试不成功,则可以继续尝试其他途径获取数据库信息,直到成功为止。
可以理解的是,这里的解密字符串指的是经解密算法解密后的数据库信息,该数据库信息包括但不限定于数据库的域名、端口、账号、密码等。
S130:获取所述DLL文件返回的所述解密字符串,根据所述解密字符串连接所述数据库。
本步骤中,当通过步骤S120得到解密字符串后,DLL文件首先利用该解密字符串对数据库进行连接测试,若测试成功,则表示获取到的解密字符串是正确的,若测试不成功,则说明本地缓存中或磁盘缓存文件中缓存的数据库信息存在错误,此时,需要通过其他方式重新获取数据库信息,并利用重新获取的数据库信息再次对数据库进行连接测试。
并且,当测试成功后,需要将解密字符串返回至应用程序中,以便应用程序根据DLL测试成功后的解密字符串进行数据库连接。这样,能够在一定程度上减少使用明文的数据库信息进行数据库连接时导致数据库信息泄露的风险,提高了数据库的安全。
上述数据库连接方法,根据预存的唯一的key值调用本地的DLL文件;其中,所述key值是由数据库预先生成并分配的;通过所述DLL文件获取与所述key值对应的数据库信息,并利用所述数据库信息对所述数据库进行连接测试,其中,所述DLL文件测试成功后对获取到的加密后的数据库信息进行解密得到解密字符串;获取所述DLL文件返回的所述解密字符串,根据所述解密字符串连接所述数据库。
本方案中,DLL文件接收上层应用程序的获取数据库请求,通过应用程序传入的唯一的key值,得到一段与数据库IP/域名、帐号、密码对应的加密后的数据库信息,再通过解密算法解释出明文的数据库IP/域名、帐号、密码,通过该解密字符串对数据库进行连接测试,并在测试成功后将解密字符串发送给应用程序,以便应用程序进行安全连接;在此过程中,数据库的IP/域名、账号、密码也不再是明文方式配置在配置文件中,而是调用DLL文件并通过加解密算法得到,这样有利于加强访问数据库的安全性,另外,当key值遭遇泄露时,只需对数据库中已保存的key值作相应的处理即可,解耦了因泄漏key值而导致大面积的数据库账号需要修改的现象。
在一个实施例中,所述key值是由加解密终端根据所述数据库发送的明文的数据库信息进行加密生成。具体地,key值的生成步骤可以包括:
S201:将明文的数据库信息发送至加解密终端,并通过所述加解密终端进行加密;
S202:将加密后的数据库信息写入到所述数据库以及Redis Cluster缓存集群中,以使所述数据库生成与所述加密后的数据库信息对应的key值,并更新所述Redis Cluster缓存集群中已存储的加密后的数据库信息。
本实施例中,数据库向应用程序发送key值之前,需要将明文的数据库信息发送至加解密终端,并通过加解密终端进行加密,数据库获取加密后的数据库信息后对其进行保存。
其中,加解密终端主要是接收明文的数据库信息,如数据库的IP/域名、帐号、密码等,通过加密方式把记录写入到MySQL(一个关系型数据库管理系统)数据库,并事务性的写入到Redis
Cluster缓存集群,然后返回一个key值给用户,用户就可以在应用程序里使用这个key值和DLL文件来获取数据库账号密码信息。
需要说明的是,这里的Redis
Cluster缓存集群是一种分布式架构,即RedisCluster中有多个节点,每个节点都负责进行数据读写操作,该架构通过使用RedisCluster缓存集群,能够获取更高效的性能,并具备高可用,可进行故障切换。另外,在RedisCluster缓存集群中存储的数据依然是加密后的字符串,可防止数据信息的泄漏。
这里的数据库使用的是MySQL MGR,该数据库同样是集群模式,提供数据库的高可用,并用于于故障切换。另外,在MySQL表中存储的数据依然是加密后的字符串,可防止数据信息的泄漏。
并且,在MySQL表中存储的是以key值为唯一主键的记录,即使是相同的数据库的IP/域名、帐号、密码,经过加密后的字符串也是可以不相同的。
这样,当key值遭遇泄露时,只需对数据库中已保存的key值作相应的处理即可,解耦了因泄漏key值而导致大面积的数据库账号需要修改的现象。
在一个实施例中,所述数据库连接方法,还可以包括:判断所述key值是否泄露,若是,则通知所述数据库,并获取由所述数据库重新生成并分配的key值;其中,所述数据库将所述key值加入黑名单。
本实施例中,当检测到某一主机存在安全风险时,或某一应用程序存在安全风险时,即可判断该主机或某一应用程序中的key值存在泄露,这时,可通知相应的数据库,将该主机上的各个应用程序在数据库中对应的key值加入黑名单,或将该应用程序在数据库中对应的key值加入黑名单,以防止该主机上的应用程序或某一应用程序访问数据库,对数据库中存储的数据安全造成威胁。
并且,当数据库使用的是MySQL
MGR时,在MySQL表中存储的是以key值为唯一主键的记录,即使是相同的数据库的IP/域名、帐号、密码,经过加密后的字符串也是可以不相同的,这样可以在某个key值泄漏后,只要把这个key值加入黑名单,就可以屏蔽这个key的使用,并不需要修改现有的数据库的账号和密码,这样能够保证其他应用的稳定性,减少变更。
在一个实施例中,如图3所示,图3为一个实施例的通过DLL文件获取数据库信息的方法示意图;步骤S120中通过所述DLL文件获取与所述key值对应的数据库信息的步骤,可以包括:
S221:通过所述DLL文件获取本地缓存中与所述key值对应的加密后的数据库信息;
S222:判断在所述本地缓存中的获取结果;
S223:若获取失败,则在本地的磁盘缓存文件中进行获取所述数据库信息。
本实施例中,如图3所示,DLL文件接收上层应用程序的获取数据库请求,通过应用程序传入的一个唯一key值,得到一段由数据库IP/域名、帐号、密码加密后的字符串,再通过解密算法解释出数据库IP/域名、帐号、密码,以尝试对数据库进行连接测试。
其中,为了安全起见,数据库将预先生成的key值发送至应用程序之前,会通过加解密终端将明文的数据库信息进行加密,因此,数据库中保存的以及其他存储区域保存的数据库信息均为加密后的数据库信息,即DLL文件获取到的数据库信息为加密后的数据库信息。
由于数据库信息经常被应用程序所调用,因此,当本次调用并非首次调用,在本次调用之前,应用程序的本地缓存中或许已保存有相应的数据库信息。因而,为了方便DLL文件获取加密后的数据库信息,优先选择在本地缓存,即内存中获取,如果内存中没有数据或者获取失败,将在磁盘缓存文件中获取。
通过上述方式即可获取加密后的数据库信息,通过解密算法进行解密即可获得解密字符串,安全高效。
在一个实施例中,参见图3,步骤S223中若获取失败,则在本地的磁盘缓存文件中进行获取所述数据库信息的步骤之后,还可以包括:
S224:判断在所述磁盘缓存文件中的获取结果;
S225:若获取失败,则通过Web Service接口向Redis Cluster缓存集群请求加密后的数据库信息,并将获取的所述数据库信息写入/更新到所述本地缓存以及所述磁盘缓存文件中。
本实施例中,如图3所示,在内存中没有数据或者获取失败的情况下,将进行磁盘缓存文件的获取,如果还是失败或者没有数据的情况下,可向Web Service接口请求数据,并将获取的加密字符串写入/更新到本地缓存以及磁盘缓存文件中。
需要说明的是,这里的Web Service接口是一个分布式的高可用接口,它提供获取最新的数据库信息,查询key值所对应的加密后的数据库IP/域名、帐号、密码;具体示例如下:
[LinkName]:key值;
[En_LinkIP]:加密后的程序需要链接的数据库的IP地址/域名;
[En_LinkSa]:加密后的数据库使用的帐号;
[En_LinkPassword]:加密后得数据库帐号所对应的密码。
这里将获取的加密字符串写入/更新到本地缓存以及磁盘缓存文件中的目的是为了及时对本地缓存以及磁盘缓存文件中已保存的数据库信息进行更新,或将最新获取的数据库信息写入到本地缓存以及磁盘缓存文件中,以便在下一次应用程序调用本地的DLL文件获取数据库信息时使用。
在一个实施例中,步骤S225中通过Web
Service接口向Redis Cluster缓存集群请求加密后的数据库信息的步骤,可以包括:通过所述DLL文件调用Web
Service接口,其中,所述DLL文件根据所述Web Service接口读取Redis
Cluste缓存集群中存储的与所述key值对应的加密后的数据库信息,并通过所述Web Service接口进行二次加密。
本实施例中,当本地缓存和磁盘缓存文件中均未找到与key值对应的数据库信息后,可通过Web
Service接口请求加密后的数据库信息,Web Service接口与Redis Cluste缓存集群通信连接,读取Redis
Cluste缓存集群中存储的与该key值对应的加密后的数据库信息。
可以理解的是,数据库向应用程序发送key值之前,需要将明文的数据库信息发送至加解密终端,并通过加解密终端进行加密,数据库获取加密后的数据库信息后对其进行保存。
另外,加解密终端还将加密后的数据库信息事务性的写入到Redis Cluster缓存集群中,以对该加密后的数据库信息进行二次保存。
当DLL文件通过Web Service接口获取数据库信息时,Web Service接口读取RedisCluste缓存集群中存储的与key值对应的加密后的数据库信息。
并且,Web
Service接口获取到Redis
Cluste缓存集群中存储的加密后的数据库信息后,可以把这些值串联成一个字符串,并使用不同的加密算法进行二次加密,然后再将二次加密后的数据库信息返回至DLL文件中,这样,能够进一步提高数据传输过程中的安全性。
在一个实施例中,步骤S225中通过Web Service接口向Redis Cluster缓存集群请求加密后的数据库信息的步骤之后,还可以包括:
S226:通过所述DLL文件对所述Web Service接口进行线程监听,用于获取更新后的加密后的数据库信息;
S227:将获取的所述加密后的数据库信息写入/更新到所述本地缓存以及所述磁盘缓存文件中。
本实施例中,DLL文件中还有一个专门的线程,该线程能够监听Web Service接口的数据更新情况,如果数据版本有更新,则将其更新至内存缓存和磁盘缓存文件中。
具体地,当数据库的加解密终端中有数据库信息的更新后,可将该更新信息发送至Redis Cluster缓存集群中,Redis Cluster缓存集群可主动推送更新后的数据库信息,或由Web Service接口采用定时轮询的方式,以获取最新的数据库信息。
具体地,Web Service接口获取Redis Cluster缓存集群中的数据库信息后,可将该数据库信息与Web Service接口中保存的数据库信息之间进行比对,以获取更新后的数据库信息。
进一步地,DLL文件中的监听线程,也会通过定时轮询的方式监听Web Service接口的数据更新情况,当有数据更新时,即可将内存缓存和磁盘缓存文件中已保存的数据库信息进行及时更新。
在一个实施例中,如图4所示,图4为一个实施例的通过DLL文件对数据库进行连接测试的方法示意图;图4中,步骤S223中若获取失败,则在本地的磁盘缓存文件中获取所述数据库信息的步骤之后,还可以包括:
S231:利用所述数据库信息对所述数据库进行连接测试;
S232:判断连接测试结果;
S233:若所述测试失败,则通过所述DLL文件调用Web Service接口请求加密后的数据库信息,并利用所述数据库信息重新对所述数据库进行连接测试。
本实施例中,如图4所示,当DLL文件通过本地缓存或磁盘缓存文件获取加密后的数据库信息后,可对该数据库信息进行解密,以获取解密字符串,并利用该解密字符串对数据库进行连接测试。
若测试失败,则表示本地缓存或磁盘缓存文件中保存的数据库信息有误,或没有对本地缓存或磁盘缓存文件中保存的数据库信息进行及时更新,此时,DLL文件可通过WebService接口请求加密后的数据库信息,并对加密后的数据库信息进行解密。
DLL文件对重新获取的数据库信息进行解密后,可再次利用解密字符串对数据库进行连接测试,以确保测试成功,这样,便可将测试成功后的解密字符串返回给应用程序,以便应用程序能够成功连接数据库。
在一个实施例中,如图5所示,图5为一个实施例的数据库连接装置结构示意图,本实施例中提供了一种数据库连接装置,其包括:接收模块210、信息获取模块220、连接模块230,其中:
调用模块210,用于根据预存的唯一的key值调用本地的DLL文件;其中,所述key值是由数据库预先生成并分配的。
通常,应用程序中会配置有连接数据库的域名、端口、账号、密码等的配置文件,该配置文件中使用明文的数据库信息进行配置,即使服务器处在内网机制,仍然会对数据库的安全带来一定隐患,若黑客攻破内网,将会导致数据库中的数据存在被盗取的风险。
因此,本申请中,为了克服现有技术中因应用程序中的配置文件使用明文进行配置,使得数据库存在数据丢失、泄露的风险,优先采取了利用DLL文件并基于加解密算法的方式提高数据库的安全。
可以理解的是,操作系统中的应用程序,如Windows中,许多应用程序并不是一个完整的可执行文件,它们被分割成一些相对独立的动态链接库,即DLL文件,放置于操作系统中。当我们执行某一个程序时,相应的DLL文件就会被调用。
需要说明的是,一个应用程序可使用多个DLL文件,一个DLL文件也可能被不同的应用程序使用,这样的DLL文件被称为共享DLL文件。
因而,在本模块中,当上层的应用程序需要获取数据库信息时,可向DLL文件发送该应用程序中保存的key值,以便调用DLL文件获取与该key值对应的数据库信息。
可以理解的是,这里的key值指的是在数据库中预先生成的、分配给对应的应用程序的唯一身份标识,应用程序可利用该身份标识并通过DLL文件获取与该身份标识对应的数据库的域名、端口、账号、密码等。
信息获取模块220,用于通过所述DLL文件获取与所述key值对应的数据库信息,并利用所述数据库信息对所述数据库进行连接测试,其中,所述DLL文件测试成功后对获取到的加密后的数据库信息进行解密得到解密字符串。
本模块中,通过接收模块210根据预存的唯一的key值调用本地的DLL文件后,DLL文件可根据该key值查找对应的数据库信息,并尝试与数据库建立连接。
具体地,DLL文件可在本地缓存中或者本地的磁盘缓存文件中查找已缓存的数据库信息,当然,为了数据库的安全性,这里缓存的数据库信息为加密后的数据库信息,当查找到对应的加密后的数据库信息后,可利用预先配置的解密算法进行解密,即可得到解密字符串。
当得到解密字符串后,可利用该解密字符串尝试与数据库之间建立通信连接,若该测试连接成功,则表示获取到的数据库信息无误,若测试不成功,则可以继续尝试其他途径获取数据库信息,直到成功为止。
可以理解的是,这里的解密字符串指的是经解密算法解密后的数据库信息,该数据库信息包括但不限定于数据库的域名、端口、账号、密码等。
连接模块230,用于获取所述DLL文件返回的所述解密字符串,根据所述解密字符串连接所述数据库。
本模块中,当通过信息获取模块220得到解密字符串后,DLL文件首先利用该解密字符串对数据库进行连接测试,若测试成功,则表示获取到的解密字符串是正确的,若测试不成功,则说明本地缓存中或磁盘缓存文件中缓存的数据库信息存在错误,此时,需要通过其他方式重新获取数据库信息,并利用重新获取的数据库信息再次对数据库进行连接测试。
并且,当测试成功后,需要将解密字符串返回至应用程序中,以便应用程序根据DLL测试成功后的解密字符串进行数据库连接。这样,能够在一定程度上减少使用明文的数据库信息进行数据库连接时导致数据库信息泄露的风险,提高了数据库的安全。
上述数据库连接装置,根据预存的唯一的key值调用本地的DLL文件;其中,所述key值是由数据库预先生成并分配的;通过所述DLL文件获取与所述key值对应的数据库信息,并利用所述数据库信息对所述数据库进行连接测试,其中,所述DLL文件测试成功后对获取到的加密后的数据库信息进行解密得到解密字符串;获取所述DLL文件返回的所述解密字符串,根据所述解密字符串连接所述数据库。
本方案中,DLL文件接收上层应用程序的获取数据库请求,通过应用程序传入的唯一的key值,得到一段与数据库IP/域名、帐号、密码对应的加密后的数据库信息,再通过解密算法解释出明文的数据库IP/域名、帐号、密码,通过该解密字符串对数据库进行连接测试,并在测试成功后将解密字符串发送给应用程序,以便应用程序进行安全连接;在此过程中,数据库的IP/域名、账号、密码也不再是明文方式配置在配置文件中,而是调用DLL文件并通过加解密算法得到,这样有利于加强访问数据库的安全性,另外,当key值遭遇泄露时,只需对数据库中已保存的key值作相应的处理即可,解耦了因泄漏key值而导致大面积的数据库账号需要修改的现象。
关于数据库连接装置的具体限定可以参见上文中对于数据库连接方法的限定,在此不再赘述。上述数据库连接装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于终端设备中的处理器中,也可以以软件形式存储于终端设备中的存储器中,以便于处理器调用执行以上各个模块对应的操作。
在一个实施例中,提供了一种计算机设备,所述计算机设备中存储有计算机可读指令,所述计算机可读指令被一个或多个处理器执行时,使得一个或多个处理器执行如上述实施例中任一项所述的数据库连接方法的步骤。
图6是一种计算机设备的内部结构示意图,该计算机设备300可以被提供为一服务器。参照图6,计算机设备300包括处理组件302,其进一步包括一个或多个处理器,以及由存储器301所代表的存储器资源,用于存储可由处理组件302的执行的指令,例如应用程序。存储器301中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外,处理组件302被配置为执行指令,以执行上述任意实施例的数据库连接方法。
计算机设备300还可以包括一个电源组件303被配置为执行计算机设备300的电源管理,一个有线或无线网络接口304被配置为将计算机设备300连接到网络,和一个输入输出(I/O)接口305。计算机设备300可以操作基于存储在存储器301的操作系统,例如WindowsServer
TM、Mac OS XTM、Unix TM、Linux TM、Free BSDTM或类似。
本领域技术人员可以理解,图6中示出的结构,仅仅是与本申请方案相关的部分结构的框图,并不构成对本申请方案所应用于其上的计算机设备的限定,具体的计算机设备可以包括比图中所示更多或更少的部件,或者组合某些部件,或者具有不同的部件布置。
应该理解的是,虽然附图的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,其可以以其他的顺序执行。而且,附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,其执行顺序也不必然是依次进行,而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
以上所述仅是本申请的部分实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。
ff
f
f
f
f
f
这项专利(申请号:CN202010267283.1,公开号:CN111488331B)由广州虎牙科技有限公司申请,涉及数据库安全技术领域。
它主要描述了一种增强数据库安全性的数据库连接方法、装置和计算机设备,采用预存的唯一key值通过本地DLL文件进行操作,以加密和解密数据库信息进行安全连接。
这种方法不仅提高了数据库的安全性,还通过key密钥管理减少了泄露密钥key后需要大规模更改数据库账户的情况。
核心创新点:
1、密钥管理系统:使用预存的唯一key值调用DLL文件,通过DLL文件的加解密算法,从而不在配置文件中明文存储数据库的IP、账号和密码,极大提高安全性。
2、动态数据获取:在本地缓存或磁盘缓存文件中获取加密的数据库信息失败后,可以通过Web Service接口向Redis Cluster缓存集群请求加密的数据库信息,增强数据的实时获取和更新。
通过所述DLL文件对所述Web Service接口进行线程监听,用于获取更新后的加密后的数据库信息;
并将获取到的所述数据库信息写入/更新到所述本地缓存以及所述磁盘缓存文件中。
3、泄露应对机制:在key值泄露时,立即通知数据库并获取新的key值,并将泄露的key值加入黑名单,防止进一步使用。
主要应用场景:
提高企业数据库的访问安全性。
减少因配置文件泄露导致的安全风险。
实现数据库访问的动态管理和高效更新。
这项技术通过使用动态链接库(DLL)和加解密算法,不仅加强了数据库访问的安全性,还提高了系统的灵活性和响应速度。
我的理解
key:字符串包含数据库访问用户等规则信息,预先生成和分配,这个key泄露了也无所谓
value:数据库真正的ip,用户名,密码 ,也叫做“密钥”,并且使用对称加密进行加密,需要在DLL里解密,这个密钥泄露了之后需要更新
本地缓存或磁盘缓存文件:配置文件缓存,最终存放数据库用户名密码IP,存放在加解密计算机
配置文件:只存放key值,存放在生产服务器
环境组成:生产服务器,加解密计算机,redis服务器
思路
每个项目都会有redis数据库,如果无redis数据库实现不了
第一:redis服务器和加解密计算机不能给所有人访问,除了管理员,死守加解密计算机和redis,因为明文用户名密码都在加解密计算机
第二:确保redis服务器和加解密计算机不能挂
第三:生产服务器的配置文件里,只保存了数据库的key值,生产服务器拿这个key值发送请求给web service接口请求加解密计算机获取redis上的数据库用户密码,
加解密计算机的DLL根据这个key值从redis拿value值,然后对称解密这个value值得到连接字符串,然后进行数据库连接测试,
如果测试成功则做两个事,一个是保存在本地的配置文件缓存,另一个是返回用户名密码给生产服务器,由始至终,生产服务器上只有数据库的key值,不保存任何的数据库用户密码
第四:加解密计算每次返回结果给生产服务器时,会直接从配置文件缓存里拿明文用户名密码,并且对数据库进行连接测试,测试成功则返回给生产服务器,如果不成功则从redis获取最新的密钥,
然后进行数据库连接测试,测试成功则覆写配置文件缓存
第五:如果密钥泄露被破解,加解密计算机的dll只需要修改对称加密算法,换另一个算法,算出新的密钥值,然后更新redis的数据,根据原来的key更新value值(密钥),这个操作要么通过redis运维平台要么手工操作
通过这种key-value密钥管理减少了泄露“密钥”后需要大规模更改数据库账户密码的情况。
第六:redis的key值字符串包含数据库访问用户等规则信息,由redis预先生成和分配
这个专利多此一举,携程Apollo配置管理系统就可以满足需求,根本不需要用redis!!!
申请号:
CN202010251295.5
申请日期:
2020-04-01 !!!!!!!!!!!!!
公开(公告)号:
CN111459761B
公开(公告)日:
2024-03-01
申请(专利权)人:
广州虎牙科技有限公司
发明(设计)人:
陈畅亮
代理人:
林祥
4.7分
详情
代理机构:
北京博思佳知识产权代理有限公司
4.8分
详情
网址: http://www.bestipr.com
榜单: 全国卓越代理机构(申请量前1%)
电话: 010-50868480
典型客户: 浙江吉利控股集团有限公司,浙江极氪智能科技有限公司
代理人数: 42 查看次数 :203
IPC分类号:
G06F 11/30
外部链接:
摘要
本说明书提供一种Redis配置的方法、装置、存储介质及设备。该方法中,获取Redis集群中的历史监控指标,按照其变化趋势呈现线性还是非线性,对应采用线性回归模型或时间序列模型预测该监控指标在预设时间段的预测值,从而根据预测值来分析是否对Redis集群进行扩容,如此,实现对Redis的趋势分析,并根据预测的趋势及时地作出调整,获得合理的配置,进而解决了业务因告警处理落后造成的不利影响。
权利要求
1.一种Redis配置的方法,其特征在于,所述方法包括:
获取Redis集群中的历史监控指标;
基于简单线性回归算法对所述历史监控指标的变化趋势进行拟合,并计算拟合优度;当所述拟合优度超过第一预设值,则判断所述历史监控指标的变化趋势为线性;当所述拟合优度未超过第一预设值,则判断所述历史监控指标的变化趋势为非线性;
当所述历史监控指标的变化趋势为线性时,通过线性回归模型预测监控指标在预设时间段的预测值,所述线性回归模型基于线性回归算法对所述监控指标的样本数据训练后得到;当所述历史监控指标的变化趋势为非线性时,通过时间序列模型预测监控指标在预设时间段的预测值,所述时间序列模型基于时间序列法对所述监控指标的样本数据训练后得到;
根据所述预测值分析是否对所述Redis集群进行扩容。
2.根据权利要求1所述的方法,其特征在于,所述监控指标包括以下至少一项:机器的内存使用容量、机器的吞吐量、机器的CPU使用率、用户响应时间。
3.根据权利要求1所述的方法,其特征在于,所述监控指标包括机器的内存使用容量;当根据所述预测值分析确定对所述Redis集群进行扩容时,所述方法还包括:
增加可使用的内存,或使用内存淘汰策略。
4.根据权利要求1所述的方法,其特征在于,所述监控指标包括以下至少一项:机器的吞吐量、机器的CPU使用率和用户响应时间;当根据所述预测值分析确定对所述Redis集群进行扩容时,所述方法还包括:
搭建新的Redis从库,并更新分配流量的配置。
5.根据权利要求1所述的方法,其特征在于,所述线性回归模型包括岭回归模型,所述岭回归模型的训练过程包括:
将所述监控指标作为因变量,所述监控指标被采集时对应的时间作为自变量,利用岭回归算法获得岭回归模型;
利用评价函数确定所述岭回归模型对应的均方误差;
当所述均方误差的值小于第二预设值时,确定所述岭回归模型合格。
6.根据权利要求1所述的方法,其特征在于,所述时间序列模型包括Prophet模型;所述Prophet模型的训练过程包括:
将所述监控指标和所述监控指标被采集时对应的时间作为Prophet模型的样本数据,分别确定断点、与所述断点对应的分段线性函数、周期函数、节假日函数,得到训练后的Prophet模型。
7.一种Redis配置的装置,其特征在于,所述装置包括:
获取模块,用于获取Redis集群中的历史监控指标;基于简单线性回归算法对所述历史监控指标的变化趋势进行拟合,并计算拟合优度;当所述拟合优度超过第一预设值,则判断所述历史监控指标的变化趋势为线性;当所述拟合优度未超过第一预设值,则判断所述历史监控指标的变化趋势为非线性;
预测模块,用于当所述历史监控指标的变化趋势为为线性时,通过线性回归模型预测监控指标在预设时间段的预测值,所述线性回归模型基于线性回归算法对所述监控指标的样本数据训练后得到;当所述历史监控指标的变化趋势为非线性时,通过时间序列模型预测监控指标在预设时间段的预测值,所述时间序列模型基于时间序列法对所述监控指标的样本数据训练后得到;
分析模块,用于根据所述预测值分析是否对所述Redis集群进行扩容。
8.一种计算机设备,其特征在于,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其中,所述处理器执行所述程序时实现如权利要求1~6任一项所述的方法。
9.一种计算机可读存储介质,其特征在于,其上存储有计算机程序,该程序被处理器执行时实现权利要求1~6任一项所述的方法。
说明书
技术领域
本说明书涉及计算机技术领域,尤其涉及一种Redis配置的方法、装置、存储介质及设备。
背景技术
Redis(Remote
Dictionary
Server,远程字典服务)是一个key-value存储系统,经常作为缓存使用。目前,在对Redis的使用过程中,经常会遇到Redis内存容量不足而导致的不可用、或者Redis实例性能不足而导致响应时间过长甚至超时,进而影响业务使用的问题。相关技术中,通常的解决方法是设置告警阈值,当内存或性能达到告警阈值时触发一个告警,然后再人工介入对内存进行扩容。这种方式往往导致处理严重落后于线上需求。
发明内容
为克服相关技术中存在的问题,本说明书提供了一种Redis配置的方法、装置、存储介质及设备。
根据本说明书实施例的第一方面,提供一种Redis配置的方法,所述方法包括:
获取Redis集群中的历史监控指标,并判断所述历史监控指标的变化趋势是否为线性;
当所述历史监控指标的变化趋势为线性时,通过线性回归模型预测监控指标在预设时间段的预测值,所述线性回归模型基于线性回归算法对所述监控指标的样本数据训练后得到;当所述历史监控指标的变化趋势为非线性时,通过时间序列模型预测监控指标在预设时间段的预测值,所述时间序列模型基于时间序列法对所述监控指标的样本数据训练后得到;
根据所述预测值分析是否对所述Redis集群进行扩容。
在某些例子中,上述监控指标包括以下至少一项:机器的内存使用容量、机器的吞吐量、机器的CPU使用率、用户响应时间。
在某些例子中,上述判断所述历史监控指标的变化趋势是否为线性包括:
基于简单线性回归算法对所述历史监控指标的变化趋势进行拟合,并计算拟合优度;
当所述拟合优度超过第一预设值,则判断所述历史监控指标的变化趋势为线性;
当所述拟合优度未超过第一预设值,则判断所述历史监控指标的变化趋势为非线性。
在某些例子中,上述监控指标包括机器的内存使用容量;当根据所述预测值分析确定对所述Redis集群进行扩容时,所述方法还包括:
增加可使用的内存,或使用内存淘汰策略。
在某些例子中,上述监控指标包括以下至少一项:机器的吞吐量、机器的CPU使用率和用户响应时间;当根据所述预测值分析确定对所述Redis集群进行扩容时,所述方法还包括:
搭建新的Redis从库,并更新分配流量的配置。
在某些例子中,上述线性回归模型包括岭回归模型,所述岭回归模型的训练过程包括:
将所述监控指标作为因变量,所述监控指标被采集时对应的时间作为自变量,利用岭回归算法获得岭回归模型;
利用评价函数确定所述岭回归模型对应的均方误差;
当所述均方误差的值小于第二预设值时,确定所述岭回归模型合格。
在某些例子中,上述时间序列模型包括Prophet模型;所述Prophet模型的训练过程包括:
将所述监控指标和所述监控指标被采集时对应的时间作为Prophet模型的样本数据,分别确定断点、与所述断点对应的分段线性函数、周期函数、节假日函数,得到训练后的Prophet模型。
根据本说明书实施例的第二方面,提供一种Redis配置的装置,所述装置包括:
获取模块,用于获取Redis集群中的历史监控指标,并判断所述历史监控指标的变化趋势是否为线性;
预测模块,用于当所述历史监控指标的变化趋势为为线性时,通过线性回归模型预测监控指标在预设时间段的预测值,所述线性回归模型基于线性回归算法对所述监控指标的样本数据训练后得到;当所述历史监控指标的变化趋势为非线性时,通过时间序列模型预测监控指标在预设时间段的预测值,所述时间序列模型基于时间序列法对所述监控指标的样本数据训练后得到;
分析模块,用于根据所述预测值分析是否对所述Redis集群进行扩容。
根据本说明书实施例的第三方面,提供一种计算机可读存储介质,其上存储有计算机程序,该程序被处理器执行时实现说明书实施例中任一项方法。
根据本说明书实施例的第四方面,提供一种计算机设备,包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序,其中,所述处理器执行所述程序时实现说明书实施例中任一项方法。
本说明书的实施例提供的技术方案可以包括以下有益效果:
本说明书实施例中,公开了一种Redis配置的方法、装置、存储介质及设备。该方法中,获取Redis集群中的历史监控指标,按照其变化趋势呈现线性还是非线性,对应采用线性回归模型或时间序列模型预测该监控指标在预设时间段的预测值,从而根据预测值来分析是否对Redis集群进行扩容,如此,实现对Redis的趋势分析,并根据预测的趋势及时地作出调整,获得合理的配置,进而解决了业务因告警处理落后造成的不利影响。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性和解释性的,并不能限制本说明书。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分,示出了符合本说明书的实施例,并与说明书一起用于解释本说明书的原理。
图1是本说明书根据一示例性实施例示出的一种Redis配置的方法的流程图;
图2是本说明书实施例Redis配置的装置所在计算机设备的一种硬件结构图;
图3是本说明书根据一示例性实施例示出的一种Redis配置的装置的框图;
图4是本说明书根据一示例性实施例示出的一种Redis配置系统的架构的示意图;
图5A是本说明书根据一示例性实施例示出的一种Redis配置系统中第一子系统的架构的示意图;
图5B是本说明书根据一示例性实施例示出的一种Redis配置系统中第二子系统的架构的示意图;
图5C是本说明书根据一示例性实施例示出的获取监控指标的预测值的效果示意图。
具体实施方式
这里将详细地对示例性实施例进行说明,其示例表示在附图中。下面的描述涉及附图时,除非另有表示,不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反,它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。
在本说明书使用的术语是仅仅出于描述特定实施例的目的,而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式,除非上下文清楚地表示其他含义。还应当理解,本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解,尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息,但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如,在不脱离本说明书范围的情况下,第一信息也可以被称为第二信息,类似地,第二信息也可以被称为第一信息。取决于语境,如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
Redis(Remote
Dictionary
Server,远程字典服务)是一个key-value存储系统,可以支持每秒十几万次的读/写操作,其性能远超数据库,并且还支持集群、分布式、主从同步等配置,经常作为缓存使用。目前,在对Redis的使用过程中,经常会遇到Redis内存容量不足而导致的不可用、或者Redis实例性能不足而导致响应时间过长甚至超时,进而影响业务使用的问题。相关技术中,通常的解决方法是设置告警阈值,当内存或性能达到告警阈值时触发一个告警,然后再人工介入对内存进行扩容。可以理解的,这容易导致处理严重落后于线上需求。
接下来对本说明书实施例进行详细说明。
如图1所示,图1是本说明书根据一示例性实施例示出的一种Redis配置的方法的流程图,所述方法包括:
在步骤101、获取Redis集群中的历史监控指标,并判断所述历史监控指标的变化趋势是否为线性;
通常认为,Redis集群具有三种模式,分别是主从模式、Sentinel模式和Cluster模式。一个Redis集群可以是由多个Redis实例组成,在主从模式中,实例分为主数据库和从数据库两类,也可简称为主库和从库。主库可以提供读写服务,当读写操作导致数据变化时会自动将数据同步给从库;从库一般只提供读服务,并且接收主库同步过来的数据。Sentinel(哨兵)模式是建立在主从模式的基础上,提供一个哨兵进程用于监控Redis集群中主库的工作状态,在主库发生故障的时候,可以实现主库和从库的切换,保证系统的高可用。而Cluster模式可以认为是主从模式和Sentinel模式的结合体,其中多个Redis实例网络互联,数据共享,客户端可以连接任何一个主库进行读写,从库不提供服务,仅作为备用。在某些例子中,本步骤中的Redis集群可以是指主从模式的Redis集群,当然,本说明书对此不作限定。
在某些例子中,本步骤中历史监控指标是指Redis集群中各实例的历史监控指标,这里的监控指标可以包括以下至少一项:机器的内存使用容量、机器的吞吐量、机器的CPU使用率、用户响应时间。机器的内存使用容量可以反映Redis实例的内存状态,机器的吞吐量、机器的CPU使用率或用户响应时间可以反映Redis实例的性能状态。可以理解的,Redis实例的内存一般是配置好的,其性能也是有所限制的,因此,当某一Redis实例的内存状态或性能状态在一段时间内持续临近上限时,表明该Redis实例的处理压力较大,需要扩容。
在某些例子中,本步骤中的判断所述历史监控指标的变化趋势是否为线性可以包括:基于简单线性回归算法对所述历史监控指标的变化趋势进行拟合,并计算拟合优度;当所述拟合优度超过第一预设值,则判断所述历史监控指标的变化趋势为线性;当所述拟合优度未超过第一预设值,则判断所述历史监控指标的变化趋势为非线性。本步骤中的历史监控指标可以是按照一定的周期采集的,周期可以根据具体场景的需要而设定,可以是一分钟、两分钟、一小时、一天等等。拟合优度的概念是回归直线对预测值的拟合程度,一般以可决系数R2作为度量的统计量,可决系数的值越接近1,说明回归直线对预测值的拟合程度越好。假定周期为一小时,获取的历史监控指标为四点到八点对应的机器的内存使用容量,分别为4.2G、4.8G、5.2G、5.5G、5.7G,以此为例,则样本数据可记为(4,4.2)、(5,4.8)、(6,5.2)、(7,5.5)和(8,5.7),基于简单线性回归算法代入这些样本数据进行拟合,这里的简单线性回归算法可以包括一元线性回归和最小二乘法,拟合后计算得可决系数为0.96,当第一预设值为0.97时,则拟合优度0.96未超过第一预设值0.97,判断得此历史监控指标的变化趋势为非线性。
在步骤102、当所述历史监控指标的变化趋势为线性时,通过线性回归模型预测监控指标在预设时间段的预测值,所述线性回归模型基于线性回归算法对所述监控指标的样本数据训练后得到;当所述历史监控指标的变化趋势为非线性时,通过时间序列模型预测监控指标在预设时间段的预测值,所述时间序列模型基于时间序列法对所述监控指标的样本数据训练后得到;
在判断历史监控指标的变化趋势是线性还是非线性后,通过对应的模型预测监控指标在预设时间段的预测值。在某些例子中,本步骤中的线性回归模型可以是指:岭回归模型。这里的岭回归模型可以基于R语言实现,也可以基于SPSS(Statistical
Product andService
Solutions,统计产品与服务解决方案)实现。岭回归模型的训练过程包括:将所述监控指标作为因变量,所述监控指标被采集时对应的时间作为自变量,利用岭回归算法获得岭回归模型;利用评价函数确定所述岭回归模型对应的均方误差;当所述均方误差的值小于第二预设值时,确定所述岭回归模型合格。通俗地讲,在输入自变量和因变量对应的样本数据后,选择岭参数K值,使可决系数R2的值尽量大,同时尽量稳定,确定后即可得到函数形式的岭回归模型;该岭回归模型的均方误差MSE可通过以下公式确定:
其中,observedi为样本数据,predictedi为将自变量代入岭回归模型后得到的数据,n为样本个数;
均方误差MSE评价数据的变化程度,MSE的值越小,说明该模型在描述样本数据时具有更好的精确度,则该模型在预测样本数据的未来趋势时也具有更好的效果。可以理解的,这里的第二预设值可以根据监控指标的类型、对该模型要求的精度以及其他具体场景的需要进行设定。
本说明书实施例针对呈非线性的监控指标,是基于时间序列法进行建模和预测。时间序列法,也叫时间序列分析,是根据系统观测得到的时间序列数据,通过曲线拟合和参数估计来建立数学模型的理论和方法,常用在国民经济宏观控制、企业经营管理、气象预报、环境污染控制等方面。在某些例子中,本说明书实施例所指出的时间序列模型包括Prophet模型,Prophet是一种开源的时间序列预测工具,可应用于建立Prophet模型。在某些例子中,Prophet模型的训练过程包括:将所述监控指标和所述监控指标被采集时对应的时间作为Prophet模型的样本数据,分别确定断点、与所述断点对应的分段线性函数、周期函数、节假日函数,得到训练后的Prophet模型。通俗地讲,Prophet的原理就是分析各种时间序列特征:周期性、趋势性、节假日效应,以及部分异常值。在趋势方面,它支持加入变化点,实现分段线性拟合;在周期方面,它使用傅里叶级数来建立周期函数,在节假和突发事件方面,可以指定节假日,及其前后相关的若干天。如此,建立好的Prophet模型在用于预测监控指标的未来趋势时,具有较好的预测精度。
在预测监控指标在预设时间段的预测值时,只需要将预设时间段作为输入量,输入对应的模型,之后得到的输出量即为所需的预测值。这里的预设时间段可以根据预测的需求进行设置。
当然,在某些例子中,本步骤中所提到的线性回归模型也可以是Lasso回归模型,时间序列模型可以是LSTM(Long Short Term Memory,长短期记忆网络)模型,这里可以根据所选用的监控指标而选择,本说明书对此不作限定。
在步骤103、根据所述预测值分析是否对所述Redis集群进行扩容。
在得到监控指标在预设时间段的预测值后,可以根据预测值分析如何对Redis进行配置。通常的,可以针对不同监控指标设置不同的阈值,这里的阈值是基于该监控指标上限的百分比而确定,当预测值超过阈值时,分析确定对该Redis进行扩容。比如,监控指标包括机器的内存使用容量,可以设置该监控指标的阈值为上限的百分之八十,则若分配的机器的最大内存使用容量为10G,其阈值为8G,当该监控指标在预设时间段的预测值超过8G时,分析确定对该Redis进行扩容。
本说明书实施例针对反映Redis内存状态和性能状态两种监控指标对应提供了以下扩容方案:
针对内存状态,监控指标包括机器的内存使用容量;当根据预测值分析确定对Redis集群进行扩容时,先尝试增加可使用的内存,当可使用的内存为零时,则使用内存淘汰策略,将访问频率最少的键值对淘汰,从而扩展Redis内存;
针对性能状态,监控指标包括以下至少一项:机器的吞吐量、机器的CPU使用率和用户响应时间;当根据所述预测值分析确定对所述Redis集群进行扩容时,搭建新的从库,搭建完成后更新配置,均衡分配流量,即将业务流量分出一部分到新的从库上,达到扩展Redis性能的目的。
扩容之后,还可以将扩容前后的状态记录,并通知给相关人员。
另外,在得到监控指标的预测值时,不仅要分析是否需要对Redis扩容,还要分析是否可以对Redis扩容。比如,监控指标包括机器的CPU使用率,当其预测值显示机器的CPU使用率持续高于95%时,远超过设置的阈值60%,则可以触发告警,通知相关人员,由相关人员介入排查问题。
本说明书实施例,获取Redis集群中的历史监控指标,按照其变化趋势呈现线性还是非线性,对应采用岭回归模型或时间序列模型预测该监控指标在预设时间段的预测值,从而根据预测值来分析是否对Redis集群进行扩容,如此,实现对Redis的趋势分析,并根据预测的趋势及时地作出调整,实现了弹性扩容,从而获得合理的配置,进而解决了业务因告警处理落后造成的不利影响。
本领域技术人员可理解的,本说明书实施例的方法还可以应用于实现对Redis的弹性缩容。
与前述方法的实施例相对应,本说明书还提供了Redis配置的装置及其所应用的终端的实施例。
本说明书Redis配置的装置的实施例可以应用在计算机设备上,例如服务器或终端设备。装置实施例可以通过软件实现,也可以通过硬件或者软硬件结合的方式实现。以软件实现为例,作为一个逻辑意义上的装置,是通过其所在文件处理的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言,如图2所示,为本说明书实施例Redis配置的装置所在计算机设备的一种硬件结构图,除了图2所示的处理器510、内存530、网络接口520、以及非易失性存储器540之外,实施例中装置531所在的服务器或电子设备,通常根据该计算机设备的实际功能,还可以包括其他硬件,对此不再赘述。
相应地,本说明书实施例还提供一种计算机存储介质,所述存储介质中存储有程序,所述程序被处理器执行时实现上述任一实施例中的方法。
本说明书实施例可采用在一个或多个其中包含有程序代码的存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。计算机可用存储介质包括永久性和非永久性、可移动和非可移动媒体,可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括但不限于:相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。
如图3所示,图3是本说明书根据一示例性实施例示出的一种Redis配置的装置的框图,所述装置包括:
获取模块31,用于获取Redis集群中的历史监控指标,并判断所述历史监控指标的变化趋势是否为线性;
预测模块32,用于当所述历史监控指标的变化趋势为为线性时,通过线性回归模型预测监控指标在预设时间段的预测值,所述线性回归模型基于线性回归算法对所述监控指标的样本数据训练后得到;当所述历史监控指标的变化趋势为非线性时,通过时间序列模型预测监控指标在预设时间段的预测值,所述时间序列模型基于时间序列法对所述监控指标的样本数据训练后得到;
分析模块33,用于根据所述预测值分析是否对所述Redis集群进行扩容。
上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。
对于装置实施例而言,由于其基本对应于方法实施例,所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的,其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的,作为模块显示的部件可以是或者也可以不是物理模块,即可以位于一个地方,或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下,即可以理解并实施。
为了对本说明书实施例的方法有更深入的理解,接下来将以一应用实例做进一步的说明:
如图4所示,图4是本说明书根据一示例性实施例示出的一种Redis配置系统的架构的示意图,该Redis配置系统应用本说明书实施例的方法,对Redis进行配置。该Redis配置系统的架构主要可以包括如下部分:监控指标采集单元、趋势分析单元、分析决策单元、配置单元、Redis代理单元、Redis集群和运维平台。
其中,监控指标采集单元用于获取Redis集群中的历史监控指标,具体的,可以是采集Redis集群中各实例的各项监控指标,包括以下至少一项:机器的内存使用容量、机器的吞吐量、机器的CPU使用率、用户响应时间,将采集到的数据上报Kafka集群,由Kafka集群通过消费队列的模式把采集的数据保存到ClickHouse数据库中。
趋势分析单元用于通过算法分析内存和性能的使用情况,给出未来一段时间的趋势数值,具体的,可以是从ClickHouse数据库中获取历史监控指标,判断历史监控指标的变化趋势是否为线性,如果是线性,则通过岭回归模型预测监控指标在预设时间段的预测值;如果是非线性,则通过Prophet模型预测监控指标在预设时间段的预测值。同样的,岭回归模型和Prophet模型在训练时的样本数据从ClickHouse数据库中获取。
分析决策单元用于根据趋势分析单元得到的预测值,分析是否需要对Redis进行扩容,如果是则通知配置单元进行相应的扩容操作,同时将扩容状态通知运维平台;并且,分析是否可以对Redis进行扩容,如果无法扩容,则触发告警,通知运维平台。
配置单元用于执行对Redis集群的扩容操作,具体的,分为内存扩容操作和性能扩容操作两种,内存扩容是先尝试增加可使用的内存,当可使用的内存为零时,则使用内存淘汰策略,将访问频率最少的键值对淘汰;性能扩容是搭建新的从库,搭建完成后通知Redis代理单元,更新Redis配置,均衡分配流量。
Redis代理层用于对Redis进行负载均衡与读写分离。
具体地,上述Redis配置系统可以认为包括第一子系统和第二子系统,其中,第一子系统针对内存方向,第二子系统针对性能方向,如图5A和图5B所示,图5A是本说明实施例示出的第一子系统的架构的示意图;图5B是本说明书实施例示出的第二子系统的架构的示意图。其中:
在第一子系统中,监控指标采集单元监控采集Redis集群的历史监控指标并上报到Kalfa集群,这里的监控指标包括机器的内存使用容量;Kalfa集群保存上报的数据,通过消费队列的模式把结果保存到ClickHouse数据库;ClickHouse数据库为趋势分析单元提供数据;趋势分析单元通过算法分析内存的使用情况,给出未来一段时间的趋势数据;分析决策单元根据趋势数据,分析是否需要对Redis进行扩容,是则通知配置单元进行相应的扩容操作,同时将扩容状态通知运维平台,并分析是否可以对Redis进行扩容,如果无法扩容,则触发告警,通知运维平台;配置单元执行内存扩容操作,先尝试增加可使用的内存,当可使用的内存为零时,则使用内存淘汰策略,将访问频率最少的键值对淘汰。
在第二子系统中,监控指标采集单元、Kalfa集群、ClickHouse、趋势分析单元、分析决策单元的逻辑关系与第一子系统相同,不同的是,这里的监控指标包括以下至少一项:机器的吞吐量、机器的CPU使用率、用户响应时间;并且,配置单元执行性能扩容操作,搭建新的从库,搭建完成后通知Redis代理单元,更新Redis配置,均衡分配流量;Redis代理层对Redis进行负载均衡与读写分离。
第一子系统的趋势分析单元通过算法分析内存的使用情况,第二子系统的趋势分析单元通过算法分析性能的使用情况。这里的算法可以是线性回归算法或者时间序列算法,具体地,可以是判断历史监控指标的变化趋势是否为线性,如果是线性,则通过岭回归模型预测监控指标在预设时间段的预测值;如果是非线性,则通过Prophet模型预测监控指标在预设时间段的预测值。如图5C所示,图5C是本说明书根据一示例性实施例示出的获取监控指标的预测值的效果示意图,其中,监控指标为机器的QPS(Queries-per-second,每秒查询率),属于反映性能的指标,是机器的吞吐量的重要参数之一;图中曲线1是监控采集的样本数据的曲线,点P表示当前时间点,曲线2是根据算法对当前时间点之前的样本数据进行拟合后的曲线,点Q是通过算法预测的机器的QPS在5:30时间点对应的预测值,该预测值为101.8K,而根据后期采集的数据可知其在5:30时间点的实际值为68.6K,在5:40时间点的实际值为103.4K,因此,系统根据预测值进行决策具有较高的可行性和精准性。
上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。
本领域技术人员在考虑说明书及实践这里申请的发明后,将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本说明书的真正范围和精神由下面的权利要求指出。
应当理解的是,本说明书并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。
以上所述仅为本说明书的较佳实施例而已,并不用以限制本说明书,凡在本说明书的精神和原则之内,所做的任何修改、等同替换、改进等,均应包含在本说明书保护的范围之内。
f
f
f
f
f
f
f
redis动态扩容
这项专利(申请号:CN202010251295.5,公开号:CN111459761B)由广州虎牙科技有限公司申请,涉及到一种针对Redis的配置方法、装置、存储介质及设备,
主要用于通过监控Redis集群中的历史监控指标来预测并分析是否需要对Redis集群进行扩容,从而优化资源管理和提高服务效率。
核心内容:
1、监控与分析:方法包括获取Redis集群中的历史监控指标,如内存使用、CPU使用率、吞吐量和响应时间,并根据这些指标的历史数据来预测其未来的趋势。
2、预测模型:根据历史数据的趋势是线性还是非线性,分别采用线性回归模型和时间序列模型(如Prophet模型)进行预测。
3、扩容决策:依据预测的监控指标,分析是否需要对Redis集群进行扩容,比如增加内存或增建Redis从库以应对未来的负载需求。
创新点:
动态预测与响应:通过先进的预测模型,能够根据实时数据动态预测Redis的资源需求,而非仅仅依赖于静态的阈值设置,从而提前做出扩容决策。
减少人工干预:自动化的预测和扩容决策过程减少了人工介入的需求,提高了系统的响应速度和效率。
应用场景:
大规模数据处理:适用于需要高性能数据处理和存储的企业,如在线游戏、大数据分析等。
资源敏感的应用:对于资源使用高度敏感的应用,如金融服务和电子商务平台,可以根据实际业务需求动态调整资源。
通过这种技术,企业可以更有效地管理其数据缓存系统,确保在用户访问量激增时系统依然能够维持高效运作。这项技术提供了一种智能化的解决方案,通过精确预测和及时扩容来优化Redis的性能和资源利用率。
时间序列模型,针对非线性
线性回归模型,针对线性
通过加从库扩容:redis(在线加内存肯定不可能的),MongoDB,MySQL
https://www.patentguru.com/cn/inventor/%E9%99%88%E7%95%85%E4%BA%AE
申请号:
CN202010183781.8
申请日期:
2020-03-16
公开(公告)号:
CN111400046B
公开(公告)日:
2024-02-27
申请(专利权)人:
广州虎牙科技有限公司
发明(设计)人:
陈畅亮
刘亚丹
毛茂德
代理人:
张欣欣
4.8分
详情
代理机构:
北京超凡宏宇知识产权代理有限公司
4.8分
详情
网址: -
榜单: 全国卓越代理机构(申请量前1%)
电话: 010-62563559
典型客户: 平安银行股份有限公司,网易(杭州)网络有限公司
代理人数: 108 查看次数 :305
IPC分类号:
G06F 9/50; G06F 16/21
外部链接:
摘要
本申请提供一种数据库资源管理方法、装置、资源管理设备及存储介质,涉及数据库处理领域。本申请根据获取到的数据库资源申请请求所包括的与目标数据库实例对应的内存需求量及磁盘空间需求量,筛选出满足内存需求量及磁盘空间需求量的待分配物理机,而后根据每个待分配物理机的运行参数进行多维度地考虑,从所有待分配物理机中确定出与目标数据库实例匹配的主物理机及从物理机,进而在主物理机上分配足够资源创建该目标数据库实例所对应的主数据库,并在从物理机上分配足够资源创建该目标数据库实例所对应的从数据库,确保目标数据库实例能够在对应物理机的支持下达到良好的运维效果,提高了物理机分配合理性及机器适配性。
权利要求
1.一种数据库资源管理方法,应用于数据库管理系统中的资源管理设备,其中所述数据库管理系统还包括多个物理机,其特征在于,所述资源管理设备存储有物理机初选模型及物理机次选模型,所述方法包括:
获取数据库资源申请请求,其中所述数据库资源申请请求包括与目标数据库实例对应的内存需求量及磁盘空间需求量;
在数据库管理系统中筛选出剩余内存满足所述内存需求量且剩余磁盘空间满足所述磁盘空间需求量的待分配物理机;
根据每个待分配物理机的运行参数在筛选出的待分配物理机中,确定与所述目标数据库实例匹配的主物理机及从物理机,其中所述运行参数包括对应物理机的CPU使用率、读写比例、QPS数值、负载大小及告警次数;
在所述主物理机与所述从物理机上针对所述目标数据库实例进行资源分配;
其中,所述根据每个待分配物理机的运行参数在筛选出的待分配物理机中,确定与所述目标数据库实例匹配的主物理机及从物理机,包括:
按照从小到大的顺序分别对所有待分配物理机各自的CPU使用率、读写比例、QPS数值、负载大小及告警次数进行排序,得到多个物理机排序结果;
调用所述物理机初选模型从所有待分配物理机中筛选在每个物理机排序结果中的排名均处于第一预设排名范围的第一初选物理机;
若筛选出至少一个第一初选物理机,则在筛选出的第一初选物理机中选取一个物理机作为主物理机;
调用所述物理机次选模型在除去所述主物理机后的剩余第一初选物理机中筛选不与所述主物理机处于同一机架的第一次选物理机;
当筛选出至少一个第一次选物理机时,从筛选出的第一次选物理机中确定从物理机。
2.根据权利要求1所述的方法,其特征在于,所述数据库资源申请请求还包括与所述目标数据库实例对应的实例访问高峰时段,所述在筛选出的第一初选物理机中选取一个物理机作为主物理机,包括:
根据每个第一初选物理机在所述实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第一初选物理机进行排序,得到对应的第一初选排序结果;
选取所述第一初选排序结果中排名第一的第一初选物理机作为所述主物理机。
3.根据权利要求2所述的方法,其特征在于,所述数据库资源申请请求还包括与所述目标数据库实例对应的从库预创数目,所述从筛选出的第一次选物理机中确定从物理机,包括:
根据每个第一次选物理机在所述实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第一次选物理机进行排序,得到对应的第一次选排序结果;
选取所述第一次选排序结果中排名不大于所述从库预创数目的所有第一次选物理机作为所述从物理机。
4.根据权利要求1-3中任意一项所述的方法,其特征在于,所述根据每个待分配物理机的运行参数在筛选出的待分配物理机中,确定与所述目标数据库实例匹配的主物理机及从物理机,还包括:
当无法筛选出第一次选物理机时,调用所述物理机次选模型从所有待分配物理机中筛选出不与所述主物理机处于同一机架并在与CPU使用率及读写比例对应的物理机排序结果中的排名均处于第一预设排名范围的第二次选物理机;
从筛选出的第二次选物理机中确定从物理机。
5.根据权利要求4所述的方法,其特征在于,所述从筛选出的第二次选物理机中确定从物理机,包括:
根据每个第二次选物理机在实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第二次选物理机进行排序,得到对应的第二次选排序结果;
选取所述第二次选排序结果中排名不大于从库预创数目的所有第二次选物理机作为所述从物理机。
6.根据权利要求4所述的方法,其特征在于,所述根据每个待分配物理机的运行参数在筛选出的待分配物理机中,确定与所述目标数据库实例匹配的主物理机及从物理机,还包括:
若无法筛选出第一初选物理机,则调用所述物理机初选模型从所有待分配物理机中筛选在与CPU使用率及读写比例对应的物理机排序结果中的排名均处于第二预设排名范围的第二初选物理机,其中所述第二预设排名范围包含所述第一预设排名范围;
在筛选出的第二初选物理机中选取一个物理机作为主物理机;
调用所述物理机次选模型在除去所述主物理机后的剩余第二初选物理机中筛选不与所述主物理机处于同一机架的第三次选物理机;
从筛选出的第三次选物理机中确定从物理机。
7.根据权利要求6所述的方法,其特征在于,所述在筛选出的第二初选物理机中选取一个物理机作为主物理机,包括:
根据每个第二初选物理机在实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第二初选物理机进行排序,得到对应的第二初选排序结果;
选取所述第二初选排序结果中排名第一的第二初选物理机作为所述主物理机。
8.根据权利要求6所述的方法,其特征在于,所述从筛选出的第三次选物理机中确定从物理机,包括:
根据每个第三次选物理机在实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第三次选物理机进行排序,得到对应的第三次选排序结果;
选取所述第三次选排序结果中排名不大于从库预创数目的所有第三次选物理机作为所述从物理机。
9.一种数据库资源管理装置,应用于数据库管理系统中的资源管理设备,其中所述数据库管理系统还包括多个物理机,其特征在于,所述资源管理设备存储有物理机初选模型及物理机次选模型,所述装置包括:
资源请求获取模块,用于获取数据库资源申请请求,其中所述数据库资源申请请求包括与目标数据库实例对应的内存需求量及磁盘空间需求量;
物理机筛选模块,用于在数据库管理系统中筛选出剩余内存满足所述内存需求量且剩余磁盘空间满足所述磁盘空间需求量的待分配物理机;
主从机确定模块,用于根据每个待分配物理机的运行参数在筛选出的待分配物理机中,确定与所述目标数据库实例匹配的主物理机及从物理机,其中所述运行参数包括对应物理机的CPU使用率、读写比例、QPS数值、负载大小及告警次数;
机器资源处理模块,用于在所述主物理机与所述从物理机上针对所述目标数据库实例进行资源分配;
其中,所述主从机确定模块根据每个待分配物理机的运行参数在筛选出的待分配物理机中,确定与所述目标数据库实例匹配的主物理机及从物理机,包括:
按照从小到大的顺序分别对所有待分配物理机各自的CPU使用率、读写比例、QPS数值、负载大小及告警次数进行排序,得到多个物理机排序结果;
调用所述物理机初选模型从所有待分配物理机中筛选在每个物理机排序结果中的排名均处于第一预设排名范围的第一初选物理机;
若筛选出至少一个第一初选物理机,则在筛选出的第一初选物理机中选取一个物理机作为主物理机;
调用所述物理机次选模型在除去所述主物理机后的剩余第一初选物理机中筛选不与所述主物理机处于同一机架的第一次选物理机;
当筛选出至少一个第一次选物理机时,从筛选出的第一次选物理机中确定从物理机。
10.一种资源管理设备,其特征在于,包括处理器和存储器,所述存储器存储有能够被所述处理器执行的机器可执行指令,所述处理器可执行所述机器可执行指令,以实现权利要求1-8中任意一项所述的数据库资源管理方法。
11.一种存储介质,其上存储有计算机程序,其特征在于,所述计算机程序被处理器执行时,实现权利要求1-8中任意一项所述的数据库资源管理方法。
说明书
技术领域
本申请涉及数据库处理领域,具体而言,涉及一种数据库资源管理方法、装置、资源管理设备及存储介质。
背景技术
随着互联网技术的不断发展,数据库因其在数据管理层面上具有高效的数据控制功能及数据检索功能,而被广泛应用到各大行业。其中,数据库在具体构建时通常需要选定某个物理机作为其承载体,并通过该物理机的相关硬件资源确保该数据库得以正常运维。目前,业界主流在针对数据库实例进行资源申请时,是通过检测物理机当前剩余的内存是非能够支撑该数据库实例的内存需求,并在能够支撑内存需求的情况下,直接选定该物理机配合机器资源用以实现该数据库实例。这种数据库实例的分配方案容易出现数据库实例在运维时受到物理机硬件设施的限制而无法达到较佳的运维效果,存在物理机分配合理性不强及机器适配性不好的问题。
发明内容
有鉴于此,本申请的目的在于提供一种数据库资源管理方法、装置、资源管理设备及存储介质,其能够针对目标数据库实例分配合理的物理机,确保目标数据库实例能够在对应物理机的支持下达到良好的运维效果,提高物理机分配合理性及机器适配性。
为了实现上述目的,本申请实施例采用的技术方案如下:
第一方面,本申请实施例提供一种数据库资源管理方法,应用于数据库管理系统中的资源管理设备,其中所述数据库管理系统还包括多个物理机,所述方法包括:
获取数据库资源申请请求,其中所述数据库资源申请请求包括与目标数据库实例对应的内存需求量及磁盘空间需求量;
在数据库管理系统中筛选出剩余内存满足所述内存需求量且剩余磁盘空间满足所述磁盘空间需求量的待分配物理机;
根据每个待分配物理机的运行参数在筛选出的待分配物理机中,确定与所述目标数据库实例匹配的主物理机及从物理机;
在所述主物理机与所述从物理机上针对所述目标数据库实例进行资源分配。
在可选的实施方式中,所述运行参数包括对应物理机的CPU使用率、读写比例、QPS数值、负载大小及告警次数,所述资源管理设备存储有物理机初选模型及物理机次选模型,所述根据每个待分配物理机的运行参数在筛选出的待分配物理机中,确定与所述目标数据库实例匹配的主物理机及从物理机,包括:
按照从小到大的顺序分别对所有待分配物理机各自的CPU使用率、读写比例、QPS数值、负载大小及告警次数进行排序,得到多个物理机排序结果;
调用所述物理机初选模型从所有待分配物理机中筛选在每个物理机排序结果中的排名均处于第一预设排名范围的第一初选物理机;
若筛选出至少一个第一初选物理机,则在筛选出的第一初选物理机中选取一个物理机作为主物理机;
调用所述物理机次选模型在除去所述主物理机后的剩余第一初选物理机中筛选不与所述主物理机处于同一机架的第一次选物理机;
当筛选出至少一个第一次选物理机时,从筛选出的第一次选物理机中确定从物理机。
在可选的实施方式中,所述数据库资源申请请求还包括与所述目标数据库实例对应的实例访问高峰时段,所述在筛选出的第一初选物理机中选取一个物理机作为主物理机,包括:
根据每个第一初选物理机在所述实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第一初选物理机进行排序,得到对应的第一初选排序结果;
选取所述第一初选排序结果中排名第一的第一初选物理机作为所述主物理机。
在可选的实施方式中,所述数据库资源申请请求还包括与所述目标数据库实例对应的从库预创数目,所述从筛选出的第一次选物理机中确定从物理机,包括:
根据每个第一次选物理机在所述实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第一次选物理机进行排序,得到对应的第一次选排序结果;
选取所述第一次选排序结果中排名不大于所述从库预创数目的所有第一次选物理机作为所述从物理机。
在可选的实施方式中,所述根据每个待分配物理机的运行参数在筛选出的待分配物理机中,确定与所述目标数据库实例匹配的主物理机及从物理机,还包括:
当无法筛选出第一次选物理机时,调用所述物理机次选模型从所有待分配物理机中筛选出不与所述主物理机处于同一机架并在与CPU使用率及读写比例对应的物理机排序结果中的排名均处于第一预设排名范围的第二次选物理机;
从筛选出的第二次选物理机中确定从物理机。
在可选的实施方式中,所述从筛选出的第二次选物理机中确定从物理机,包括:
根据每个第二次选物理机在实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第二次选物理机进行排序,得到对应的第二次选排序结果;
选取所述第二次选排序结果中排名不大于从库预创数目的所有第二次选物理机作为所述从物理机。
在可选的实施方式中,所述根据每个待分配物理机的运行参数在筛选出的待分配物理机中,确定与所述目标数据库实例匹配的主物理机及从物理机,还包括:
若无法筛选出第一初选物理机,则调用所述物理机初选模型从所有待分配物理机中筛选在与CPU使用率及读写比例对应的物理机排序结果中的排名均处于第二预设排名范围的第二初选物理机,其中所述第二预设排名范围包含所述第一预设排名范围;
在筛选出的第二初选物理机中选取一个物理机作为主物理机;
调用所述物理机次选模型在除去所述主物理机后的剩余第二初选物理机中筛选不与所述主物理机处于同一机架的第三次选物理机;
从筛选出的第三次选物理机中确定从物理机。
在可选的实施方式中,所述在筛选出的第二初选物理机中选取一个物理机作为主物理机,包括:
根据每个第二初选物理机在实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第二初选物理机进行排序,得到对应的第二初选排序结果;
选取所述第二初选排序结果中排名第一的第二初选物理机作为所述主物理机。
在可选的实施方式中,所述从筛选出的第三次选物理机中确定从物理机,包括:
根据每个第三次选物理机在实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第三次选物理机进行排序,得到对应的第三次选排序结果;
选取所述第三次选排序结果中排名不大于从库预创数目的所有第三次选物理机作为所述从物理机。
第二方面,本申请实施例提供一种数据库资源管理装置,应用于数据库管理系统中的资源管理设备,其中所述数据库管理系统还包括多个物理机,所述装置包括:
资源请求获取模块,用于获取数据库资源申请请求,其中所述数据库资源申请请求包括与目标数据库实例对应的内存需求量及磁盘空间需求量;
物理机筛选模块,用于在数据库管理系统中筛选出剩余内存满足所述内存需求量且剩余磁盘空间满足所述磁盘空间需求量的待分配物理机;
主从机确定模块,用于根据每个待分配物理机的运行参数在筛选出的待分配物理机中,确定与所述目标数据库实例匹配的主物理机及从物理机;
机器资源处理模块,用于在所述主物理机与所述从物理机上针对所述目标数据库实例进行资源分配。
第三方面,本申请实施例提供一种资源管理设备,包括处理器和存储器,所述存储器存储有能够被所述处理器执行的机器可执行指令,所述处理器可执行所述机器可执行指令,以实现前述实施方式所述的数据库资源管理方法。
第四方面,本申请实施例提供一种存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时,实现前述实施方式所述的数据库资源管理方法。
相对于背景技术而言,本申请具有以下有益效果:
本申请在获取到数据库资源申请请求时,会根据该数据库资源申请请求所包括的与目标数据库实例对应的内存需求量及磁盘空间需求量,筛选出满足内存需求量及磁盘空间需求量的待分配物理机,而后根据每个待分配物理机的运行参数进行多维度地考虑,从所有待分配物理机中确定出与目标数据库实例匹配的主物理机及从物理机,进而在主物理机上分配足够资源创建该目标数据库实例所对应的主数据库,并在从物理机上分配足够资源创建该目标数据库实例所对应的从数据库,确保目标数据库实例能够在对应物理机的支持下达到良好的运维效果,提高了物理机分配合理性及机器适配性。
为使本申请的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1为本申请实施例提供的数据库管理系统的系统组成示意图;
图2为本申请实施例提供的资源管理设备的结构组成示意图;
图3为本申请实施例提供的数据库资源管理方法的流程示意图;
图4为图3中的步骤S230包括的子步骤的流程示意图之一;
图5为图3中的步骤S230包括的子步骤的流程示意图之二;
图6为图3中的步骤S230包括的子步骤的流程示意图之三;
图7为本申请实施例提供的数据库资源管理装置的功能模块示意图。
图标:10-数据库管理系统;11-资源管理设备;12-物理机;111-存储器;112-处理器;113-通信单元;100-数据库资源管理装置;110-资源请求获取模块;120-物理机筛选模块;130-主从机确定模块;140-机器资源处理模块。
具体实施方式
下面将结合本申请实施例中附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。
因此,以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围,而是仅仅表示本申请的选定实施例。基于本申请的实施例,本领域技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本申请保护的范围。
需要说明的是,术语“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
下面结合附图,对本申请的一些实施方式作详细说明。在不冲突的情况下,下述的实施例及实施例中的特征可以相互组合。
请参照图1,图1是本申请实施例提供的数据库管理系统10的系统组成示意图。在本申请实施例中,所述数据库管理系统10用于实现对数据库的创建管理、资源分配、运维管理等管理操作,其中所述数据库管理系统10包括资源管理设备11及多个物理机12,所述资源管理设备11与多个物理机12通信连接,用于获取每个物理机12向自身承载的数据库提供的资源支持状况,并根据各物理机12的资源支持状况为新数据库实例分配资源合适且运行性能匹配的物理机12进行相关的数据库创建及运维操作,其中每个物理机12可用于承载多个数据库。所述资源管理设备11可通过网络与用户所使用的终端设备通信连接,以获取用户需要创建的数据库实例的运维要求信息,其中所述运维要求信息包括对应数据库实例在运维时所需的物理资源大小、机器运行条件以及被访问高峰时段信息等。所述资源管理设备11与所述物理机12可以是,但不限于,服务器及个人计算机等;所述终端设备可以是,但不限于,平板电脑及个人计算机等。
可选地,请参照图2,图2是本申请实施例提供的资源管理设备11的结构组成示意图。在本申请实施例中,所述资源管理设备11包括数据库资源管理装置100、存储器111、处理器112及通信单元113。所述存储器111、所述处理器112及所述通信单元113各个元件相互之间直接或间接地电性连接,以实现数据的传输或交互。例如,所述存储器111、所述处理器112及所述通信单元113这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。
在本实施例中,所述存储器111可用于存储应用程序,所述处理器112在接收到执行指令后,可相应地执行对应的应用程序。其中,所述存储器111可以是,但不限于,随机存取存储器(Random
Access Memory,RAM),只读存储器(Read Only Memory,ROM),可编程只读存储器(Programmable
Read-Only Memory,PROM),可擦除只读存储器(ErasableProgrammable Read-Only
Memory,EPROM),电可擦除只读存储器(Electric ErasableProgrammable Read-Only
Memory,EEPROM)等。
在本实施例中,所述处理器112可以是一种具有信号的处理能力的集成电路芯片。所述处理器112可以是通用处理器,包括中央处理器(Central
Processing Unit,CPU)及网络处理器(Network
Processor,NP)等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等,可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。
在本实施例中,所述通信单元113用于通过网络建立所述资源管理设备11与其他终端设备之间的通信连接,并通过该网络收发数据。例如,所述资源管理设备11通过该通信单元113与各物理机12通信连接,并从各物理机12处获取其对应的物理资源利用状况。
在本实施例中,所述数据库资源管理装置100包括至少一个能够以软件或固件的形式存储于所述存储器111中或固化在所述资源管理设备11的操作系统中的软件功能模块。所述处理器112可用于执行所述存储器111存储的可执行模块,例如所述数据库资源管理装置100所包括的软件功能模块及计算机程序等。所述资源管理设备11通过所述数据库资源管理装置100为需要创建及运维的目标数据库实例分配资源合适且运行性能匹配的物理机12,确保目标数据库实例能在对应物理机12的支持下达到良好的运维效果,提高物理机分配合理性及机器适配性。
可以理解的是,图1所示的结构组成示意图仅为资源管理设备11的一种示意图,所述资源管理设备11还可包括比图1中所示更多或更少的组件,或具有与图1所示不同的配置。图1中所示的各组件可以采用硬件、软件或其组合实现。
在本申请中,为确保所述资源管理设备11能够针对需要创建的数据库实例分配资源合适且运行性能匹配的物理机12,确保数据库实例能在对应物理机12的支持下达到良好的运维效果,提高物理机分配合理性及机器适配性,本申请通过提供应用于上述资源管理设备11的数据库资源管理方法实现上述功能。下面对本申请提供的数据库资源管理方法进行相应描述。
可选地,请参照图3,图3是本申请实施例提供的数据库资源管理方法的流程示意图。在本申请实施例中,图3所示的数据库资源管理方法的具体流程和步骤如下文所示。
步骤S210,获取数据库资源申请请求,其中数据库资源申请请求包括与目标数据库实例对应的内存需求量及磁盘空间需求量。
在本实施例中,用户可用过终端设备向所述资源管理设备11上传针对其需要创建的目标数据库实例的数据库资源申请请求,使资源管理设备11根据该数据库资源申请请求所包括的目标数据库实例的内存需求量及磁盘空间需求量,选取合适的物理机12作为所述目标数据库实例的承载体。
步骤S220,在数据库管理系统中筛选出剩余内存满足内存需求量且剩余磁盘空间满足磁盘空间需求量的待分配物理机。
在本实施例中,所述资源管理设备11会通过网络统计所述数据库管理系统10下每个物理机12的总内存大小及总磁盘空间大小,以及每个物理机12针对自身已承载的数据库所分配的已分配内存大小及已分配磁盘空间大小,从而通过将同一物理机12的总内存大小与已分配内存大小进行减法运算,并将同一物理机12的总磁盘空间大小与已分配磁盘空间大小进行减法运算,得到各物理机12的剩余内存大小及剩余磁盘空间大小。而后,所述资源管理设备11通过将各物理机12的剩余内存大小与所述内存需求量进行比较,并将各物理机12的剩余磁盘空间大小与所述磁盘空间需求量进行比较,从而将所述数据库管理系统10中的剩余内存大小不小于所述内存需求量且剩余磁盘空间大小不小于所述磁盘空间需求量的物理机12,作为所述数据库管理系统10中的初步满足所述目标数据库实例的运维条件的待分配物理机12。
步骤S230,根据每个待分配物理机的运行参数在筛选出的待分配物理机中,确定与目标数据库实例匹配的主物理机及从物理机。
在本实施例中,所述运行参数包括对应物理机12的CPU使用率、读写比例、QPS(Queries-Per-Second,每秒查询率)数值、负载大小及告警次数。所述CPU使用率用于表示对应物理机12的CPU在预设时间段内的运行状况,其数值可由所述资源管理设备11通过对CPU运行状况进行正态分布分析得到,其中CPU使用率的数值越高,则表明CPU使用越频繁。所述读写比例用于表示对应物理机12在一定时间段内的数据读取状况与数据写入状况之间的态势比例,其数值可由所述资源管理设备11根据对应物理机12的IO(Input-Output,输入-输出)接口的使用状况针对数据读取方面及数据写入方面进行独立分析得到。所述QPS数值用于表示对应物理机12上的所有数据库在被访问查询时的整体数据查询能力,其数值可由所述资源管理设备11对物理机12上已分配的数据库的QPS数值进行数值统计操作及数值加法运算得到,其数值越大,则可表明该物理机12的剩余机器资源越少。所述负载大小用于表示对应物理机12在过去一段时间内的数据承载量大小,其数值越大,则表明对应物理机12的数据负载压力越大。所述告警次数用于表示对应物理机12在过去一段时间内的告警状况,其数值越大,则表明对应物理机12的设备运行稳定性越差。
所述资源管理设备11在筛选出初步满足所述目标数据库实例的运维条件的待分配物理机12后,会根据获取到的每个待分配物理机12针对已承载数据库的资源支持状况,确定出每个待分配物理机12的CPU使用率、读写比例、QPS数值、负载大小及告警次数,并针对这些待分配物理机12的CPU使用率、读写比例、QPS数值、负载大小及告警次数进行多维度地考虑,进而从筛选出的所有待分配物理机12中确定出机器资源合适的能够构建与目标数据库实例匹配的数据库的主物理机12和从物理机12,避免造成机器资源浪费或硬件资源限制的现象。其中,所述主物理机12用于构建目标数据库实例所对应的起主要运维作用的主数据库,所述从物理机12用于构建目标数据库实例所对应的起备用作用的从数据库。
步骤S240,在主物理机与从物理机均针对目标数据库实例进行资源分配。
在本实施例中,当所述资源管理设备11确定出机器资源与目标数据库实例匹配的主物理机12及从物理机12后,会在所述主物理机12上分配与该目标数据库实例的内存需求量及磁盘空间需求量对应的机器资源给该目标数据库实例,而后在所述主物理机12上利用被分配的机器资源构建该目标数据库实例所对应的主数据库,同时也会在所述从物理机12上分配与该目标数据库实例的内存需求量及磁盘空间需求量对应的机器资源给该目标数据库实例,并在所述从物理机12上利用被分配的机器资源构建该目标数据库实例所对应的从数据库。
在本申请中,所述资源管理设备11通过执行上述的数据库资源管理方法为新数据库实例分配机器资源合适的物理机12,使该数据库实例能够在对应物理机12的支持下达到良好的运维效果,提高了物理机分配合理性及机器适配性。
在本申请中,为确保所述资源管理设备11能够针对目标数据库实例进行多维度的物理机分配考虑,使分配的物理机12的运行状况与目标数据库实例真实匹配,避免出现机器资源浪费或硬件资源限制,本申请通过提供一种主从物理机确定方案实现上述功能。下面对本申请提供的主从物理机确定方案进行相应描述。
可选地,请参照图4,图4是图3中的步骤S230包括的子步骤的流程示意图之一。在本实施例中,所述资源管理设备11上存储有物理机初选模型及物理机次选模型,其中所述物理机初选模型用于在待分配物理机12中筛选能够参与主物理机确定操作的候选物理机12,所述物理机次选模型用于在待分配物理机12中筛选能够参与从物理机确定操作的候选物理机12,此时步骤S230可以包括子步骤S231~子步骤S235。
子步骤S231,按照从小到大的顺序分别对所有待分配物理机各自的CPU使用率、读写比例、QPS数值、负载大小及告警次数进行排序,得到多个物理机排序结果。
在本实施例中,当所述资源管理设备11确定出与目标数据库实例对应的所有待分配物理机12后,会对各待分配物理机12的处于同一运行参数种类的具体数值按照从小到大的顺序进行排序,得到多个物理机排序结果,其中CPU使用率、读写比例、QPS数值、负载大小及告警次数等5项运行参数种类各自对应一个物理机排序结果。其中,同一待分配物理机12在不同物理机排序结果中的排名结果可以相同,也可以不同。例如,假设与目标数据库实例对应的待分配物理机12包括图1所示的物理机A、物理机B及物理机C,物理机A、物理机B及物理机C在与CPU使用率对应的物理机排序结果中的排名可以分别为1、2、5,物理机A、物理机B及物理机C在与读写比例对应的物理机排序结果中的排名可以分别为3、2、4,物理机A、物理机B及物理机C在与QPS数值对应的物理机排序结果中的排名可以分别为2、3、5,物理机A、物理机B及物理机C在与负载大小对应的物理机排序结果中的排名可以分别为2、4、6,物理机A、物理机B及物理机C在与告警次数对应的物理机排序结果中的排名可以分别为5、7、10。
子步骤S232,调用物理机初选模型从所有待分配物理机中筛选在每个物理机排序结果中的排名均处于第一预设排名范围的第一初选物理机。
在本实施例中,所述第一预设排名范围的排名上限值通常被设置为不大于筛选出的待分配物理机12的数目的数值,但也可固定设置为某个特定数值,同时也可将所述第一预设排名范围的排名下限值设置为某个固定数值(比如1或2)。以筛选出的待分配物理机12的数目为15为例,所述第一预设排名范围可以是1~10,也可以是2~9。
所述资源管理设备11在确定出与待分配物理机12相关的多个物理机排序结果后,会通过调用所述物理机初选模型检测各项运行参数所对应的物理机排序结果中是否存在对应排名处于所述第一预设排名范围内的同一物理机12,进而筛选出在所有物理机排序结果中的排名均处于第一预设排名范围内的第一初选物理机12,作为参与主物理机确定操作的候选物理机12。
子步骤S233,若筛选出至少一个第一初选物理机,则在筛选出的第一初选物理机中选取一个物理机作为主物理机。
在本实施例中,通过调用所述物理机初选模型在待分配物理机12中筛选第一初选物理机12的操作可能造成两种结果,一种是能够筛选出至少一个第一初选物理机12,另一种就是无法筛选出任何一个第一初选物理机12。而当筛选出至少一个第一初选物理机12时,所述资源管理设备11可直接从筛选出的第一初选物理机12中选取任意一个第一初选物理机12作为与目标数据库实例匹配的主物理机12。同时,所述资源管理设备11也可按照某种规则对筛选出的第一初选物理机12进行契合度排序,从而根据排序结果确定出与目标数据库实例契合度最高的第一初选物理机12作为所述主物理机12。
可选地,在本实施例的一种实施方式中,所述数据库资源申请请求还包括用户针对所述目标数据库实例配置的实例访问高峰时段,为确保所述资源管理设备11选取出的主物理机12之前的使用高峰时段与所述实例访问高峰时段错开,保证所述目标数据库实例在主物理机12上运维时得以实现错峰访问,所述资源管理设备11将根据每个第一初选物理机12在所述实例访问高峰时段内的过往访问状况确定出与该目标数据库实例错峰访问的主物理机12。此时所述在筛选出的第一初选物理机12中选取一个物理机12作为主物理机12,包括:
根据每个第一初选物理机12在所述实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第一初选物理机12进行排序,得到对应的第一初选排序结果;
选取第一初选排序结果中排名第一的第一初选物理机12作为主物理机12。
其中,所述资源管理设备11可通过执行上述实施方式,保证目标数据库实例在选取的主物理机12上运维时,能够实现错峰访问,增强目标数据库实例在对应主物理机12上的访问便捷性,避免出现实例访问拥堵现象。
子步骤S234,调用物理机次选模型在除去主物理机后的剩余第一初选物理机中筛选不与主物理机处于同一机架的第一次选物理机。
在本实施例中,所述资源管理设备11在从第一初选物理机12中确定出主物理机12后,会按照主从数据库应不处于同一机架的原则,通过调用物理机次选模型在所有第一初选物理机12中剔除所述主物理机12及与所述主物理机12处于同一机架的物理机12,并将剩余的第一初选物理机12作为第一次选物理机12(参与从物理机确定操作的候选物理机12),以确保从第一次选物理机12中选取从物理机12不会在主物理机12所在机架掉电时也跟着掉电,从物理机12上的从数据库能够替换主物理机12上的主数据库投入使用。
子步骤S235,当筛选出至少一个第一次选物理机时,从筛选出的第一次选物理机中确定从物理机。
在本实施例中,通过调用所述物理机次选模型在第一初选物理机12中筛选第一次选物理机12的操作可能造成两种结果,一种是能够筛选出至少一个第一次选物理机12,另一种就是无法筛选出任何一个第一次选物理机12。而当筛选出至少一个第一次选物理机12时,所述资源管理设备11可直接从筛选出的第一次选物理机12中,选取数目与用户针对目标数据库实例设定的从数据库数目匹配的至少一个第一次选物理机12,作为与目标数据库实例匹配的从物理机12。同时,所述资源管理设备11也可按照某种规则对筛选出的第一次选物理机12进行契合度排序,从而根据排序结果确定出与目标数据库实例契合度排名高的至少一个第一次选物理机12作为从物理机12。
可选地,在本实施例的一种实施方式中,所述数据库资源申请请求除了实例访问高峰时段,还包括用户针对所述目标数据库实例配置的用于表示从数据库的构建数目的从库预创数目,为确保所述资源管理设备11选取出的从物理机12的数目尽量满足用户需求,并确保被选取的从物理机12之前的使用高峰时段也与所述实例访问高峰时段错开,保证所述目标数据库实例在从物理机12上运维时也能实现错峰访问,所述资源管理设备11将根据每个第一次选物理机12在所述实例访问高峰时段内的过往访问状况,确定出与该目标数据库实例错峰访问的尽量满足从库预创数目的至少一个从物理机12。此时所述在筛选出的第一次选物理机12中确定从物理机12,包括:
根据每个第一次选物理机12在实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第一次选物理机12进行排序,得到对应的第一次选排序结果;
选取第一次选排序结果中排名不大于从库预创数目的所有第一次选物理机12作为从物理机12。
其中,被选取的第一次选物理机12的数量通常情况下与所述从库预创数目保持一致,使每个被选取的第一次选物理机12上各自构建一个从数据库,保证同一物理机12上不构建相同的数据库,避免物理机12掉电时会有多个数据库同时掉线。而倘若第一次选排序结果所涉及的第一次选物理机12的数目小于从库预创数目,所述资源管理设备11会将所述第一次选排序结果所涉及的所有第一次选物理机12作为从物理机12,并仍坚持在每个物理机12上不构建相同数据库的原则进行从数据库的创建。当然可以理解的是,所述资源管理设备11也可为保证创建出的从数据库的数目满足从库预设数目,而在某些从物理机12上创建多个从数据库,使每个从物理机12上针对同一数据库实例创建有至少一个从数据库。所述资源管理设备11可通过执行上述实施方式,保证目标数据库实例在选取的从物理机12上运维时,能够实现错峰访问,增强目标数据库实例在对应从物理机12上的访问便捷性,避免出现实例访问拥堵现象。
在本申请实施例中,所述资源管理设备11可通过执行子步骤S231~子步骤S235的方式,确保被选定的主物理机12和从物理机12与目标数据库实例的资源匹配度最高,避免出现机器资源浪费或硬件资源限制的现象。
可选地,请参照图5,图5是图3中的步骤S230包括的子步骤的流程示意图之二。在本实施例中,当所述资源管理设备11通过调用物理机次选模型执行子步骤S234所得到的结果为无法筛选出第一次选物理机12时,所述步骤S230还可以包括子步骤S236~子步骤S237,以确保所述资源管理设备11能够通过调用物理机次选模型找到资源与目标数据库实例匹配的从物理机12。其中,通过子步骤S236~子步骤S237确定出的从物理机12与目标数据库实例的资源匹配度,通常低于通过子步骤S234~子步骤S235确定出的从物理机12与目标数据库实例的资源匹配度。
子步骤S236,当无法筛选出第一次选物理机时,调用物理机次选模型从所有待分配物理机中筛选出不与主物理机处于同一机架并在与CPU使用率及读写比例对应的物理机排序结果中的排名均处于第一预设排名范围的第二次选物理机。
在本实施例中,当所述资源管理设备11执行在筛选出的第一初选物理机12中筛选第一次选物理机12的操作所得到的结果为无法筛选出任何一个第一次选物理机12时,可以表明筛选出的第一初选物理机12无法提供目标数据库实例的从数据库载体,此时所述资源管理设备11需要调用物理机次选模型从待分配物理机12中筛选合适的物理机12来参与从物理机12的确定操作。为此,所述资源管理设备11将通过调用物理机次选模型先确定出在与CPU使用率及读写比例对应的物理机排序结果中的排名均处于第一预设排名范围的特殊物理机12,而后在确定出的特殊物理机12中筛选出不与已确定好的主物理机12处于同一机架的物理机12,作为本次参与从物理机确定操作的候选物理机12的第二次选物理机12。
其中,CPU使用率与读写比例为对数据库运维管理的影响程度最大的两项运行参数种类,上述特殊物理机12的筛选条件比第一初选物理机12的筛选条件简单很多,必定导致筛选出的特殊物理机12的数目是不小于第一初选物理机12的数目。所述资源管理设备11在无法筛选出第一次选物理机12的情况下执行确定第二次选物理机12的操作,必定能够确定出一定数目的第二次选物理机12,同时也能通过第二次选物理机12在一定程度上确保最终确定的从物理机12能够提供与目标数据库实例匹配的机器资源。
子步骤S237,从筛选出的第二次选物理机中确定从物理机。
在本实施例中,所述资源管理设备11执行所述子步骤S237的操作与上述子步骤S235的操作类似,可直接从筛选出的第二次选物理机12中,选取数目与用户针对目标数据库实例设定的从数据库数目匹配的至少一个第二次选物理机12,作为与目标数据库实例匹配的从物理机12。同时,所述资源管理设备11也可按照某种规则对筛选出的第二次选物理机12进行契合度排序,从而根据排序结果确定出与目标数据库实例契合度排名高的至少一个第二次选物理机12作为从物理机12。
可选地,在本实施例的一种实施方式中,为确保所述资源管理设备11从第二次选物理机12中选取出的从物理机12的数目尽量满足用户需求,并确保被选取的从物理机12之前的使用高峰时段也与实例访问高峰时段错开,保证所述目标数据库实例在从物理机12上运维时实现错峰访问,所述资源管理设备11将根据每个第二次选物理机12在所述实例访问高峰时段内的过往访问状况,确定出与该目标数据库实例错峰访问的尽量满足从库预创数目的至少一个从物理机12。此时所述在筛选出的第二次选物理机12中确定从物理机12,包括:
根据每个第二次选物理机12在实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第二次选物理机12进行排序,得到对应的第二次选排序结果;
选取第二次选排序结果中排名不大于从库预创数目的所有第二次选物理机12作为从物理机12。
其中,被选取的第二次选物理机12的数量通常情况下与所述从库预创数目保持一致,使每个被选取的第二次选物理机12上各自构建一个从数据库,保证同一物理机12上不构建相同的数据库,避免物理机12掉电时会有多个数据库同时掉线。而倘若第二次选排序结果所涉及的第二次选物理机12的数目小于从库预创数目,所述资源管理设备11会将所述第二次选排序结果所涉及的所有第二次选物理机12作为从物理机12,并仍坚持在每个物理机12上不构建相同数据库的原则进行从数据库的创建。当然可以理解的是,所述资源管理设备11也可为保证创建出的从数据库的数目满足从库预设数目,而在某些从物理机12上创建多个从数据库,使每个从物理机12上针对同一数据库实例创建有至少一个从数据库。所述资源管理设备11可通过执行上述实施方式,保证目标数据库实例在选取的从物理机12上运维时,能够实现错峰访问,增强目标数据库实例在对应从物理机12上的访问便捷性,避免出现实例访问拥堵现象。
在本申请实施例中,所述资源管理设备11在无法执行图4中的子步骤S235的情况下,可通过执行图5所示的子步骤S236~子步骤S237,以确保被选定的从物理机12也具有较高的与目标数据库实例对应的资源匹配度,避免出现机器资源浪费或硬件资源限制的现象。
可选地,请参照图6,图6是图3中的步骤S230包括的子步骤的流程示意图之三。在本实施例中,当所述资源管理设备11通过调用物理机初选模型执行子步骤S232所得到的结果为无法筛选出第一初选物理机12时,所述步骤S230还可以包括子步骤S238~子步骤S2311,以确保所述资源管理设备11能够找到资源与目标数据库实例匹配的主物理机12及从物理机12。其中,通过子步骤S238~子步骤S2311确定出的主物理机12及从物理机12与目标数据库实例的资源匹配度,通常低于通过子步骤S232~子步骤S235确定出的主物理机12及从物理机12与目标数据库实例的资源匹配度。
子步骤S238,若无法筛选出第一初选物理机,则调用物理机初选模型从所有待分配物理机中筛选在与CPU使用率及读写比例对应的物理机排序结果中的排名均处于第二预设排名范围的第二初选物理机。
在本实施例中,所述第二预设排名范围包含所述第一预设排名范围,所述第二预设排名范围的排名下限值不大于所述第一预设排名范围的排名下限值,所述第二预设排名范围的排名上限值不小于所述第一预设排名范围的排名上限值,通常可将所述第二预设排名范围的排名下限值设置为1。以筛选出的待分配物理机12的数目为15为例,当所述第一预设排名范围是1~10或2~9时,所述第二预设排名范围可以是1~11或1~15。
因此,第二初选物理机12的筛选条件比第一初选物理机12的筛选条件简单很多,必定导致第二初选物理机12是能够筛选出的,所述资源管理设备11可通过调用物理机初选模型筛选第二初选物理机12,确保最终的主物理机12与从物理机12能够提供与目标数据库实例匹配的机器资源。
子步骤S239,在筛选出的第二初选物理机中选取一个物理机作为主物理机。
在本实施例中,所述资源管理设备11可直接从筛选出的第二初选物理机12中选取任意一个第二初选物理机12作为与目标数据库实例匹配的主物理机12。同时,所述资源管理设备11也可按照某种规则对筛选出的第二初选物理机12进行契合度排序,从而根据排序结果确定出与目标数据库实例契合度最高的第二初选物理机12作为所述主物理机12。
可选地,在本实施例的一种实施方式中,为确保所述资源管理设备11从第二初选物理机12中选取出的主物理机12之前的使用高峰时段与所述实例访问高峰时段错开,保证所述目标数据库实例在主物理机12上运维时得以实现错峰访问,所述资源管理设备11将根据每个第二初选物理机12在所述实例访问高峰时段内的过往访问状况确定出与该目标数据库实例错峰访问的主物理机12。此时所述在筛选出的第二初选物理机12中选取一个物理机12作为主物理机12,包括:
根据每个第二初选物理机12在实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第二初选物理机12进行排序,得到对应的第二初选排序结果;
选取第二初选排序结果中排名第一的第二初选物理机12作为主物理机12。
其中,所述资源管理设备11可通过执行上述实施方式,保证目标数据库实例在选取的主物理机12上运维时,能够实现错峰访问,增强目标数据库实例在对应主物理机12上的访问便捷性,避免出现实例访问拥堵现象。
子步骤S2310,调用物理机次选模型在除去主物理机后的剩余第二初选物理机中筛选不与主物理机处于同一机架的第三次选物理机。
在本实施例中,所述资源管理设备11在从第二初选物理机12中确定出主物理机12后,会按照主从数据库应不处于同一机架的原则,通过调用物理机次选模型在所有第二初选物理机12中剔除所述主物理机12及与所述主物理机12处于同一机架的物理机12,并将剩余的第二初选物理机12作为第三次选物理机12(参与从物理机确定操作的候选物理机12),以确保从第三次选物理机12中选取的从物理机12不会在主物理机12所在机架掉电时也跟着掉电,从物理机12上的从数据库能够替换主物理机12上的主数据库投入使用。
子步骤S2311,从筛选出的第三次选物理机中确定从物理机。
在本实施例中,因第二初选物理机12的筛选条件比第一初选物理机12的筛选条件简单很多,必定导致第二初选物理机12是能够筛选出的,那么通常在第二初选物理机12也是能够筛选出第三次选物理机12的。此时所述资源管理设备11可直接从筛选出的第三次选物理机12中,选取数目与用户针对目标数据库实例设定的从数据库数目匹配的至少一个第三次选物理机12,作为与目标数据库实例匹配的从物理机12。同时,所述资源管理设备11也可按照某种规则对筛选出的第三次选物理机12进行契合度排序,从而根据排序结果确定出与目标数据库实例契合度排名高的至少一个第三次选物理机12作为从物理机12。
可选地,在本实施例的一种实施方式中,为确保所述资源管理设备11从第三次选物理机12中选取出的从物理机12的数目尽量满足用户需求,并确保被选取的从物理机12之前的使用高峰时段也与实例访问高峰时段错开,保证所述目标数据库实例在从物理机12上运维时也能实现错峰访问,所述资源管理设备11将根据每个第三次选物理机12在所述实例访问高峰时段内的过往访问状况,确定出与该目标数据库实例错峰访问的尽量满足从库预创数目的至少一个从物理机12。此时所述在筛选出的第三次选物理机12中确定从物理机12,包括:
根据每个第三次选物理机12在实例访问高峰时段内的历史访问频次,按照从低到高的顺序对所有第三次选物理机12进行排序,得到对应的第三次选排序结果;
选取第三次选排序结果中排名不大于从库预创数目的所有第三次选物理机12作为从物理机12。
其中,被选取的第三次选物理机12的数量通常情况下与所述从库预创数目保持一致,使每个被选取的第三次选物理机12上各自构建一个从数据库,保证同一物理机12上不构建相同的数据库,避免物理机12掉电时会有多个数据库同时掉线。而倘若第三次选排序结果所涉及的第三次选物理机12的数目小于从库预创数目,所述资源管理设备11会将所述第三次选排序结果所涉及的所有第三次选物理机12作为从物理机12,并仍坚持在每个物理机12上不构建相同数据库的原则进行从数据库的创建。当然可以理解的是,所述资源管理设备11也可为保证创建出的从数据库的数目满足从库预设数目,而在某些从物理机12上创建多个从数据库,使每个从物理机12上针对同一数据库实例创建有至少一个从数据库。所述资源管理设备11可通过执行上述实施方式,保证目标数据库实例在选取的从物理机12上运维时,能够实现错峰访问,增强目标数据库实例在对应从物理机12上的访问便捷性,避免出现实例访问拥堵现象。
在本申请实施例中,所述资源管理设备11在无法执行子步骤S233~子步骤S237的情况下,可通过执行图6所示的子步骤S236~子步骤S237,以确保被选定的主物理机12及从物理机12也具有较高的与目标数据库实例对应的资源匹配度,避免出现机器资源浪费或硬件资源限制的现象。
在本申请中,为确保图2所示的数据库资源管理方法能够在所述资源管理设备11上正常运行,本申请提供一种应用于上述资源管理设备11的数据库资源管理装置100实施图3所示的数据库资源管理方法,下面对本申请提供的数据库资源管理装置100的具体组成进行相应描述。
可选地,请参照图7,图7是本申请实施例提供的数据库资源管理装置100的功能模块示意图。在本申请实施例中,所述数据库资源管理装置100包括资源请求获取模块110、物理机筛选模块120、主从机确定模块130及机器资源处理模块140。
资源请求获取模块110,用于获取数据库资源申请请求,其中数据库资源申请请求包括与目标数据库实例对应的内存需求量及磁盘空间需求量。
物理机筛选模块120,用于在数据库管理系统中筛选出剩余内存满足内存需求量且剩余磁盘空间满足磁盘空间需求量的待分配物理机。
主从机确定模块130,用于根据每个待分配物理机的运行参数在筛选出的待分配物理机中,确定与目标数据库实例匹配的主物理机及从物理机。其中运行参数包括对应物理机的CPU使用率、读写比例、QPS数值、负载大小及告警次数。
机器资源处理模块140,用于在主物理机与从物理机上针对目标数据库实例进行资源分配。
需要说明的是,本申请提供的数据库资源管理装置100,其基本原理及产生的技术效果与上述的数据库资源管理方法相同,为简要描述,本实施例部分未提及之处,可参考上述的对图3所示的数据库资源管理方法的相应描述。
在本申请所提供的实施例中,应该理解到,所揭露的装置和方法,也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,附图中的流程图和框图显示了根据本申请的实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现方式中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
另外,在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分,也可以是各个模块单独存在,也可以两个或两个以上模块集成形成一个独立的部分。
所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时,可以存储在一个可读存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个可读存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的可读存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only
Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
综上所述,在本申请提供的一种数据库资源管理方法、装置、资源管理设备及存储介质中,本申请在获取到数据库资源申请请求时,会根据该数据库资源申请请求所包括的与目标数据库实例对应的内存需求量及磁盘空间需求量,筛选出满足内存需求量及磁盘空间需求量的待分配物理机,而后根据每个待分配物理机的CPU使用率、读写比例、QPS数值、负载大小及告警次数进行多维度地考虑,从所有待分配物理机中确定出与目标数据库实例匹配的主物理机及从物理机,进而在主物理机上分配足够资源创建该目标数据库实例所对应的主数据库,并在从物理机上分配足够资源创建该目标数据库实例所对应的从数据库,确保目标数据库实例能够在对应物理机的支持下达到良好的运维效果,提高了物理机分配合理性及机器适配性。
以上所述仅为本申请的优选实施例而已,并不用于限制本申请,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。
f
f
f
f
f
f
f
f
f
这个专利是由广州虎牙科技有限公司申请的,涉及一种数据库资源管理的方法、装置、资源管理设备以及存储介质。
该专利主要解决的是如何合理地分配物理机给数据库实例,以提高物理机的分配合理性和机器的适配性,从而确保数据库实例能在物理机的支持下达到良好的运维效果。
关键技术点概述:
1、资源申请处理:根据数据库实例的资源需求(内存和磁盘空间),筛选出满足需求的待分配物理机。
2、物理机选择策略:利用物理机初选模型和次选模型,基于物理机的运行参数(如CPU使用率、读写比例等),从待分配物理机中确定最适合的主物理机和从物理机。
3、资源分配:在确定的主物理机和从物理机上分配资源,创建相应的主数据库和从数据库。
实现优点:
优化资源利用率,减少资源浪费。
提高数据库系统的稳定性和响应速度。
根据物理机的实际运行状态动态调整资源分配,提升运维效果。
这个专利的技术方案为数据库资源管理提供了一种系统性的解决方法,通过智能化的物理机筛选和资源分配策略,有效提升了数据库服务的质量和效率。
1、专利概述:广州虎牙科技有限公司提交的专利,旨在通过优化物理机的分配来支持数据库实例
,确保数据库实例在物理机的支持下能够实现良好的运维效果,从而提高物理机分配的合理性和机器的适配性。
2、方法论:该方法接收数据库资源的申请请求,包括与目标数据库实例相对应的内存需求量和磁盘空间需求量。系统中将筛选出满足这些需求的待分配物理机,
并基于这些物理机的运行参数(如CPU使用率、读写比例、QPS数值、负载大小和告警次数),多维度考虑后,确定适合的主物理机和从物理机。
3、技术细节:专利详细描述了如何通过初选模型和次选模型,从所有待分配的物理机中筛选并确定最适合的主物理机和从物理机。这包括根据物理机的运行参数排序,
以及如何在不同的物理机之间进行选择,确保所选物理机的运维效果最优。
4、实施效果:该技术能够确保数据库实例按照需求得到足够的资源支持,优化资源的使用效率,提高数据库系统的稳定性和响应速度。
通过这种方法和设备,广州虎牙科技有限公司旨在解决现有技术中物理机分配不合理和机器适配性不佳的问题,实现数据库资源管理的优化。
51ak 搞的专利
关系型数据库同步到对外加密库
f
f
标签:12,Windows,Redis,数据库,加解密,DLL,所述,实例,物理 From: https://www.cnblogs.com/lyhabc/p/18161274