掌桥专利:专业的专利平台
掌桥专利
首页

业务请求处理方法、装置、设备及存储介质

文献发布时间:2024-04-18 20:01:23


业务请求处理方法、装置、设备及存储介质

技术领域

本申请涉及分布式数据存储技术领域,尤其涉及一种业务请求处理方法、装置、设备及存储介质。

背景技术

目前,随着互联网时代的到来,互联网在人们日常的学习、工作和生活中得到广泛的应用。人们日常的各种事务都可以通过互联网来处理和呈现。同时,随着移动互联网的快速发展,各互联网服务提供方(即业务服务提供方)通过开发各自的应用程序为用户提供相应的业务服务,用户可以根据各自的实际需求在智能终端设备(如智能手机)中安装相应的应用程序,例如,购物应用、视频应用、聊天应用、支付应用等等。

然而,随着某一应用程序的用户量越来越大,相应的业务数据量也随之激增,分布式数据存储的需求越来越高,例如,采用分库存储的方式,因此,需要将客户端的业务请求发送至相应的数据库节点。相关技术中采用分片键作为数据库节点的索引,通过从业务请求中获取目标分片键,再基于目标分片键确定业务请求对应的目标数据库节点,基于此,如何快速、有效地从业务请求中获取目标分片键,再基于目标分片键将业务请求转发至目标数据库节点为当前急需解决的问题之一。

发明内容

本申请实施例的目的是提供一种业务请求处理方法、装置、设备及存储介质,增设请求转发服务端,以及预先针对目标应用配置相应的分片键获取规则集合,这样基于分片键获取规则集合对业务请求进行解析,再基于解析结果即可获取所需的目标分片键,进一步的,基于目标分片键就可以确定出应该接收此次业务请求的目标数据库节点,提高目标分片键的获取准确度和灵活性。

为了实现上述技术方案,本申请实施例是这样实现的:

第一方面,本申请实施例提供的一种业务请求处理方法,应用于请求转发服务端,所述请求转发服务端与数据库节点集群之间通信连接,所述数据库节点集群包括多个预设应用分别对应的数据库节点子集,所述方法包括:

接收客户端的业务请求;所述业务请求是所述客户端基于目标用户对所述多个预设应用中目标应用的触发操作而发出的;

基于所述目标应用对应的分片键获取规则集合对所述业务请求进行解析处理,得到目标分片键;

基于所述目标分片键,从所述目标应用对应的数据库节点子集中确定目标数据库节点;

将所述业务请求转发至所述目标数据库节点;所述目标数据库节点用于根据所述业务请求进行数据存储或者数据查询。

第二方面,本申请实施例提供的一种业务请求处理装置,设置于请求转发服务端,所述请求转发服务端与数据库节点集群之间通信连接,所述数据库节点集群包括多个预设应用分别对应的数据库节点子集,所述装置包括:

接收单元,用于接收客户端的业务请求;所述业务请求是所述客户端基于目标用户对所述多个预设应用中目标应用的触发操作而发出的;

确定单元,用于基于所述目标应用对应的分片键获取规则集合对所述业务请求进行解析处理,得到目标分片键;

所述确定单元,还用于基于所述目标分片键,从所述目标应用对应的数据库节点子集中确定目标数据库节点;

转发单元,用于将所述业务请求转发至所述目标数据库节点;所述目标数据库节点用于根据所述业务请求进行数据存储或者数据查询。

第三方面,本申请实施例提供的一种业务请求处理设备,所述设备包括:

处理器;以及被安排成存储计算机可执行指令的存储器,所述可执行指令被配置由所述处理器执行,所述可执行指令包括用于执行如第一方面中所述的方法中的步骤。

第四方面,本申请实施例提供的一种存储介质,其中,所述存储介质用于存储计算机可执行指令,所述可执行指令使得计算机执行如第一方面中所述的方法中的步骤。

可以看出,在本申请实施例中,请求转发服务端在接收到客户端基于用户对目标应用的触发操作而发出的业务请求后,基于目标应用对应的分片键获取规则集合对业务请求进行解析,得到目标分片键;然后,基于目标分片键,从目标应用对应的数据库节点子集中确定目标数据库节点;再将业务请求转发至目标数据库节点,以使目标数据库节点根据业务请求进行数据存储或者数据查询;一方面,在客户端和数据库节点之间增设请求转发服务端,由请求转发服务端基于业务请求获取相应的目标分片键,这样目标应用对应的分片键获取规则集合仅需部署于请求转发服务端即可,无论是客户端还是数据库节点不仅不需要部署分片键获取规则,也省去了基于业务请求获取目标分片键的步骤,并且请求转发服务端能够对同一客户端上安装的多个预设应用的业务请求进行转发,也能够对不同客户端上安装的同一预设应用的业务请求进行转发;另一方面,通过预先针对每个预设应用配置相应的分片键获取规则集合,再基于分片键获取规则集合对业务请求进行解析,再基于解析结果即可获取所需的目标分片键,由于分片键获取规则集合中包含多个分片键获取规则且这多个分片键获取规则是有针对性地为某一预设应用所配置的,确保了分片键获取方式的多样性和针对性,这样在不需要结合具体业务数据识别待处理的业务请求的实际业务类型、或者无法获知待处理的业务请求的实际业务类型的情况下,也能够基于分片键获取集合中的某一分片键获取规则确定目标分片键,从而提高目标分片键的获取准确度和灵活性,进一步的,基于目标分片键就可以确定出应该接收此次业务请求的目标数据库节点,因此本申请能够提高目标数据库节点的确定准确度。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请一个或多个中记载的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动性的前提下,还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的业务请求处理系统的应用场景示意图;

图2为本申请实施例提供的业务请求处理方法的第一种流程示意图;

图3为本申请实施例提供的业务请求处理方法的第二种流程示意图;

图4为本申请实施例提供的业务请求处理方法的第一种实现原理示意图;

图5为本申请实施例提供的业务请求处理方法的第三种流程示意图;

图6为本申请实施例提供的业务请求处理方法的第二种实现原理示意图;

图7为本申请实施例提供的业务请求处理装置的模块组成示意图;

图8为本申请实施例提供的业务请求处理设备的结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请一个或多个中的技术方案,下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一个或多个一部分实施例,而不是全部的实施例。基于本申请一个或多个中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都应当属于本申请的保护范围。

需要说明的是,在不冲突的情况下,本申请中的一个或多个实施例以及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请实施例。

本申请一个或多个实施例提供了一种业务请求处理方法、装置、设备及存储介质,考虑到如果由数据库节点或者客户端执行为业务请求确定目标数据库节点的步骤,那么,需要在每个数据库节点或者每个客户端均部署分片键获取规则,这样不仅会增加数据库节点或者客户端的内存负担,还会增大数据库节点或者客户端的数据处理量,基于此,本技术方案在客户端和数据库节点之间增设请求转发服务端,由请求转发服务端基于业务请求获取相应的目标分片键,这样目标应用对应的分片键获取规则集合仅需部署于请求转发服务端即可,无论是客户端还是数据库节点不仅不需要部署分片键获取规则,也省去了基于业务请求获取目标分片键的步骤,并且请求转发服务端能够对同一客户端上安装的多个预设应用的业务请求进行转发,也能够对不同客户端上安装的同一预设应用的业务请求进行转发;又考虑到虽然在客户端和数据库节点之间增设请求转发服务端,但如果仅仅是预设几个常用的分片键查找方式,例如,从Http请求的Url中获取分片键,从Http请求的Header中获取分片键,从Http请求的Cookie中获取分片键,存在分片键获取方式灵活性差,无法兼容所有预设应用的情况,那么业务服务提供方为了确保请求转发服务端能够从业务请求中获取到分片键,业务服务提供方需要基于这些常用的分片键查找方式对请求接收接口和请求格式进行改造,使得业务请求中与分片键查找方式对应的字段位置携带有分片键,势必存在改造成本差,业务服务提供方使用体验差的问题,基于此,本技术方案通过预先针对每个预设应用配置相应的分片键获取规则集合,再基于分片键获取规则集合对业务请求进行解析,再基于解析结果即可获取所需的目标分片键,由于分片键获取规则集合中包含多个分片键获取规则,确保了分片键获取方式的多样性,这样在不需要结合具体业务数据识别待处理的业务请求的实际业务类型、或者无法获知待处理的业务请求的实际业务类型的情况下,也能够基于分片键获取集合中的某一分片键获取规则确定目标分片键,从而提高目标分片键的获取准确度和灵活性,进一步的,基于目标分片键就可以确定出应该接收此次业务请求的目标数据库节点,因此本申请能够提高目标数据库节点的确定准确度;并且每个分片键获取规则集合中的多个分片键获取规则均是基于某一预设应用的不同业务类型的请求接收接口的接口需求有针对性地配置的,这样无需业务服务提供方对请求接收接口和请求格式进行改造,请求转发服务端也能够同时兼容多个业务服务提供方的预设应用的业务请求转发服务。

图1为本申请实施例提供的业务请求处理系统的应用场景示意图,如图1所示,该系统包括:客户端、请求转发服务端和数据库节点集群,客户端安装有采用分库数据存储方式的N个预设应用,数据库节点集群包括N个预设应用分别对应的数据库节点子集,一个业务服务提供方可以开发一个预设应用,也可以开发M预设应用(M<N),某一业务服务提供方为各自开发的每个预设应用分配一定数量的数据库节点(即该预设应用对应的数据库节点子集),这样客户端针对目标应用的业务请求只能访问部分数据库资源(即需要将业务请求路由到基于目标分片键确定的目标数据库节点);另外,某一客户端可以安装N个预设应用中的全部应用,也可以仅安装部分应用;其中,该客户端可以是智能手机、平板电脑等移动终端,该客户端还可以是个人计算机等终端设备,该请求转发服务端可以是设置于数据库节点集群前端的网关服务器,该数据库节点集群中的每个数据库节点可以对应于一个数据库服务器,也可以是多个数据库节点对应于一个数据库服务器。其中,业务请求处理的具体过程为:

客户端,在检测到用户对多个预设应用中目标应用的触发操作之后,生成相应的业务请求,并将该业务请求发送至请求转发服务端;

请求转发服务端,在接收到客户端的业务请求之后,获取目标应用对应的分片键获取规则集合,并基于该分片键获取规则集合,对业务请求进行解析处理,得到目标分片键;

请求转发服务端,基于获取到的目标分片键,从目标应用对应的数据库节点子集中确定目标数据库节点;

另外,需要说明的是,考虑到上述采用分库数据存储方式的预设应用可以是第一类应用(即采用分库且表结构相同的数据存储方式,也即多个数据库节点中的数据库表结构相同),也可以是第二类应用(即采用分库且表结构不同的数据存储方式,也即多个数据库节点中的数据库表结构不同),而通常情况下,针对第二类应用而言,每个业务请求对应的目标数据库节点是预先设置的,只有第一类应用的业务请求可以基于目标分片键确定目标数据库节点,因此,在接收到客户端的业务请求之后,判断业务请求所针对的目标应用对应的数据存储方式是否为分库且表结构相同的数据存储方式;若是,则获取目标应用对应的分片键获取规则集合,并基于该分片键获取规则集合,对业务请求进行解析处理,得到目标分片键;若否,则按照预设映射关系确定目标数据库节点;也就是说,若已知上述N个预设应用的数据存储方式均为分库且表结构相同的数据存储方式,则无需判断目标应用对应的数据存储方式是否为分库且表结构相同的数据存储方式;若上述预设应用的类型包括第一类应用或者第二类应用(即对应的数据存储方式为分库且表结构相同的数据存储方式、或者分库且表结构不同的数据存储方式),则需要先判断目标应用对应的数据存储方式是否为分库且表结构相同的数据存储方式,再决定是否执行获取目标应用对应的分片键获取规则集合,并基于该分片键获取规则集合,对业务请求进行解析处理,得到目标分片键的步骤以及后续步骤。

请求转发服务端,将上述业务请求转发至目标数据库节点;

目标数据库节点,在接收到请求转发服务端转发的业务请求后,根据接收到的业务请求进行数据存储或者数据查询;

例如,在上述图1中,目标用户1的客户端基于目标用户1对预设应用1的触发操作向请求转发服务端发送业务请求1;请求转发服务端在接收到业务请求1后,获取预设应用1对应的分片键获取规则集合1,并基于分片键获取规则集合1确定业务请求1对应的目标分片键,再基于该目标分片键从预设应用1对应的数据库节点子集中确定目标数据库节点(如数据库节点i),并将业务请求1转发至相应的目标数据库节点(即数据库节点i);

类似地,目标用户2的客户端基于目标用户2对预设应用N的触发操作向请求转发服务端发送业务请求2;请求转发服务端在接收到业务请求2后,获取预设应用N对应的分片键获取规则集合N,并基于分片键获取规则集合N确定业务请求2对应的目标分片键,再基于该目标分片键从预设应用N对应的数据库节点子集中确定目标数据库节点(如数据库节点j),并将业务请求2转发至相应的目标数据库节点(即数据库节点j)。

图2为本申请一个或多个实施例提供的业务请求处理方法的第一种流程示意图,图2中的方法能够由图1中的请求转发服务端执行,如图2所示,该方法至少包括以下步骤:

S202,接收客户端的业务请求;其中,该业务请求是客户端基于目标用户对多个预设应用中目标应用的触发操作而发出的;

具体的,客户端在检测到目标用户对多个预设应用中目标应用的触发操作之后,生成相应的业务请求,并将该业务请求发送至请求转发服务端;例如,以目标应用为购物应用为例,目标用户对目标应用的触发操作可以是将某一待购买商品进行付款的触发操作,对应的,业务请求的业务类型为下单支付服务;又如,以目标应用为业务申请应用为例,目标用户对目标应用的触发操作可以是针对已申请业务的合同查看的触发操作,对应的,业务请求的业务类型为合同查看服务。

S204,基于目标应用对应的分片键获取规则集合对接收到的业务请求进行解析处理,得到该业务请求对应的目标分片键;

具体的,针对目标应用为单元化应用(即上述第一类应用)的情况,也即目标应用对应的数据存储方式为分库且表结构相同的数据存储方式,针对此类应用程序,将业务请求分配给哪个数据库节点通常是基于预设的分片键(如商品编号、有效证件编号等)来确定的,因此,需要确定业务请求对应的目标分片键;例如,通过对业务请求对应的目标分片键进行取模处理,根据取模数值的大小与数据库节点标识之间的对应关系,确定将业务请求分配给哪个数据库节点,如,基于目标分片键计算得到的取模数值为5,则可以将业务请求分配给序号为5的数据库节点。

其中,选择哪个业务数据作为用于确定数据库节点的分片键可以是预先设置的,例如,针对购物应用,可以将商品编号作为分片键,对应的,将订单编号作为与分片键具有预设映射关系的关联信息;又如,针对业务申请应用,可以将申请人的有效证件编号作为分片键,对应的,将合同编号作为与分片键具有预设映射关系的关联信息;而针对目标应用为非单元化应用的情况,可以直接将业务请求转发至相应的业务服务提供方。

具体的,针对采用数据分库存储方式的某一预设应用(如购物应用)而言,由于不同业务类型(如商品加购服务、下单支付服务等等)的业务请求的接口对业务请求格式的要求有所不同,使得属于不同业务类型的业务请求中携带的与分片键有关的字段所在位置也有所不同,例如,与分片键有关的字段所在位置可以是http header、Url参数、Url path路径、http body、http cookie中任一项,因此,需要针对不同业务类型,配置相应的分片键获取规则,以确保目标应用对应的分片键获取规则集合中的多个分片键获取规则包括与接收到的业务请求相对应的目标获取规则,这样在不需要结合具体业务数据识别待处理的业务请求的实际业务类型、或者无法获知待处理的业务请求的实际业务类型的情况下,也能够基于分片键获取集合中的某一分片键获取规则确定目标分片键,从而提高目标分片键的获取准确度和灵活性,进一步的,基于目标分片键就可以确定出应该接收此次业务请求的目标数据库节点,因此本申请能够提高目标数据库节点的确定准确度。

具体的,由于分片键获取规则集合中的多个分片键获取规则可以是预先根据实际需求灵活配置的,因此,目标分片键的获取方式是多样化的,例如,可以是直接地从业务请求中解析得到目标分片键,又如,也可以是间接地从业务请求中获取目标分片键,即先从业务请求中解析得到与目标分片键具有一定映射关系的关联信息,再基于关联信息和预存分片键映射关系确定目标分片键,再如,还可以是将预设兜底信息确定为目标分片键;并且由于在目标分片键的获取过程中,可以使用分片键获取规则集合中的多个分片键获取规则,因此,必然存在一个能够获取到业务请求对应的目标分片键的分片键获取规则,从而确保准确地将业务请求转发至目标数据库节点。

S206,基于上述目标分片键,从目标应用对应的数据库节点子集中确定目标数据库节点;

具体的,在获取到当前接收到的业务请求对应的目标分片键之后,对目标分片键进行取模计算,得到取模数值,或者对目标分片键进行哈希计算,得到哈希值,再将取模数值或者哈希值对应的数据库节点确定为目标数据库节点;例如,目标分片键为当前接收到的业务请求所针对的待购买商品的商品编号(如xxxxxx),对商品编号进行取模计算,得到取模数值(如5),则将目标应用对应的数据库节点子集中序号为5的数据库节点确定为目标数据库节点;又如,目标分片键为当前接收到的业务请求所针对的已申请业务合同的申请人的有效证件编号(如zzzzzz),对有效证件编号进行取模计算,得到取模数值(如3),则将目标应用对应的数据库节点子集中序号为3的数据库节点确定为目标数据库节点;其中,由于针对某一业务数据而言,数据查询阶段与数据存储阶段所使用的目标分片键是相同的,因此,数据查询阶段的业务请求对应的目标数据库节点与数据存储阶段的业务请求对应的目标业务数据库节点是相同的。

在具体实施时,针对基于目标分片键确定目标数据库节点的过程,为了提高目标数据库节点的确定效率,可以预先配置预设脚本引擎,具体的,以取模计算为例,上述步骤S206,具体包括:利用预设脚本引擎,对目标分片键中的部分字符或全部字符进行取模计算,得到取模数值;再将目标应用对应的数据库节点子集中,与取模数值对应的数据库节点确定为目标数据库节点。

具体的,可以对目标分片键中的全部字符进行取模计算,得到取模数值;也可以对目标分片键中的部分字符进行取模计算,得到取模数值,其中,利用预设脚本引擎(如表达式引擎Aviator),从目标分片键中提取一定数量的字符串,再对该字符串进行取模计算,得到取模数值,例如,仍以目标分片键为当前接收到的业务请求所针对的待购买商品的商品编号(如yyyyyy)为例,可以从商品编号中提取后四位字符,再对后四位字符进行取模计算,得到取模数值(如7),则将目标应用对应的数据库节点子集中序号为7的数据库节点确定为目标数据库节点。

S208,将上述业务请求转发至目标数据库节点;其中,目标数据库节点用于根据上述业务请求进行数据存储或者数据查询。

具体的,在确定出目标数据库节点之后,由请求转发服务端直接将当前接收到的业务请求转发至目标数据库节点,这样目标数据库节点在接收到该业务请求后,根据接收到的业务请求进行数据存储或者数据查询;例如,业务请求为下单支付请求,目标数据库节点存储业务请求所针对的商品订单信息,又如,业务请求为合同查看请求,目标数据库节点查询业务请求所针对的业务申请合同信息。

在本申请实施例中,一方面,在客户端和数据库节点之间增设请求转发服务端,由请求转发服务端基于业务请求获取相应的目标分片键,这样目标应用对应的分片键获取规则集合仅需部署于请求转发服务端即可,无论是客户端还是数据库节点不仅不需要部署分片键获取规则,也省去了基于业务请求获取目标分片键的步骤,并且请求转发服务端能够对同一客户端上安装的多个预设应用的业务请求进行转发,也能够对不同客户端上安装的同一预设应用的业务请求进行转发;另一方面,通过预先针对每个预设应用配置相应的分片键获取规则集合,再基于分片键获取规则集合对业务请求进行解析,再基于解析结果即可获取所需的目标分片键,由于分片键获取规则集合中包含多个分片键获取规则且这多个分片键获取规则是有针对性地为某一预设应用所配置的,确保了分片键获取方式的多样性和针对性,这样在不需要结合具体业务数据识别待处理的业务请求的实际业务类型、或者无法获知待处理的业务请求的实际业务类型的情况下,也能够基于分片键获取集合中的某一分片键获取规则确定目标分片键,从而提高目标分片键的获取准确度和灵活性,进一步的,基于目标分片键就可以确定出应该接收此次业务请求的目标数据库节点,因此本申请能够提高目标数据库节点的确定准确度。

进一步地,为了提高请求转发服务端的适用性和可扩展性,确保能够同时兼容多个预设应用的业务请求的转发服务,预先分别针对每个预设应用有针对性地配置分片键获取规则集合,其中,针对各预设应用分别对应的分片键获取规则集合的配置过程,如图3所示,在上述步骤S202,接收客户端的业务请求之前,还包括:

S210,针对每个预设应用,获取该预设应用所提供的每个业务类型对应的接口需求信息;其中,上述接口需求信息包括表征业务请求是否包含分片键的第一格式要求信息、以及表征与分片键有关的字段所在位置的第二格式要求信息;

具体的,由于针对某一预设应用而言,不同业务类型对应的请求接收接口对业务请求的格式要求有所不同,使得属于不同业务类型的业务请求中携带的与分片键有关的字段所在位置也有所不同,因此,需要结合业务类型对应的接口需求信息配置相应的分片键获取规则,以确保基于预设应用对应的分片键获取规则集合中的某一分片键获取规则能够获取业务请求对应的目标分片键。

S212,基于上述接口需求信息中的第一格式要求信息和第二格式要求信息,为预设应用所提供的每个业务类型配置相应的分片键获取规则;在具体实施时,为了后续便于基于预设历史时间段内所使用的分片键获取规则,预测待处理的业务请求对应的至少一个候选业务类型,在分片键获取规则的配置过程中,可以记录业务类型与分片键获取规则之间的类型规则对应关系;这样基于该对应关系,即可确定预设历史时间段内所使用的分片键获取规则对应的历史业务请求的业务类型。

其中,上述分片键获取规则用于对属于某一相应业务类型的业务请求进行解析得到与分片键有关的字段,具体的,解析得到的目标信息(即与分片键有关的字段)可以是分片键本身,另外,为了支持业务请求中不直接携带分片键的情况,因此,解析得到的目标信息也可以是与分片键具有映射关系的关联信息,再基于关联信息和预存分片键映射关系,转换得到目标分片键;例如,商品编号为预先定义的分片键字段,而解析得到的目标信息为订单编号,因此,可以基于订单编号转换为商品编号,这样在业务请求中不携带商品编号的情况下,也能够自动确定业务请求对应的目标分片键。

具体的,针对不同业务类型配置相应的分片键获取规则,例如,业务请求为商品查询,对应的业务类型为商品查询服务,基于商品查询服务对应的请求接收接口的第一格式要求信息和第二格式要求信息,配置相应的分片键获取规则A,又如,业务请求为订单支付,对应的业务类型为订单支付服务,基于订单支付服务对应的请求接收接口的第一格式要求信息和第二格式要求信息,配置相应的分片键获取规则B;这样在业务请求转发的过程中,如果接收到的业务请求为商品查询请求,则基于分片键获取规则集合中的分片键获取规则A,即可确定该商品查询请求对应的目标分片键;如果接收到的业务请求为订单支付请求,则基于分片键获取规则集合中的分片键获取规则B,即可确定该订单支付请求对应的目标分片键;

在具体实施时,由于请求转发服务端并不关心业务请求的业务类型,因此,可以使用分片键获取规则集合中的多个分片键获取规则,依次对业务请求进行解析处理,针对商品查询请求而言,使用分片键获取规则B得到的请求解析结果为空,而使用分片键获取规则A得到的请求解析结果为非空,即可确定商品查询请求对应的目标分片键;类似地,针对订单支付请求而言,使用分片键获取规则A得到的请求解析结果为空,而使用分片键获取规则B得到的请求解析结果为非空,即可确定订单支付请求对应的目标分片键;

另外,需要说明的是,针对接口需求信息相同的多个业务类型可以配置相同的分片键获取规则,即虽然业务类型不同,但其对应的请求接收接口的第一格式要求信息和第二格式要求信息是相同的,因此,可以使用同一个分片键获取规则从业务类型不同的多个业务请求中获取目标分片键。

S214,基于预设应用所提供的多个业务类型对应的分片键获取规则,生成预设应用对应的分片键获取规则集合。

在具体实施时,考虑到还可能存在使用任一分片键获取规则均无法从业务请求中解析得到非空的目标信息的情况,为了确保业务请求的转发成功率,还可以在分片键获取规则集合中增加兜底规则,具体的,基于预设兜底规则和预设应用所提供的多个业务类型对应的分片键获取规则(即非兜底规则),生成预设应用对应的分片键获取规则集合。

其中,需要说明的是,针对分片键获取规则集合的配置过程中,可以是人为配置的,也可以是基于接口需求信息自动配置的,还可以是在分片键获取规则库中自动匹配得到的;

具体的,由于请求转发服务端能够兼容多个预设应用的业务请求转发服务,且某一分片键获取规则在不同预设应用之间可能是通用的,又考虑到针对同一业务服务提供方所开发的多个预设应用,如果业务类型相同,对应的请求接收接口的格式要求也是相同的,因此,可以将已配置的分片键获取规则存入分片键获取规则库中,在存在新增的预设应用的情况下,可以根据预设应用所提供的业务类型和业务服务提供方标识,在分片键获取规则库中确定匹配的分片键获取规则,这样无需重新配置分片键获取规则,从而实现快速针对新增的预设应用配置相应的分片键获取规则,提高了请求转发服务端的适用性和可扩展性,还增加了已配置的分片键获取规则的可复用性。

进一步地,为了确保分片键获取规则的标准化、规范性、可读性,引入预设数据结构,通过基于接口需求信息对预设数据结构中的多个指示字段进行赋值,得到分片键获取规则,基于此,上述步骤S212,基于上述第一格式要求信息和第二格式要求信息,为预设应用所提供的业务类型配置相应的分片键获取规则,具体包括:

步骤A1,基于上述第一格式要求信息和第二格式要求信息,对预设数据结构中的多个指示字段进行赋值,得到字段赋值后的预设数据结构;

步骤A2,将字段赋值后的预设数据结构确定为预设应用所提供的业务类型对应的分片键获取规则。

其中,预设数据结构的格式可以为:规则唯一标识Id|第一字段Key|第二字段Type|第三字段Script|第四字段Level;具体的,针对某一业务类型对应的分片键获取规则而言,基于该业务类型对应的第一格式要求信息确定第一字段Key的取值,以及基于该业务类型对应的第二格式要求信息确定第二字段Type、以及第三字段Script的取值,第四字段Level的取值可以是根据实际需求进行设置的初始优先级;

具体的,第一字段Key用于指示业务请求是否携带分片键(即利用某一分片键获取规则对业务请求解析得到的目标信息的类型是否为分片键),第一字段Key的取值可以包括uniqueId(即分片键标识,如商品编号CommodityNo、或者有效证件编号cert ificateNo)、contractNo(即分片键为有效证件编号cert ificateNo的关联信息为合同编号)、或者orderNo(即分片键为商品编号CommodityNo的关联信息为订单编号)等等,在具体实施时,第一字段Key的取值可以根据实际需求进行自定义,例如,还可以是0或1,0表示分片键标识,1表示非分片键标识,只要能够对业务请求中与分片键有关的字段信息的类型进行区分即可;具体的,若某一分片键获取规则中第一字段的取值为uniqueId(即取值为分片键标识),则可以确定业务请求中携带有分片键(即基于该分片键获取规则从业务请求中解析得到的目标信息的类型为分片键)、或者该分片键获取规则为兜底规则(即将预设兜底信息确定为目标分片键),若某一分片键获取规则中第一字段的取值不为uniqueId(即取值为非分片键标识),则可以确定业务请求中未携带有分片键(即基于该分片键获取规则从业务请求中解析得到的目标信息的类型不为分片键,因此需要将目标信息转换为目标分片键),例如,第一字段的取值为orderNo且预先定义的分片键为商品编号,则需要将解析得到的订单编号orderNo转换为商品编号(即目标分片键);

具体的,第二字段Type用于指示业务请求携带的与分片键有关的信息字段所在位置;例如,第二字段Type的取值可以包括http header、Url参数、Url path路径、http body、http cookie、或者兜底值等等,其中,由于根据第二字段Type的取值是否为兜底值,可以确定分片键获取规则是否为兜底规则,因此,第二字段Type也可以用于指示分片键获取规则是否为兜底规则;在具体实施时,第二字段Type的取值还可以是数字,再定义数字与具体取值之间的对应关系,例如,1表示http header,2表示Url参数,3表示Url path路径,4表示http body,5表示http cookie,6表示兜底值;因此,若某一分片键获取规则中第二字段的取值为1至5,则可以确定分片键获取规则不为兜底规则且基于第二字段的具体取值可以确定与分片键有关的信息字段在业务请求中的位置信息,若某一分片键获取规则中第二字段的取值为6,则可以确定分片键获取规则为兜底规则;

具体的,第三字段Script用于指示业务请求携带的与分片键有关的信息字段的解析方式;其中,第三字段Script的取值可以包括一个Spel表达式,该Spel表达式用于指示如何从业务请求中解析得到目标信息,例如,第三字段Script的取值为['REQUEST']['BODY']['CONTR_NO'],表示按照REQUEST→BODY→CONTR_NO的层次关系取出目标信息;又如,第三字段Script的取值为['header']['CONTR_NO'],表示从Http Header中获取CONTR_NO这个自定义header的值作为目标信息;

具体的,第四字段Level用于指示分片键获取规则的初始优先级(即规则使用优先级);其中,第四字段Level的取值可以是具体的数值,数值越大表示优先级越高,也可以是其他能够表示优先级的标识信息,具体如何设置不构成对本申请的保护范围的限制。

例如,针对某一预设应用所配置的分片键获取规则集合包括3个分片键获取规则,分片键获取规则1、分片键获取规则2和分片键获取规则3,具体为:

(1)分片键获取规则1为:

1|orderNo|4|['REQUEST']['BODY']['Order_NO']|5

具体的,第一字段的取值为orderNo(即非分片键标识),表示业务请求未携带分片键且携带的与分片键具有预设映射关系的关联信息为订单编号,因此,利用分片键获取规则1对相应的业务请求解析得到的目标信息的类型不为分片键,而是订单编号,需要将订单编号转换为属于分片键的商品编号;第二字段的取值为4,4表示http body,即表示与分片键具有预设映射关系的关联信息位于业务请求的http body中,第三字段的取值为['REQUEST']['BODY']['Order_NO'],表示按照REQUEST→BODY→Order_NO的层次关系取出订单编号orderNo;另外,第四字段的取值为5,表示规则使用优先级居中;

(2)分片键获取规则2为:

2|uniqueId|1|['header']['Commodity_NO']|9

具体的,第一字段的取值为uniqueId(即分片键标识),表示业务请求携带分片键(即商品编号),因此,利用分片键获取规则2对相应的业务请求解析得到的目标信息的类型即为目标分片键;第二字段的取值为1,1表示http header,即表示分片键位于业务请求的http header中,第三字段的取值为['header']['Commodity_NO'],表示从Http Header中获取Commodity_NO这个自定义header的值作为目标信息;另外,第四字段的取值为9,表示规则使用优先级最高;

(3)分片键获取规则3为:

3|uniqueId|6|1234567|1

具体的,第一字段的取值为uniqueId且第二字段的取值为6,6表示兜底值,因此,分片键获取结果所包含的目标信息的类型为分片键,分片键获取规则3为兜底规则,且将预设兜底信息确定为目标分片键,其中,第三字段的取值为1234567,即预设兜底信息为1234567;另外,第四字段的取值为1,表示规则使用优先级最低。其中,针对分片键获取规则为兜底规则的情况,兜底规则中第一字段的取值可以固定为分片键标识(如uniqueId),即上述第一字段Key不仅能够用于指示任意一个请求解析结果中目标信息(即采用任意一个分片键获取规则对业务请求进行解析得到的非空信息)的类型是否为分片键,还能够用于指示预设兜底信息(即基于兜底规则确定出的分片键获取结果所包含的目标信息)的类型为分片键;另外,在具体实施时,由于若分片键获取规则的兜底规则,则可以直接将预设兜底信息确定为目标分片键,即也可以同时确定预设兜底信息的类型为分片键,此时可以预设兜底信息的类型可以与第一字段的取值无关,因此,第一字段的取值主要用来表征采用任意一个分片键获取规则对业务请求进行解析得到的非空信息(即任意一个请求解析结果中目标信息)的类型是否为分片键。

需要说明的是,由于业务请求的格式可能是二进制格式,因此,需要先将业务请求(如http请求)转换为JSON格式的业务请求,再利用分片键获取规则对JSON格式的业务请求进行解析处理,得到相应的请求解析结果。

在具体实施时,如图4所示,给出了一种业务请求处理的具体实现过程主要包括:

针对每个预设应用,获取该预设应用所提供的业务类型对应的接口需求信息;基于该接口需求信息为该预设应用所提供的业务类型配置相应的分片键获取规则,从而得到该预设应用对应的分片键获取规则集合;

存储预设应用与分片键获取规则集合之间的第一对应关系;以及存储预设应用与数据库节点子集之间的第二对应关系;

在接收到客户端针对目标应用的业务请求后,基于上述第一对应关系获取目标应用对应的分片键获取规则集合;具体的,在上述图2中,针对预设应用1至N分别配置对应的分片键获取规则集合1至N;

基于目标应用对应的分片键获取规则集合对接收到的业务请求进行解析处理,得到该业务请求对应的目标分片键;具体的,在上述图2中,若目标应用为预设应用1,则基于分片键获取规则集合1对接收到的业务请求1进行解析处理;若目标应用为预设应用N,则基于分片键获取规则集合N对接收到的业务请求2进行解析处理;

基于上述目标分片键和第二对应关系,从目标应用对应的数据库节点子集中确定目标数据库节点;具体的,在上述图2中,业务请求1对应的目标数据库节点可以为预设应用1对应的数据库节点子集中的数据库节点i,业务请求2对应的目标数据库节点可以为预设应用N对应的数据库节点子集中的数据库节点j。

进一步地,针对目标分片键的确定过程,考虑到请求转发服务端并不需要关心业务请求的业务类型,因此为了确保在不需要结合具体业务数据识别当前接收到的业务请求的实际业务类型、或者无法获知当前接收到的业务请求的实际业务类型的情况下,自动确定当前接收到的业务请求对应的目标分片键,需要使用分片键获取规则集合中的多个分片键获取规则对业务请求进行解析处理,看哪个分片键获取规则的请求解析结果不为空,从而确定目标分片键,基于此,为了尽量确保优先使用与当前接收到的业务请求相匹配的分片键获取规则,从而提高业务请求对应的目标分片键的获取效率,可以引入规则使用优先级,按照规则使用优先级由高至低的顺序对业务请求进行解析处理,如图5所示,上述步骤S204,基于目标应用对应的分片键获取规则集合对接收到的业务请求进行解析处理,得到该业务请求对应的目标分片键,具体包括:

S2042,确定目标应用对应的分片键获取规则集合中各分片键获取规则的规则使用优先级;

其中,各分片键获取规则的规则使用优先级可以是预先设定的,也可以是基于目标应用对应的分片键获取集合中的多个分片键获取规则与当前接收到的业务请求之间的匹配程度实时确定的,即当前待处理的业务请求与某一分片键获取规则的匹配程度越高,该分片键获取规则的规则使用优先级越高;具体的,由于分片键获取规则与当前接收到的业务请求之间的匹配程度越高,说明分片键获取规则能够从业务请求中解析出目标信息的概率越大,因此,优先使用该分片键获取规则对业务请求进行解析处理。

S2044,基于上述规则使用优先级,利用至少一个分片键获取规则对接收到的业务请求进行解析处理,得到该业务请求对应的分片键获取结果;

具体的,按照规则使用优先级由高至低的顺序,依次选取一个分片键获取规则对当前接收到的业务请求进行解析处理,若某一分片键获取规则对应的请求解析结果不为空,则将该非空的请求解析结果确定为业务请求对应的分片键获取结果;或者,若在选取兜底规则之前所选取的分片键获取规则对应的请求解析结果均为空,则将预设兜底信息确定为业务请求对应的分片键获取结果。

具体的,针对分片键获取结果的确定过程,若在分片键获取规则的配置过程中,在分片键获取规则集合中增加了兜底规则,这样能够在利用分片键获取规则集合中的部分或全部的分片键获取规则对业务请求进行解析,得到的请求解析结果均为空的情况下,可以使用兜底规则确定目标分片键,从而确保针对任意一个业务请求均能够确定出对应的目标分片键,因此,在从分片键获取规则集合中选取用于对业务请求进行解析的分片键获取规则的过程中,需要先判断本次选取的分片键获取规则是否为兜底规则,若本次选取的分片键获取规则为兜底规则,则无需对业务请求进行解析,直接将兜底值作为目标分片键即可,基于此,上述S2044,基于上述规则使用优先级,利用至少一个分片键获取规则对接收到的业务请求进行解析处理,得到该业务请求对应的分片键获取结果,具体包括:

步骤一,基于上述规则使用优先级,从目标应用对应的分片键获取规则集合中选取一个分片键获取规则;其中,本次选取的分片键获取规则为未被选取的分片键获取规则中优先级最高的分片键获取规则;

步骤二,若本次选取的分片键获取规则不为兜底规则,则基于本次选取的分片键获取规则对当前接收到的业务请求进行解析处理,得到请求解析结果;

步骤三,基于上述请求解析结果,确定上述业务请求对应的分片键获取结果;

具体的,针对上述步骤三,基于上述请求解析结果,确定上述业务请求对应的分片键获取结果,具体包括:

(1)若上述请求解析结果为空,则重复执行上述步骤一和步骤二;即若基于本次选取的分片键获取规则对业务请求进行解析,得到的请求解析结果为空,则继续选取下一个优先级最高的分片键获取规则对业务请求进行解析,直到请求解析结果不为空,或者下一个选取的分片键获取规则为兜底规则。

(2)若上述请求解析结果不为空,则将上述请求解析结果确定为上述业务请求对应的分片键获取结果;即若基于本次选取的分片键获取规则对业务请求进行解析,得到的请求解析结果不为空,则将解析得到的非空的目标信息确定为上述业务请求对应的分片键获取结果。

步骤四,若本次选取的分片键获取规则为兜底规则,则将预设兜底信息确定为上述业务请求对应的分片键获取结果;即针对本次选取的分片键获取规则为兜底规则的情况,分片键获取结果所包含的目标信息为预设兜底信息。

S2046,基于上述分片键获取结果,确定上述业务请求对应的目标分片键。

具体的,针对目标分片键的确定过程,考虑到业务请求中可能不直接携带有分片键,因此,为了实现在确保业务请求的请求格式保持不变(即业务请求中不额外增加分片键信息)的情况下,也能够获取到业务请求对应的目标分片键,基于此,上述S2046,基于上述分片键获取结果,确定上述业务请求对应的目标分片键,具体包括:

(1)若上述分片键获取结果所包含的目标信息的类型为分片键,则将目标信息确定为接收到的业务请求对应的目标分片键;

具体的,如果利用某一分片键获取规则对业务请求进行解析处理,从业务请求中解析出的目标信息的类型为分片键,则直接将目标信息确定为当前接收到的业务请求对应的目标分片键,例如,若分片键为商品编号,目标信息也为商品编号,则确定从业务请求中解析得到的商品编号为目标分片键;或者,针对选取的分片键获取规则为兜底规则的情况,分片键获取结果所包含的目标信息为预设兜底信息,此时,同样是直接将目标信息确定为当前接收到的业务请求对应的目标分片键。

(2)若上述分片键获取结果所包含的目标信息的类型不为分片键,则基于预存分片键映射关系,确定目标信息对应的预设分片键,并将该预设分片键确定为接收到的业务请求对应的目标分片键。

具体的,如果从业务请求中解析出的目标信息的类型不为分片键,则需要基于预存分片键映射关系,将目标信息转换为目标分片键,这样针对业务请求中不携带预设的分片键的情况,也不需要在业务请求中额外增加分片键字段,而是间接地从业务请求中获取目标分片键,即先从业务请求中解析得到与目标分片键具有一定映射关系的关联信息(即分片键获取结果所包含的目标信息),再基于目标信息和预存分片键映射关系确定目标分片键,达到在确保业务请求的请求格式保持不变的情况下,也能够准确地获取业务请求对应的目标分片键。

具体的,为了提高预存分片键映射关系的获取效率,可以先从缓存数据库Redis中获取预存分片键映射关系,若缓存数据库中不存在该预存分片键映射关系,再从开源数据库HBase中获取该预存分片键映射关系;其中,预存分片键映射关系包括目标信息与分片键之间的对应关系,例如,若分片键为商品编号,目标信息为订单编号,则预存分片键映射关系包括商品编号与订单编号之间的对应关系,因此,基于预存分片键映射关系可以确定从业务请求中解析得到的订单编号对应的商品编号(即目标分片键)。

在一个具体实施例中,例如,目标应用对应的分片键获取规则集合中包括3个分片键获取规则,仍以上述分片键获取规则1、分片键获取规则2和分片键获取规则3为例进行细化说明,因此,3个分片键获取规则的规则使用优先级由高至低的顺序为:分片键获取规则2→分片键获取规则1→分片键获取规则3;

具体的,首次选取的分片键获取规则为分片键获取规则2“2|uniqueId|1|['header']['Commodity_NO']|9”且分片键获取规则2不为兜底规则,利用分片键获取规则2对当前接收到的业务请求进行解析处理,得到请求解析结果1;

若请求解析结果1不为空,则将解析得到的商品编号commodityNO(即分片键获取结果所包含的目标信息)确定为目标分片键;

若请求解析结果1为空,则继续选取下一个分片键获取规则为分片键获取规则1“1|orderNo|4|['REQUEST']['BODY']['Order_NO']|5”且分片键获取规则1不为兜底规则,利用分片键获取规则1对当前接收到的业务请求进行解析处理,得到请求解析结果2;

若请求解析结果2不为空,则将解析得到的订单编号orderNo确定为分片键获取结果所包含的目标信息,由于目标信息的类型不为分片键,因此,需要基于目标信息和预存分片键映射关系,确定订单编号orderNo对应的商品编号(即目标分片键);

若请求解析结果2为空,则继续选取下一个分片键获取规则为分片键获取规则3“3|uniqueId|6|1234567|1”且分片键获取规则3为兜底规则,则将预设兜底值1234567(即分片键获取结果所包含的目标信息)确定为目标分片键。

接下来,针对分片键获取规则包括多个指示字段的情况,对确定业务请求对应的目标分片键的具体实现过程进行详细说明。

在具体实施时,由于是否需要对分片键获取结果所包含的目标信息进行转换得到目标分片键,取决于该目标信息的类型是否为分片键,针对确定分片键获取结果所包含的目标信息的类型是否为分片键的过程,可以是判断预设的分片键标识集合中是否存在目标信息对应的字段标识(如,目标信息对应的字段标识为订单编号,但预设的分片键标识集合中包含商品编号,不包含订单编号,则说明目标信息的类型不属于分片键),也可以是通过查询预存的分片键映射关系,判断是否存在与目标信息对应的一条分片键映射关系,若存在,则说明目标信息的类型不属于分片键,但这两种判断方式的信息比对量比较大,导致目标信息的类型是否为分片键的确定效率低,基于此,为了提高目标信息的类型是否为分片键的确定效率和准确度,在分片键获取规则的配置过程中,增加一个指示字段,具体的,上述任意一个分片键获取规则可以包括用于指示任意一个请求解析结果中目标信息的类型是否为分片键的第一字段,该任意一个请求解析结果是采用目标应用对应的分片键获取规则集合中任意一个分片键获取规则对业务请求进行解析得到的;对应的,在上述S2046,基于上述分片键获取结果,确定上述业务请求对应的目标分片键之前,还包括:

(1)若上述分片键获取结果对应的分片键获取规则中第一字段的取值为分片键标识,则确定上述分片键获取结果所包含的目标信息的类型为分片键;

(2)若上述分片键获取结果对应的分片键获取规则中第一字段的取值为非分片键标识,则确定上述分片键获取结果所包含的目标信息的类型不为分片键。

具体的,上述分片键获取结果对应的分片键获取规则为最后一个选取的分片键获取规则,即解析得到目标信息的分片键获取规则、或者最后选取的兜底规则;例如,若上述分片键获取结果对应的分片键获取规则为上述分片键获取规则2“2|uniqueId|1|['header']['Commodity_NO']|9”,即解析得到目标信息的分片键获取规则中第一字段的取值为uniqueId(即分片键标识),则可以确定分片键获取结果所包含的目标信息的类型为分片键;

又如,若上述分片键获取结果对应的分片键获取规则为上述分片键获取规则1“1|orderNo|4|['REQUEST']['BODY']['Order_NO']|5”,即解析得到目标信息的分片键获取规则中第一字段的取值为orderNo(即非分片键标识),则可以确定分片键获取结果所包含的目标信息的类型不为分片键;

再如,若上述分片键获取结果对应的分片键获取规则为上述分片键获取规则3“3|uniqueId|6|1234567|1”,即最后选取的兜底规则中第一字段的取值为uniqueId(即分片键标识),则可以确定分片键获取结果所包含的目标信息的类型为分片键。

在具体实施时,由于是否需要利用本次选取的分片键获取规则对业务请求进行解析处理,取决于本次选取的分片键获取规则是否为兜底规则,因此,针对确定本次选取的分片键获取规则是否为兜底规则的过程,为了提高兜底规则的识别准确度和效率,在分片键获取规则的配置过程中,增加另一个指示字段,具体的,上述任意一个分片键获取规则包括用于指示分片键获取规则是否为兜底规则的第二字段;对应的,在上述步骤一,基于上述规则使用优先级,从目标应用对应的分片键获取规则集合中选取一个分片键获取规则之后,还包括:

(1)若本次选取的分片键获取规则中第二字段的取值为第一取值,则确定本次选取的分片键获取规则不为兜底规则;

(2)若本次选取的分片键获取规则中第二字段的取值为第二取值,则确定本次选取的分片键获取规则为兜底规则。

其中,第一取值与第一取值不同,仍以上述第二字段的取值为1至6为例,第一取值包括1至5,第二取值包括6;例如,若本次选取的分片键获取规则为上述分片键获取规则2“2|uniqueId|1|['header']['Commodity_NO']|9”,即本次选取的分片键获取规则中第二字段的取值为1(即第一取值),则可以确定本次选取的分片键获取规则不为兜底规则;

又如,若本次选取的分片键获取规则为上述分片键获取规则1“1|orderNo|4|['REQUEST']['BODY']['Order_NO']|5”,即本次选取的分片键获取规则中第二字段的取值为4(即第一取值),则可以确定本次选取的分片键获取规则不为兜底规则;

再如,若本次选取的分片键获取规则为上述分片键获取规则3“3|uniqueId|6|1234567|1”,即本次选取的分片键获取规则中第二字段的取值为6(即第一取值),则可以次选取的分片键获取规则为兜底规则。

在具体实施时,由于与分片键有关的目标信息在业务请求中的位置有所不同,因此,在分片键获取规则的配置过程中,增加另一个指示字段,用来指示如何从业务请求中解析得到所需的目标信息,具体的,上述任意一个分片键获取规则包括用于指示请求解析方式的第三字段;对应的,上述步骤二中的基于本次选取的分片键获取规则对当前接收到的业务请求进行解析处理,得到请求解析结果,具体包括:

基于本次选取的分片键获取规则中第三字段的取值,确定请求解析表达式;

基于上述请求解析表达式对当前接收到的业务请求进行解析处理,得到请求解析结果。

例如,若本次选取的分片键获取规则为上述分片键获取规则2“2|uniqueId|1|['header']['Commodity_NO']|9”,即本次选取的分片键获取规则中第三字段的取值为['header']['Commodity_NO'],则表示从Http Header中获取Commodity_NO这个自定义header的值作为目标信息,若解析得到的值不为空,即可得到包含目标信息的请求解析结果;

又如,若本次选取的分片键获取规则为上述分片键获取规则1“1|orderNo|4|['REQUEST']['BODY']['Order_NO']|5”,即本次选取的分片键获取规则中第三字段的取值为['REQUEST']['BODY']['Order_NO'],则表示按照REQUEST→BODY→Order_NO的层次关系取出订单编号orderNo作为目标信息,若解析结果不为空,即可得到包含目标信息的请求解析结果。

在具体实施时,在分片键获取规则的配置过程中,同样可以增加一个用于指示规则使用优先级的指示字段,具体的,上述任意一个分片键获取规则包括用于指示规则使用优先级的第四字段;对应的,上述步骤S2042,确定目标应用对应的分片键获取规则集合中各分片键获取规则的规则使用优先级,具体包括:

基于目标应用对应的分片键获取规则集合中每个分片键获取规则的第四字段的取值,确定各分片键获取规则的规则使用优先级。

具体的,可以直接将分片键获取规则中第四字段的取值确定为最终的规则使用优先级,即按照分片键获取规则中第四字段的取值对多个分片键获取规则进行排序;也可以将分片键获取规则中第四字段的取值确定为初始使用优先级,再基于历史相关信息,动态调整初始使用优先级的顺序,得到最终的规则使用优先级,从而提高分片键获取规则的规则使用优先级的确定准确度。

在具体实施时,为了进一步提高业务请求对应的目标分片键的获取效率,因此,需要提高分片键获取规则的规则使用优先级的确定准确度,基于此,上述基于目标应用对应的分片键获取规则集合中每个分片键获取规则的第四字段的取值,确定各分片键获取规则的规则使用优先级,具体包括:

步骤B1,基于目标应用对应的分片键获取规则集合中每个分片键获取规则的第四字段的取值,确定各分片键获取规则的初始使用优先级;

步骤B2,基于预设历史时间段内所使用的分片键获取规则,对各分片键获取规则的初始使用优先级的排序进行调整,得到各分片键获取规则的最终的规则使用优先级。

具体的,在不需要结合具体业务数据识别待处理的业务请求的实际业务类型、或者无法获知待处理的业务请求的实际业务类型的情况下,为了提高分片键获取规则的规则使用优先级的准确度,考虑到对于某一目标用户而言,该目标用户先后发起的业务请求的业务类型通常具有一定规律性,又考虑到分片键获取规则与业务类型也具有一定对应关系,因此,各分片键获取规则的规则使用优先级可以是基于目标用户的业务行为偏好信息和预设历史时间段内所使用的分片键获取规则,对初始使用优先级进行调整得到的;

在具体实施时,基于对目标用户在预设历史时间段内的历史业务请求所使用的分片键获取规则(即对目标用户的历史业务请求进行解析得到非空的目标信息的分片键获取规则),即可确定预设历史时间段内目标用户的历史业务请求的业务类型;再基于历史业务请求的业务类型和目标用户的业务行为偏好信息,即可预测当前接收到的业务请求对应的至少一个候选业务类型,增大至少一个候选业务类型对应的分片键获取规则的初始使用优先级,得到各分片键获取规则的最终的规则使用优先级;具体的,可以认为当前接收到的业务请求与至少一个候选业务类型对应的分片键获取规则之间的匹配程度比较高,因此,至少一个候选业务类型对应的分片键获取规则的规则使用优先级也应设置为更高。

具体的,针对当前接收到的业务请求对应的至少一个候选业务类型的确定过程,可以利用预先训练的用户业务行为识别模型,基于历史业务请求的业务类型和目标用户的业务行为偏好信息,对目标应用所提供的多个业务类型进行打分,将预测分数排序靠前的P个业务类型确定为候选业务类型;例如,基于预设历史时间段内所使用的分片键获取规则,确定出预设历史时间段内目标用户先后发起的历史业务请求的业务类型为a和b,又结合目标用户的业务行为偏好信息,可知目标用户在先后发起业务类型为a和b的业务请求后,通常会发起业务类型为c或d的业务请求,因此,将业务类型为c或d确定为至少一个候选业务类型,并且,若业务类型d的预测分数大于业务类型c的预测分数,则业务类型d对应的分片键获取规则的使用优先级高于业务类型c对应的分片键获取规则的使用优先级。

其中,需要说明的是,业务类型为a和b的历史业务请求与业务类型为c或d的当前接收到的业务请求所针对的预设应用可以是相同的,也可以不同的,例如,目标用户在应用使用习惯上可以是先触发第一应用(例如,某一银行应用)查看账户余额,再触发第二应用(例如,某一理财应用,如京东金融)请求将第一应用的部分账户余额转入第二应用的账户,对应的,历史业务请求的业务类型为资源查看请求,待处理的业务请求的业务类型为资源转移请求,若当前接收到的待处理业务请求所针对的目标应用为第二应用,则自动增大第二应用对应的分片键获取规则集合中与资源转移请求对应的分片键获取规则的规则使用优先级。

另外,考虑到还可能存在针对目标用户在预设历史时间段内的历史业务请求所使用的分片键获取规则的数据量不够的情况,因此,无法准确地结合目标用户的业务行为偏好信息对预测当前接收到的业务请求对应的至少一个候选业务类型;又考虑到针对同一目标应用的业务请求发起需求在多数用户之间具有共性,因此,基于对其他用户在预设历史时间段内的历史业务请求所使用的分片键获取规则,即可确定目标应用所提供的多个业务类型中使用频次比较高的至少一个高频业务类型,增大至少一个高频业务类型对应的分片键获取规则的初始使用优先级,得到各分片键获取规则的最终的规则使用优先级;具体的,可以认为当前接收到的业务请求与至少一个高频业务类型对应的分片键获取规则之间的匹配程度比较高,因此,至少一个高频业务类型对应的分片键获取规则的规则使用优先级也应设置为更高。

在一个具体实施例中,如图6所示,以上述预设应用对应的数据存储方式包括数据分库且表结构相同的数据存储方式、或者数据分库且表结构不同的数据存储方式为例,上述业务请求处理的具体实现过程主要包括:

接收客户端基于用户对目标应用的触发操作所发出的业务请求;其中,业务请求携带有目标应用的标识信息;

判断目标应用对应的数据存储方式是否为数据分库且表结构相同的数据存储方式;

若否,则将业务请求转发至目标应用对应的业务服务端;

若是,则获取目标应用对应的分片键获取规则集合,并确定分片键获取规则集合中多个分片键获取规则的规则使用优先级排序;

基于上述规则使用优先级排序,按照优先级由高至低的顺序选取一个分片键获取规则;

判断本次选取的分片键获取规则是否为兜底规则;

若是,则将预设兜底信息确定为业务请求对应的目标分片键;

若否,则利用本次选取的分片键获取规则,对当前接收到的业务请求进行解析处理,得到请求解析结果;

判断本次得到的请求解析结果是否为空;

若是,则重复执行基于上述规则使用优先级排序,按照优先级由高至低的顺序选取下一个分片键获取规则的步骤以及后续步骤;

若否,则判断本次得到的请求解析结果所包含的目标信息的类型是否为分片键;

若是,则将上述目标信息确定为目标分片键;

若否,则从缓存数据库Redis中获取预存分片键映射关系;

判断是否获取到目标信息对应的预存分片键映射关系;

若是,则基于获取到的预存分片键映射关系确定目标信息对应的目标分片键;

若否,则从开源数据库HBase中获取目标信息对应的预存分片键映射关系,并基于获取到的预存分片键映射关系确定目标信息对应的目标分片键;

利用预设脚本引擎,基于上述目标分片键确定目标数据库节点;

将上述业务请求转发至目标数据库节点,以使目标数据库节点用于根据接收到的业务请求进行数据存储或者数据查询。

本申请实施例中的业务请求处理方法,请求转发服务端在接收到客户端基于用户对目标应用的触发操作而发出的业务请求后,基于目标应用对应的分片键获取规则集合对业务请求进行解析,得到目标分片键;然后,基于目标分片键,从目标应用对应的数据库节点子集中确定目标数据库节点;再将业务请求转发至目标数据库节点,以使目标数据库节点根据业务请求进行数据存储或者数据查询;一方面,在客户端和数据库节点之间增设请求转发服务端,由请求转发服务端基于业务请求获取相应的目标分片键,这样目标应用对应的分片键获取规则集合仅需部署于请求转发服务端即可,无论是客户端还是数据库节点不仅不需要部署分片键获取规则,也省去了基于业务请求获取目标分片键的步骤,并且请求转发服务端能够对同一客户端上安装的多个预设应用的业务请求进行转发,也能够对不同客户端上安装的同一预设应用的业务请求进行转发;另一方面,通过预先针对每个预设应用配置相应的分片键获取规则集合,再基于分片键获取规则集合对业务请求进行解析,再基于解析结果即可获取所需的目标分片键,由于分片键获取规则集合中包含多个分片键获取规则且这多个分片键获取规则是有针对性地为某一预设应用所配置的,确保了分片键获取方式的多样性和针对性,这样在不需要结合具体业务数据识别待处理的业务请求的实际业务类型、或者无法获知待处理的业务请求的实际业务类型的情况下,也能够基于分片键获取集合中的某一分片键获取规则确定目标分片键,从而提高目标分片键的获取准确度和灵活性,进一步的,基于目标分片键就可以确定出应该接收此次业务请求的目标数据库节点,因此本申请能够提高目标数据库节点的确定准确度。

对应上述图2至图6描述的业务请求处理方法,基于相同的技术构思,本申请实施例还提供了一种业务请求处理装置,图7为本申请实施例提供的业务请求处理装置的模块组成示意图,该装置设置于请求转发服务端,请求转发服务端与数据库节点集群之间通信连接,数据库节点集群包括多个预设应用分别对应的数据库节点子集,该装置用于执行图2至图6描述的业务请求处理方法,如图7所示,该装置包括:

接收单元702,用于接收客户端的业务请求;所述业务请求是所述客户端基于目标用户对所述多个预设应用中目标应用的触发操作而发出的;

确定单元704,用于基于所述目标应用对应的分片键获取规则集合对所述业务请求进行解析处理,得到目标分片键;

所述确定单元704,还用于基于所述目标分片键,从所述目标应用对应的数据库节点子集中确定目标数据库节点;

转发单元706,用于将所述业务请求转发至所述目标数据库节点;所述目标数据库节点用于根据所述业务请求进行数据存储或者数据查询。

可选地,针对目标分片键的确定过程,考虑到请求转发服务端并不需要关心业务请求的业务类型,因此为了确保在不需要结合具体业务数据识别当前接收到的业务请求的实际业务类型、或者无法获知当前接收到的业务请求的实际业务类型的情况下,自动确定当前接收到的业务请求对应的目标分片键,需要使用分片键获取规则集合中的多个分片键获取规则对业务请求进行解析处理,看哪个分片键获取规则的请求解析结果不为空,从而确定目标分片键,基于此,为了尽量确保优先使用与当前接收到的业务请求相匹配的分片键获取规则,从而提高业务请求对应的目标分片键的获取效率,可以引入规则使用优先级,按照规则使用优先级由高至低的顺序对业务请求进行解析处理,基于此,所述确定单元704,具体用于:

确定所述分片键获取规则集合中各分片键获取规则的规则使用优先级;

基于所述规则使用优先级,利用至少一个分片键获取规则对所述业务请求进行解析处理,得到所述业务请求对应的分片键获取结果;

基于所述分片键获取结果,确定所述业务请求对应的目标分片键。

可选地,针对分片键获取结果的确定过程,若在分片键获取规则的配置过程中,在分片键获取规则集合中增加了兜底规则,这样能够在利用分片键获取规则集合中的部分或全部的分片键获取规则对业务请求进行解析,得到的请求解析结果均为空的情况下,可以使用兜底规则确定目标分片键,从而确保针对任意一个业务请求均能够确定出对应的目标分片键,因此,在从分片键获取规则集合中选取用于对业务请求进行解析的分片键获取规则的过程中,需要先判断本次选取的分片键获取规则是否为兜底规则,若本次选取的分片键获取规则为兜底规则,则无需对业务请求进行解析,直接将兜底值作为目标分片键即可,基于此,所述确定单元704,进一步具体用于:

基于所述规则使用优先级,从所述分片键获取规则集合中选取一个分片键获取规则;其中,本次选取的所述分片键获取规则为未被选取的分片键获取规则中优先级最高的分片键获取规则;

若本次选取的所述分片键获取规则不为兜底规则,则基于本次选取的分片键获取规则对所述业务请求进行解析处理,得到请求解析结果;并基于所述请求解析结果,确定所述业务请求对应的分片键获取结果;

若本次选取的所述分片键获取规则为兜底规则,则将预设兜底信息确定为所述业务请求对应的分片键获取结果。

可选地,所述确定单元704,更进一步具体用于:

若所述请求解析结果为空,则重复执行基于所述规则使用优先级,从所述分片键获取规则集合中选择一个分片键获取规则的步骤以及后续步骤;

若所述请求解析结果不为空,则将所述请求解析结果确定为所述业务请求对应的分片键获取结果。

可选地,针对目标分片键的确定过程,考虑到业务请求中可能不直接携带有分片键,因此,为了实现在确保业务请求的请求格式保持不变(即业务请求中不额外增加分片键信息)的情况下,也能够获取到业务请求对应的目标分片键,基于此,所述确定单元704,还具体用于:

若所述分片键获取结果所包含的目标信息的类型为分片键,则将所述目标信息确定为所述业务请求对应的目标分片键;

若所述分片键获取结果所包含的目标信息的类型不为分片键,则基于预存分片键映射关系,确定所述目标信息对应的预设分片键,并将所述预设分片键确定为目标分片键。

可选地,考虑到是否需要对分片键获取结果所包含的目标信息进行转换得到目标分片键,取决于该目标信息的类型是否为分片键,针对确定分片键获取结果所包含的目标信息的类型是否为分片键的过程,可以是判断预设的分片键标识集合中是否存在目标信息对应的字段标识(如,目标信息对应的字段标识为订单编号,但预设的分片键标识集合中包含商品编号,不包含订单编号,则说明目标信息的类型不属于分片键),也可以是通过查询预存的分片键映射关系,判断是否存在与目标信息对应的一条分片键映射关系,若存在,则说明目标信息的类型不属于分片键,但这两种判断方式的信息比对量比较大,导致目标信息的类型是否为分片键的确定效率低,基于此,为了提高目标信息的类型是否为分片键的确定效率和准确度,在分片键获取规则的配置过程中,增加一个指示字段,基于此,任意一个分片键获取规则包括用于指示任意一个请求解析结果中目标信息的类型是否为分片键的第一字段;所述任意一个请求解析结果是采用所述任意一个分片键获取规则对所述业务请求进行解析得到的;所述确定单元704,还具体用于:

若所述分片键获取结果对应的分片键获取规则中第一字段的取值为分片键标识,则确定所述分片键获取结果所包含的目标信息的类型为分片键;

若所述分片键获取结果对应的分片键获取规则中第一字段的取值为非分片键标识,则确定所述分片键获取结果所包含的目标信息的类型不为分片键。

可选地,又考虑到是否需要利用本次选取的分片键获取规则对业务请求进行解析处理,取决于本次选取的分片键获取规则是否为兜底规则,因此,针对确定本次选取的分片键获取规则是否为兜底规则的过程,为了提高兜底规则的识别准确度和效率,在分片键获取规则的配置过程中,增加另一个指示字段,基于此,任意一个分片键获取规则包括用于指示分片键获取规则是否为兜底规则的第二字段;所述确定单元704,还具体用于:

若本次选取的分片键获取规则中第二字段的取值为第一取值,则确定本次选取的所述分片键获取规则不为兜底规则;

若本次选取的分片键获取规则中第二字段的取值为第二取值,则确定本次选取的所述分片键获取规则为兜底规则。

可选地,还考虑到与分片键有关的目标信息在业务请求中的位置有所不同,因此,在分片键获取规则的配置过程中,增加另一个指示字段,用来指示如何从业务请求中解析得到所需的目标信息,基于此,任意一个分片键获取规则包括用于指示请求解析方式的第三字段;所述确定单元704,还具体用于:

基于本次选取的分片键获取规则中第三字段的取值,确定请求解析表达式;

基于所述请求解析表达式对所述业务请求进行解析处理,得到请求解析结果。

可选地,在分片键获取规则的配置过程中,同样可以增加一个用于指示规则使用优先级的指示字段,基于此,任意一个分片键获取规则包括用于指示规则使用优先级的第四字段;所述确定单元704,还具体用于:

基于所述分片键获取规则集合中每个分片键获取规则的第四字段的取值,确定各分片键获取规则的规则使用优先级。

可选地,为了进一步提高业务请求对应的目标分片键的获取效率,因此,需要提高分片键获取规则的规则使用优先级的确定准确度,所述确定单元704,还进一步具体用于:

基于所述分片键获取规则集合中每个分片键获取规则的第四字段的取值,确定各分片键获取规则的初始使用优先级;

基于预设历史时间段内所使用的分片键获取规则,对所述各分片键获取规则的初始使用优先级的排序进行调整,得到各分片键获取规则的规则使用优先级。

可选地,针对基于目标分片键确定目标数据库节点的过程,为了提高目标数据库节点的确定效率,可以预先配置预设脚本引擎,具体的,以取模计算为例,所述确定单元704,还具体用于:

利用预设脚本引擎,对所述目标分片键中的部分字符或全部字符进行取模计算,得到取模数值;

将所述目标应用对应的数据库节点子集中,与所述取模数值对应的数据库节点确定为目标数据库节点。

可选地,为了提高请求转发服务端的适用性和可扩展性,确保能够同时兼容多个预设应用的业务请求的转发服务,预先分别针对每个预设应用有针对性地配置分片键获取规则集合,其中,针对各预设应用分别对应的分片键获取规则集合的配置过程,所述装置还包括规则构建单元,用于:

针对每个预设应用,获取所述预设应用所提供的每个业务类型对应的接口需求信息;所述接口需求信息包括表征业务请求是否包含分片键的第一格式要求信息、以及表征与分片键有关的字段所在位置的第二格式要求信息;

基于所述第一格式要求信息和所述第二格式要求信息,为每个业务类型配置相应的分片键获取规则;所述分片键获取规则用于对属于相应业务类型的业务请求进行解析得到与分片键有关的字段;

基于多个业务类型对应的分片键获取规则,生成所述预设应用对应的分片键获取规则集合。

本申请实施例中的业务请求处理装置,在接收到客户端基于用户对目标应用的触发操作而发出的业务请求后,基于目标应用对应的分片键获取规则集合对业务请求进行解析,得到目标分片键;然后,基于目标分片键,从目标应用对应的数据库节点子集中确定目标数据库节点;再将业务请求转发至目标数据库节点,以使目标数据库节点根据业务请求进行数据存储或者数据查询;一方面,在客户端和数据库节点之间增设请求转发服务端,由请求转发服务端基于业务请求获取相应的目标分片键,这样目标应用对应的分片键获取规则集合仅需部署于请求转发服务端即可,无论是客户端还是数据库节点不仅不需要部署分片键获取规则,也省去了基于业务请求获取目标分片键的步骤,并且请求转发服务端能够对同一客户端上安装的多个预设应用的业务请求进行转发,也能够对不同客户端上安装的同一预设应用的业务请求进行转发;另一方面,通过预先针对每个预设应用配置相应的分片键获取规则集合,再基于分片键获取规则集合对业务请求进行解析,再基于解析结果即可获取所需的目标分片键,由于分片键获取规则集合中包含多个分片键获取规则且这多个分片键获取规则是有针对性地为某一预设应用所配置的,确保了分片键获取方式的多样性和针对性,这样在不需要结合具体业务数据识别待处理的业务请求的实际业务类型、或者无法获知待处理的业务请求的实际业务类型的情况下,也能够基于分片键获取集合中的某一分片键获取规则确定目标分片键,从而提高目标分片键的获取准确度和灵活性,进一步的,基于目标分片键就可以确定出应该接收此次业务请求的目标数据库节点,因此本申请能够提高目标数据库节点的确定准确度。

需要说明的是,本申请中关于业务请求处理装置的实施例与本申请中关于业务请求处理方法的实施例基于同一发明构思,因此该实施例的具体实施可以参见前述对应的业务请求处理方法的实施,重复之处不再赘述。

进一步地,对应上述图2至图6所示的方法,基于相同的技术构思,本申请实施例还提供了一种业务请求处理设备,该设备用于执行上述的业务请求处理方法,如图8所示。

业务请求处理设备可因配置或性能不同而产生比较大的差异,可以包括一个或一个以上的处理器801和存储器802,存储器802中可以存储有一个或一个以上存储应用程序或数据。其中,存储器802可以是短暂存储或持久存储。存储在存储器802的应用程序可以包括一个或一个以上模块(图示未示出),每个模块可以包括对业务请求处理设备中的一系列计算机可执行指令。更进一步地,处理器801可以设置为与存储器802通信,在业务请求处理设备上执行存储器802中的一系列计算机可执行指令。业务请求处理设备还可以包括一个或一个以上电源803,一个或一个以上有线或无线网络接口804,一个或一个以上输入输出接口805,一个或一个以上键盘806等。

在一个具体的实施例中,业务请求处理设备包括有存储器,以及一个或一个以上的程序,其中一个或者一个以上程序存储于存储器中,且一个或者一个以上程序可以包括一个或一个以上模块,且每个模块可以包括对业务请求处理设备中的一系列计算机可执行指令,且经配置以由一个或者一个以上处理器执行该一个或者一个以上程序包含用于进行以下计算机可执行指令:

接收客户端的业务请求;所述业务请求是所述客户端基于目标用户对所述多个预设应用中目标应用的触发操作而发出的;

基于所述目标应用对应的分片键获取规则集合对所述业务请求进行解析处理,得到目标分片键;

基于所述目标分片键,从所述目标应用对应的数据库节点子集中确定目标数据库节点;

将所述业务请求转发至所述目标数据库节点;所述目标数据库节点用于根据所述业务请求进行数据存储或者数据查询。

本申请实施例中的业务请求处理设备,在接收到客户端基于用户对目标应用的触发操作而发出的业务请求后,基于目标应用对应的分片键获取规则集合对业务请求进行解析,得到目标分片键;然后,基于目标分片键,从目标应用对应的数据库节点子集中确定目标数据库节点;再将业务请求转发至目标数据库节点,以使目标数据库节点根据业务请求进行数据存储或者数据查询;一方面,在客户端和数据库节点之间增设请求转发服务端,由请求转发服务端基于业务请求获取相应的目标分片键,这样目标应用对应的分片键获取规则集合仅需部署于请求转发服务端即可,无论是客户端还是数据库节点不仅不需要部署分片键获取规则,也省去了基于业务请求获取目标分片键的步骤,并且请求转发服务端能够对同一客户端上安装的多个预设应用的业务请求进行转发,也能够对不同客户端上安装的同一预设应用的业务请求进行转发;另一方面,通过预先针对每个预设应用配置相应的分片键获取规则集合,再基于分片键获取规则集合对业务请求进行解析,再基于解析结果即可获取所需的目标分片键,由于分片键获取规则集合中包含多个分片键获取规则且这多个分片键获取规则是有针对性地为某一预设应用所配置的,确保了分片键获取方式的多样性和针对性,这样在不需要结合具体业务数据识别待处理的业务请求的实际业务类型、或者无法获知待处理的业务请求的实际业务类型的情况下,也能够基于分片键获取集合中的某一分片键获取规则确定目标分片键,从而提高目标分片键的获取准确度和灵活性,进一步的,基于目标分片键就可以确定出应该接收此次业务请求的目标数据库节点,因此本申请能够提高目标数据库节点的确定准确度。

需要说明的是,本申请中关于业务请求处理设备的实施例与本申请中关于业务请求处理方法的实施例基于同一发明构思,因此该实施例的具体实施可以参见前述对应的业务请求处理方法的实施,重复之处不再赘述。

进一步地,对应上述图2至图6所示的方法,基于相同的技术构思,本申请实施例还提供了一种存储介质,用于存储计算机可执行指令,一种具体的实施例中,该存储介质可以为U盘、光盘、硬盘等,该存储介质存储的计算机可执行指令在被处理器执行时,能实现以下流程:

接收客户端的业务请求;所述业务请求是所述客户端基于目标用户对所述多个预设应用中目标应用的触发操作而发出的;

基于所述目标应用对应的分片键获取规则集合对所述业务请求进行解析处理,得到目标分片键;

基于所述目标分片键,从所述目标应用对应的数据库节点子集中确定目标数据库节点;

将所述业务请求转发至所述目标数据库节点;所述目标数据库节点用于根据所述业务请求进行数据存储或者数据查询。

本申请实施例中的存储介质存储的计算机可执行指令在被处理器执行时,在接收到客户端基于用户对目标应用的触发操作而发出的业务请求后,基于目标应用对应的分片键获取规则集合对业务请求进行解析,得到目标分片键;然后,基于目标分片键,从目标应用对应的数据库节点子集中确定目标数据库节点;再将业务请求转发至目标数据库节点,以使目标数据库节点根据业务请求进行数据存储或者数据查询;一方面,在客户端和数据库节点之间增设请求转发服务端,由请求转发服务端基于业务请求获取相应的目标分片键,这样目标应用对应的分片键获取规则集合仅需部署于请求转发服务端即可,无论是客户端还是数据库节点不仅不需要部署分片键获取规则,也省去了基于业务请求获取目标分片键的步骤,并且请求转发服务端能够对同一客户端上安装的多个预设应用的业务请求进行转发,也能够对不同客户端上安装的同一预设应用的业务请求进行转发;另一方面,通过预先针对每个预设应用配置相应的分片键获取规则集合,再基于分片键获取规则集合对业务请求进行解析,再基于解析结果即可获取所需的目标分片键,由于分片键获取规则集合中包含多个分片键获取规则且这多个分片键获取规则是有针对性地为某一预设应用所配置的,确保了分片键获取方式的多样性和针对性,这样在不需要结合具体业务数据识别待处理的业务请求的实际业务类型、或者无法获知待处理的业务请求的实际业务类型的情况下,也能够基于分片键获取集合中的某一分片键获取规则确定目标分片键,从而提高目标分片键的获取准确度和灵活性,进一步的,基于目标分片键就可以确定出应该接收此次业务请求的目标数据库节点,因此本申请能够提高目标数据库节点的确定准确度。

需要说明的是,本申请中关于存储介质的实施例与本申请中关于业务请求处理方法的实施例基于同一发明构思,因此该实施例的具体实施可以参见前述对应的业务请求处理方法的实施,重复之处不再赘述。

上述对本申请特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下,在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外,在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中,多任务处理和并行处理也是可以的或者可能是有利的。

本领域内的技术人员应明白,本申请实施例可提供为方法、系统或计算机程序产品。因此,本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可读存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上,使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中,计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括暂存电脑可读媒体(transitory media),如调制的数据信号和载波。

还需要说明的是,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本申请实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述,例如程序模块。一般地,程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请的一个或多个实施例,在这些分布式计算环境中,由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中,程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本申请中的各个实施例均采用递进的方式描述,各个实施例之间相同相似的部分互相参见即可,每个实施例重点说明的都是与其他实施例的不同之处。尤其,对于系统实施例而言,由于其基本相似于方法实施例,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。

以上所述仅为本文件的实施例而已,并不用于限制本文件。对于本领域技术人员来说,本文件可以有各种更改和变化。凡在本文件的精神和原理之内所作的任何修改、等同替换、改进等,均应包含在本文件的权利要求范围之内。

相关技术
  • 一种四足探测器静步态规划系统
  • 信道的选择方法、装置、网关及计算机可读存储介质
技术分类

06120116553925