分布式数据库的数据操作请求处理方法及装置技术领域
本申请涉及分布式数据库领域，尤其涉及分布式数据库的数据操作请求处理方法
及装置。
背景技术
为了解决单级数据库的扩容问题，分布式数据库作为一种解决方法被广泛采用。
相对于传统人工分库分表的数据库部署，分布式数据库提供了数据分区的功能以支持数据
横向扩展。
分布式数据库可以使用由多个独立节点组成、节点间采用网络互联的计算机集群
实现数据库的分布式存储、计算等功能。分布式数据库可以使用相互独立的计算节点，则同
一张数据表的不同数据可以根据分区策略被分配到不同的节点进行存储，考虑到网络时延
和带宽原因，跨节点的数据操作效率一般远小于节点内部的数据操作效率，为了保证分布
式数据库的高效运行，针对不同数据的数据操作请求需要被尽可能地路由到其对应的存储
节点，其中，数据操作请求可以是诸如结构化查询语言(Structured Query Language，SQL)
请求等可用于请求操作分布式数据库中数据的请求。
在现有技术中，由于分布式数据库的分区规则的复杂性，数据操作请求路由往往
通过少量的服务器(称为路由代理服务器)集中部署。具体地，分布式数据库对应的客户端
可以与路由代理服务器建立会话并发出数据操作请求，路由代理服务器接收到数据操作请
求后，根据数据操作请求所依赖的数据分区，将数据操作请求转发到该分区所处节点进行
处理，由于处理结果也需要路由代理服务器转发回到客户端。
但是，由于路由代理服务器往往只有少数机器组成，其接受数据处理请求的吞吐
量较小，从而导致数据操作请求路由效率低。
发明内容
本申请实施例提供分布式数据库的数据操作请求处理方法及装置，用以解决现有
技术中分布式数据库的数据操作请求路由方式效率低的问题。
本申请实施例采用下述技术方案：
本申请实施例提供的一种分布式数据库的数据操作请求处理方法，包括：
客户端接收数据操作请求，所述数据操作请求中包含其所请求操作的数据对应的
关键字和数据表的表名；
所述客户端根据所述关键字和所述表名，当确定所述数据表为分区表时，获取与
所述数据操作请求和所述分区表对应的分区策略；
所述客户端根据所述分区策略，将所述数据操作请求发送给所述数据操作请求所
请求操作的数据所处的服务器。
本申请实施例提供的一种分布式数据库的数据操作请求处理装置，所述装置位于
客户端，包括：
第一接收模块，接收数据操作请求，所述数据操作请求中包含其所请求操作的数
据对应的关键字和数据表的表名；
第一获取模块，根据所述关键字和所述表名，当确定所述数据表为分区表时，获取
与所述数据操作请求和所述分区表对应的分区策略；
发送模块，根据所述分区策略，将所述数据操作请求发送给所述数据操作请求所
请求操作的数据所处的服务器。
本申请实施例提供的另一种分布式数据库的数据操作请求处理方法，包括：
服务端接收客户端发送的数据操作请求，所述数据操作请求中包含其所请求操作
的数据对应的关键字和数据表的表名，所述数据表为分区表；
所述服务端根据所述关键字和所述表名，获取与所述数据操作请求和所述分区表
对应的分区策略；
所述服务端将所述分区策略返回给所述客户端，以便于所述客户端根据所述分区
策略，将所述数据操作请求发送给所述数据操作请求所请求操作的数据所处的服务器。
本申请实施例提供的另一种分布式数据库的数据操作请求处理装置，所述装置位
于服务端，包括：
第二接收模块，接收客户端发送的数据操作请求，所述数据操作请求中包含其所
请求操作的数据对应的关键字和数据表的表名，所述数据表为分区表；
第二获取模块，根据所述关键字和所述表名，获取与所述数据操作请求和所述分
区表对应的分区策略；
返回模块，将所述分区策略返回给所述客户端，以便于所述客户端根据所述分区
策略，将所述数据操作请求发送给所述数据操作请求所请求操作的数据所处的服务器。
本申请实施例提供的再一种分布式数据库的数据操作请求处理方法，包括：客户
端接收数据操作请求，所述数据操作请求中包含其所请求操作的数据对应的关键字和数据
表的表名；
所述客户端对所述数据操作请求进行解析，获得所述表名；
所述客户端根据所述表名，当确定所述数据表为分区表时，对所述数据操作请求
进行参数化处理，获得所述关键字；
所述客户端根据所述表名和所述关键字，获取与所述数据操作请求和所述分区表
对应的分区策略；
所述客户端根据所述分区策略，将所述数据操作请求发送给所述数据操作请求所
请求操作的数据所处的服务器。
本申请实施例提供的再一种分布式数据库的数据操作请求处理装置，所述装置位
于客户端，包括：
请求接收模块，收数据操作请求，所述数据操作请求中包含其所请求操作的数据
对应的关键字和数据表的表名；
解析模块，对所述数据操作请求进行解析，获得所述表名；
参数化处理模块，根据所述表名，当确定所述数据表为分区表时，对所述数据操作
请求进行参数化处理，获得所述关键字；
分区策略第一获取模块，根据所述表名和所述关键字，获取与所述数据操作请求
和所述分区表对应的分区策略；
请求转发模块，根据所述分区策略，将所述数据操作请求发送给所述数据操作请
求所请求操作的数据所处的服务器。
本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：将原来由少
数服务器完成的数据操作请求路由工作，转移至由分布式数据库中的各客户端完成，由各
客户端对数据操作请求进行转发，从而可以提高接收数据处理请求的吞吐量，提高数据操
作请求路由效率，因此，可以部分或全部地解决现有技术中的问题。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申
请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本申请实施例提供的一种分布式数据库的数据操作请求处理方法的流程示
意图；
图2为本申请实施例提供的另一种分布式数据库的数据操作请求处理方法的流程
示意图；
图3为本申请实施例提供的再一种分布式数据库的数据操作请求处理方法的流程
示意图；
图4为本申请实施例提供的在一种实际应用场景下，分布式数据库的数据操作请
求处理方法对应的一种系统结构示意图；
图5为本申请实施例提供的在一种实际应用场景下，分布式数据库的数据操作请
求处理方法的详细流程示意图；
图6为本申请实施例提供的对应于图1的分布式数据库的数据操作请求处理装置
结构示意图；
图7为本申请实施例提供的对应于图2的分布式数据库的数据操作请求处理装置
结构示意图；
图8为本申请实施例提供的对应于图3的分布式数据库的数据操作请求处理装置
结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及
相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一
部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做
出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
本申请的方案的核心思想是：通过客户端与服务端的动态交互，以及客户端上保
存(为了提高速度，具体可以保存在相应的缓存中)的服务于数据操作请求路由过程的相关
数据，实现基于复杂分区规则的全自动数据操作请求路由过程。需要说明的是，本申请中提
到的“路由”均是指分布式数据库的数据操作请求的路由，而非一般理解的IP数据包的路
由。
在本申请实施例中，分布式数据库中可以有两类数据表。第一类是未分区表，对于
一张未分区表，其可以存储在分布式数据库中的某一台设备上；第二类是分区表，分区表被
拆分为至少两部分(每一部分可以称为一个分区)，不同分区一般分别处于分布式数据库中
的不同的设备上，和/或分别处于分布式数据库中的某一台设备的不同存储区域中，其中，
用于存储数据表的设备一般为作分布式数据库中的各服务器。在实际应用中，涉及未分区
表或分区表的数据操作请求都有可能需要在分布式数据库中进行路由，不同之处在于涉及
分区表的数据操作请求路由更加复杂，因为，涉及同一张分区表的不同数据操作请求所请
求操作的数据可能处于不同的服务器上，则不同数据操作请求相应地可能会被转发至不同
的服务器进行处理。
本申请的方案对于这两类数据表均是适用的，需要说明的是，在分区表的场景下，
尤其能体现出本申请的方案相比于现有技术的优点。因此，以下主要是以基于分区表的场
景进行说明的。
下面分别从客户端、服务端的角度对本申请的方案进行详细说明。
图1为本申请实施例提供的一种分布式数据库的数据操作请求处理方法的流程示
意图。
图1中的流程的执行主体可以是分布式数据库对应的客户端(以下简称为：客户
端)。其中，分布式数据库可以对应多个客户端以及多个服务端，每个客户端可以有其对应
的至少一个服务端。本申请对搭载客户端或服务端的设备并不做限定，以下仅列举一些设
备作为示例，比如，个人计算机、大中型计算机、计算机集群、手机、平板电脑、智能手表、车
载移动台等。
图1中的流程可以包括以下步骤：
S101：客户端接收数据操作请求，所述数据操作请求中包含其所请求操作的数据
对应的关键字和数据表的表名。
在本申请实施例中，所述数据操作请求可以是：诸如SQL请求等可用于请求操作分
布式数据库中数据的请求。所述数据操作请求可以是分布式数据库的用户所发送的。
所述关键字可以为数据库记录中包含的键值对中的“键(key)”。以某数据操作请
求为有如下SQL语句为例：
select*from t1where c1＝1and c2＝2。
该数据操作请求中包含的其所请求操作的数据对应的关键字为“c1”和“c2”，其所
请求操作的数据对应的数据表的表名为“t1”。
S102：所述客户端根据所述关键字和所述表名，当确定所述数据表为分区表时，获
取与所述数据操作请求和所述分区表对应的分区策略。
在本申请实施例中，客户端在接收到数据操作请求后，可以判断数据操作请求所
请求操作的数据对应的数据表是否为分区表；若是，则可以执行步骤S102；否则，可以直接
根据数据操作请求所请求操作的数据对应的数据表的表名，查询该数据表所处的服务器，
进而将数据操作请求发送至该数据表所处的服务器(也即，对于对应的数据表为非分区表
的数据操作请求的路由过程)。
客户端和/或客户端的服务端上可以预先保存有分布式数据库中的分区表的分区
表模式信息，基于分区表模式信息，客户端可以判断数据操作请求所请求操作的数据对应
的数据表是否为分区表，其中，分区表模式信息可以用于表明对应的分区表是采用哪种分
区模式进行分区的，分区模式可以包括范围(range)分区模式、哈希(hash)分区模式等。
以实际应用中的某分区表为例，假定该分区表记作t1＝(c1int，c2int，c3int)，采
用hash分区模式，其中，c1、c2、c3均为t1的列名，数值类型为整型。这些信息可以包含在t1
对应的分区表模式信息中，需要说明的是，该例中只是对分区表模式信息进行了示例性说
明，并非是对分区表模式信息所包含内容的限定，只要根据分区表模式信息包含的内容足
以判断t1是否为分区表即可。
需要说明的是，在实际应用中，可以用于判断数据操作请求所请求操作的数据对
应的数据表是否为分区表的依据并不限于分区表模式信息，所述依据还可以是用于表明对
应的数据表是否为分区表的标记信息等，标记信息可以携带在数据表的表名中，等等。
在本申请实施例中，不同的数据操作请求包含的关键字可以不同，不同的数据操
作请求对包含的各关键字的取值限定情况也可以不同，相应地可以导致不同的数据操作请
求所请求操作的数据也不同，可能属于不同的分区。步骤S102中所述的与所述数据操作请
求和所述分区表对应的分区策略可以指：可用于确定所述数据操作请求所请求操作的数据
属于所述分区表划分出的哪个分区的策略。
S103：所述客户端根据所述分区策略，将所述数据操作请求发送给所述数据操作
请求所请求操作的数据所处的服务器。
在本申请实施例中，客户端根据分区策略以及数据操作请求，可以确定数据操作
请求所请求操作的数据属于分区表划分出的哪个分区，进而，可以根据该分区的相关信息，
确定该分区所处服务器(也即，数据操作请求所请求操作的数据所处的服务器)的地址，并
将数据操作请求发送给该服务器，以便于该服务器对响应于接收到的数据操作请求，对数
据操作请求所请求操作的的数据执行相应的操作。
通过图1中的方法，可以将原来由少数服务器完成的数据操作请求路由工作，转移
至由分布式数据库中的各客户端完成，由各客户端对数据操作请求进行转发，从而可以提
高接收数据处理请求的吞吐量，提高数据操作请求路由效率，因此，可以部分或全部地解决
现有技术中的问题。
基于图1中的方法，本申请实施例还提供了图1中的方法的一些具体实施方案，以
及扩展方案，下面进行说明。
在本申请实施例中，前面已经提到，可以根据分区表模式信息或标记信息等判断
数据操作请求所请求操作的数据对应的数据表是否为分区表，由于分区表模式信息在后续
步骤的实施过程中还可以有其他用途，因此，以分区表模式信息作为判断依据即可，一般无
需采用标记信息。
在这种情况下，对于步骤S102，所述客户端根据所述关键字和所述表名，当确定所
述数据表为分区表时，获取与所述数据操作请求和所述分区表对应的分区策略，具体可以
包括：所述客户端对所述数据操作请求进行解析，获得所述表名；所述客户端根据所述表
名，在所述客户端上保存的分区表模式信息和/或所述客户端的服务端上保存的分区表模
式信息中进行查询，以确定所述数据表是否为分区表；若是，对所述数据操作请求进行参数
化处理，获得所述关键字，并根据所述关键字和所述表名，获取与所述数据操作请求和所述
分区表对应的分区策略。。
分区表模式信息与分区表的表名可以是一一对应的，则客户端对数据操作请求进
行解析时，至少可以解析出数据操作请求中包含的表名，确定出了表名即确定出了数据操
作请求所请求操作的数据对应的数据表。
进一步地，客户端上保存的分区表模式信息与所述客户端的服务端上保存的分区
表模式信息可以不完全一致，客户端上保存的分区表模式信息可以是源于客户端的服务端
的。
在这种情况下，上述的所述客户端根据所述表名，在所述客户端上保存的分区表
模式信息和/或所述客户端的服务端上保存的分区表模式信息中进行查询，以确定所述数
据表是否为分区表，具体可以包括：所述客户端根据所述表名，在所述客户端上保存的分区
表模式信息中进行查询，以确定所述客户端上保存的分区表模式信息是否包含所述数据表
对应的分区表模式信息；若是，根据所述客户端上保存的分区表模式信息，确定所述数据表
是否为分区表；否则，根据所述表名，在所述客户端的服务端上保存的分区表模式信息中查
询，以确定所述数据表是否为分区表，以及若查询获得所述数据表对应的分区表模式信息，
将所述数据表对应的分区表模式信息保存至所述客户端上，如此，客户端以后可以直接使
用该分区表模式信息，而无需再从服务端获取，可以提高效率。
在本申请实施例中，根据对于步骤S102的说明可知，不同的数据操作请求及分区
表对应的分区策略也可能不同，则分区策略可能有多种。这些分区策略可以部分或全部地
保存在客户端的服务端上，也可以部分或全部地保存在客户端上。则对于步骤S102，获取与
所述数据操作请求和所述分区表对应的分区策略，具体可以包括：所述客户端根据所述关
键字和所述表名，从所述客户端和/或所述客户端的服务端，获取与所述数据操作请求和所
述分区表对应的分区策略。
进一步地，客户端上保存的分区策略可以是源于客户端的服务端的，保存的各分
区策略可以分别与一个或多个参数化(或者，也可以称为模板化)的数据操作请求建立有对
应关系，其中，每个参数化的数据操作请求可以反映某一个或某一类数据操作请求包含的
关键字以及关键字的取值限定情况等，每一类数据操作请求参数化处理结果可以是相同
的，参数化处理结果至少可以包括数据操作请求包含的关键字。
在这种情况下，上述的所述客户端根据所述关键字和所述表名，从所述客户端和/
或所述客户端的服务端，获取与所述数据操作请求和所述分区表对应的分区策略，具体可
以包括：所述客户端根据所述关键字和所述表名，确定所述客户端上保存的分区策略中是
否包含与所述数据操作请求和所述分区表对应的分区策略；若是，从所述客户端获取与所
述数据操作请求和所述分区表对应的分区策略；否则，从所述客户端的服务端上的保存的
分区策略中获取与所述数据操作请求和所述分区表对应的分区策略，以及将与所述数据操
作请求和所述分区表对应的分区策略保存至所述客户端上，如此，客户端以后可以直接使
用该分区策略，而无需再从服务端获取，可以提高效率。其中，所述关键字和所述表名是客
户端通过对所述数据操作请求进行解析和参数化处理而获得的。
进一步地，若客户端从服务端获取分区策略，服务端也需要获得数据操作请求或
数据操作请求相关的信息才能够确定对应的分区策略，因此，上述的从所述客户端的服务
端获取与所述数据操作请求和所述分区表对应的分区策略，具体可以包括：所述客户端将
所述数据操作请求发送给所述客户端的服务端，以使所述客户端的服务端根据所述数据操
作请求包含的所述关键字和所述表名，确定与所述数据操作请求和所述分区表对应的分区
策略并返回给所述客户端。
客户端向服务端发送数据操作请求时，可以仅发送数据操作请求本身，也可以将
数据操作请求携带在其他请求(比如查询请求等)中，再将其他请求发送给服务端，总之，只
要使得服务端可以获得该数据操作操作请求即可。
以所述其他请求为虚拟表查询请求为例，上述的所述客户端将所述数据操作请求
发送给所述客户端的服务端，具体可以包括：所述客户端将携带所述数据操作请求的虚拟
表查询请求发送给所述客户端的服务端，以使所述服务端通过对应的虚拟表，确定与所述
数据操作请求和所述分区表对应的分区策略并返回给所述客户端。这种方式的优点是：可
以利用已有的数据库查询接口从服务端获取分区策略，而无需专门定义用于获取分区策略
的应用程序接口，可以节省成本，避免使用定制远程过程调用协议(Remote Procedure
Call Protocol，RPC)，也可以增加方案的灵活性和通用性。
在本申请实施例中，客户端在获取分区策略后，可以确定数据操作请求所请求操
作的数据所处分区，进而确定该分区所处服务器。一种实施方式如下：
对于步骤S103，所述客户端根据所述分区策略，将所述数据操作请求发送给所述
数据操作请求所请求操作的数据所处的服务器，具体可以包括：所述客户端根据所述分区
策略以及所述关键字，确定所述数据操作请求所请求操作的数据所处分区的分区物理标
识；根据所述分区物理标记，在保存的分区物理位置信息中确定所述分区物理标记对应的
分区物理位置信息；根据所述分区物理标记对应的分区物理位置信息，确定所述数据所请
求操作的数据所处的服务器的地址，并将所述数据操作请求发送给所述服务器。
在本申请实施例中，当分区为hash分区时，可以根据数据操作请求的参数以及获
得的分区策略，直接计算出分区物理标识，而当分区为range分区时，还需要获取用于表明
range分区的范围的信息，该信息一般包含在分区表模式信息中。则当所述分区为范围
range分区时，上述的所述客户端所述分区策略以及所述关键字，确定所述数据操作请求所
请求操作的数据所处分区的分区物理标识，具体可以包括：所述客户端获取所述分区表对
应的分区表模式信息；所述客户端根据所述分区表对应的分区表模式信息、所述分区策略
以及所述关键字，确定所述数据操作请求所请求操作的数据所处分区的分区物理标识；其
中，所述分区表模式信息包含用于表明所述range分区的范围的信息。
进一步地，上述的分区物理位置信息可以保存在客户端上和/或客户端的服务端
上，客户端上保存的分区物理位置信息可以源于服务端。
在本申请实施例中，根据上面的说明可知，客户端上可以保存部分或全部用于实
现数据操作请求路由的信息，比如，分区策略、分区表模式信息、分区物理位置信息等。在实
际应用中，可以将这些信息存储在客户端上的缓存(cache)中，以实现对这些信息的高速读
写，从而可以提高本申请的方案的效率。具体地，所述客户端上保存的分区策略和/或分区
表模式信息和/或分区物理位置信息可以分别保存在对应的缓存中，这些信息中的部分或
全部可以分别保存在自己独占的缓存中，也可以保存在共用缓存中。
上面从客户端角度对本申请的方案进行了说明。基于同样的思路，本申请实施例
还提供了另一种分布式数据库的数据操作请求处理方法，是从服务端角度出发的，下面进
行说明。
图2为本申请实施例提供的另一种分布式数据库的数据操作请求处理方法的流程
示意图。
图2中的流程的执行主体可以是分布式数据库对应的服务端。
图2中的流程可以包括以下步骤：
S201：服务端接收客户端发送的数据操作请求，所述数据操作请求中包含其所请
求操作的数据对应的关键字和数据表的表名，所述数据表为分区表。
S202：所述服务端根据所述关键字和所述表名，获取与所述数据操作请求和所述
分区表对应的分区策略。
S203：所述服务端将所述分区策略返回给所述客户端，以便于所述客户端根据所
述分区策略，将所述数据操作请求发送给所述数据操作请求所请求操作的数据所处的服务
器。
通过图2中的方法，可以将原来由少数服务器完成的数据操作请求路由工作，转移
至由分布式数据库对应的各客户端完成，由各客户端对数据操作请求进行转发，从而可以
提高接收数据处理请求的吞吐量，提高数据操作请求路由效率，因此，可以部分或全部地解
决现有技术中的问题。
基于图2中的方法，本申请实施例还提供了图2中的方法的一些具体实施方案，以
及扩展方案，下面进行说明。
在本申请实施例中，对于步骤S201，服务端接收客户端发送的数据操作请求，具体
可以包括：服务端接收客户端发送的携带数据操作请求的虚拟表查询请求。
进一步地，对于步骤S202，所述服务端根据所述数据操作请求，确定与所述数据操
作请求和所述分区表对应的分区策略，具体可以包括：所述服务端响应于所述虚拟表查询
请求，通过对应的虚拟表对所述数据操作请求进行解析，确定与所述数据操作请求和所述
分区表对应的分区策略。
在本申请实施例中，对于步骤S203，所述服务端将所述分区策略返回给所述客户
端，具体可以包括：所述服务端将所述分区策略序列化；所述服务端将序列化的分区策略返
回给所述服务端，以便于所述客户端对所述序列化的分区策略反序列化后使用。对分区策
略序列化的原因是为了便于通过已有的查询接口返回分区策略，而无需专门定义用于返回
分区策略的应用程序接口。当然，在实际应用中，即使不对分区策略序列化，服务端仍然可
以实现将分区策略返回给客户端，本申请对具体的返回方式并不做限定，将分区策略序列
化后返回仅是返回方式的一种示例。
本申请实施例还提供了再一种分布式数据库的数据操作请求处理方法的流程示
意图，如图3所示，是对图1中流程进一步的细化。
图3中的流程可以包括以下步骤：
S301：客户端接收数据操作请求，所述数据操作请求中包含其所请求操作的数据
对应的关键字和数据表的表名。
S302：所述客户端对所述数据操作请求进行解析，获得所述表名。
S303：所述客户端根据所述表名，当确定所述数据表为分区表时，对所述数据操作
请求进行参数化处理，获得所述关键字。
S304：所述客户端根据所述表名和所述关键字，获取与所述数据操作请求和所述
分区表对应的分区策略。
S305：所述客户端根据所述分区策略，将所述数据操作请求发送给所述数据操作
请求所请求操作的数据所处的服务器。
上面分别从客户端、服务端对本申请的方案进行了说明。本申请实施例还提供了
在一种实际应用场景下，分布式数据库的数据操作请求处理方法对应的一种系统结构示意
图，以及对应的数据操作请求处理方法的详细流程示意图，如图4、图5所示。
图4为本申请实施例提供的在一种实际应用场景下，分布式数据库的数据操作请
求处理方法的详细流程示意图。
在图4中，上述的数据操作请求具体可以为SQL请求，上述的分区策略具体可以为
分区计算公式，需要说明的是，在实际应用中，分区策略也可以是公式形式以外的其他形式
的信息。
客户端中包含有：
SQL请求快速参数化模块，用于对接收到的SQL请求进行参数化处理，参数化处理
结果包括但不限于该SQL请求中的关键字；
SQL请求分区计算公式缓存，用于保存分区计算公式；
分区表模式缓存，用于保存分区表模式信息；
分区物理位置缓存，用于保存分区物理位置信息。
服务端中包含有：
分区计算公式虚拟表，用于处理客户端发送的分区计算公式虚拟表查询请求；
SQL请求解析模块，用于解析分区计算公式虚拟表查询请求中携带的SQL请求，以
便于确定与该SQL请求对应的分区计算公式；
分区表模式记录，用于保存分区表模式信息，以及向客户端提供客户端上尚未保
存的分区表模式信息。
图5为本申请实施例提供的在一种实际应用场景下，分布式数据库的数据操作请
求处理方法的详细流程示意图。
图5中的详细流程可以概括为以下七个步骤：
步骤一：客户端接收用户发送的SQL请求，首先利用SQL请求快速参数化模块对SQL
请求涉及的表名进行解析，以判断SQL请求对应的数据表是否为分区表，如果不是分区表，
则可以直接查询分区物理标识(比如，可以将非分区表的分区ID统一设置为0)，如果是分区
表，则进入步骤二。
步骤二：客户端利用通过步骤一得到的参数化处理后的SQL请求，查询SQL请求分
区计算公式缓存，如果命中，则进入步骤四，如果未命中，则进入步骤三。
步骤三：客户端通过发送SQL请求，查询服务端的分区计算公式虚拟表，服务端在
接收到请求后，驱动SQL请求解析模块，解析请求并将SQL请求对应的分区计算公式序列化，
通过结果集合返回给客户端。
步骤四：客户端利用服务端返回的分区计算公式，将其反序列化，再结合SQL请求
的参数，计算分区信息，并可以将该分区计算公式保存在SQL请求分区计算公式缓存中以便
于以后使用。其中，如果SQL请求对应的分区是hash分区，则可以直接计算出分区物理标识，
如果是range分区，则进入步骤五。
步骤五：客户端查询range分区表模式缓存，如果命中，则进入步骤七，如果未命
中，则进入步骤六。
步骤六：客户端查询服务端的分区表模式记录，并通过服务端返回的结果，计算分
区物理标识。
步骤七：客户端通过计算得到的分区物理标识，查询分区物理位置缓存，找到所在
的服务器的地址，并将用户的SQL请求转发至该服务器。
为了进一步地帮助理解本申请的方案，基于以上概括出的步骤，以下还提供了3个
更具体的应用实例，下面分别进行说明。
实例一：
假设分区表为t1(c1int，c2int，c3int)，其中，分区模式为hash，分区键为c1+c2，
分区个数为256个。
客户端当接收到用户的如下SQL请求：
select*from t1where c1＝1and c2＝2；
步骤一中，利用SQL请求快速参数化模块解析出SQL请求涉及的表名为“t1”，通过
查询分区模式表缓存可知t1为分区表，进入步骤二。
步骤二中，假定SQL请求分区计算公式缓存中无对应的记录，则进入步骤三。
步骤三中，假定服务端的分区计算公式虚拟表为proxy_route，客户端可以向服务
端发送如下虚拟表查询请求：
select partition_type,partition_cnt,partition_calc_formula from
proxy_route where sql_string＝‘select*from t1where c1＝1and c2＝2’；
其中，“partition_type”表示分区模式，“partition_cnt”表示分区个数，
“partition_calc_formula”表示分区计算公式。
服务器端通过解析该请求，对应地返回类似如下的结果：
‘hash’，256，‘0100010111010….’；
‘0100010111010….’即为对应于用户的SQL请求的分区计算公式，在此场景下也
可以将其理解为：‘@1+@2’。其中@1为快速参数化的第一个关键字，此例中为c＝1中的1，@2
为第二个关键字，即为c2＝2中的2。该分区计算公式的内容依赖于快速参数化所得到的关
键字列表，因此对于不同SQL请求会有所不同。
步骤四中，服务器端通过计算‘@1+@2’，即‘1+2’得到3，并调动内建hash函数计算
得到hash值，例如假定计算得到的hash为300，然后通过hash分区物理标识的计算规则，即
300取模256，得到分区物理标识为44。
进入到步骤七(并非是range分区，因此，无需执行步骤五、步骤六)，假设分区表的
第44号分区的物理位置缓存为18.220.2.25，则将该请求转发到地址为18.220.2.25的服务
器上。
另外，步骤三得到的分区计算表达式可以保存在客户端的分区计算公式缓存中，
则客户端再次收到形式相同但关键字不同的请求后，例如select*from t1where c1＝5and
c2＝7，则会命中该缓存，并利用公式计算出5+7＝12，进而执行步骤四之后的过程。
实例二：
客户端当接收到用户的如下SQL请求：
select*from t1where t1＝1and t3＝2and t2＝4；
由于该SQL请求不同于实例一中的请求，无法命中分区计算式缓存，需要重新发送
到服务端解析，解析后的分区表达式也不同于上例中的‘@1+@2’,而是变为‘@1+@3’，客户端
根据新的分区计算公式计算出1+4＝5，并重复对应于实例一的后续步骤。在实例一和实例
二发生后，客户端的SQL请求分区计算公式缓存中可以保存有如下表1中的内容：
表1
![]()
实例三：
假定有range分区表t2(c1int，c2int，c3int)，其分区键为c1,分区模式为range分
区模式，具体如下：
“0<c1<＝10→分区0
10<c1<＝20→分区1
20<c1<＝30→分区2
30<c1→分区4”。
客户端当接收到用户的如下SQL请求：
select*from t2where c1＝c2and c3＝4and c2>15and c2<20；
则对应的分区计算表达式可以为(@2，@3)，注意：由于c1与c2相等，则c2的条件自
动等价到c1上。假设此时分区表模式缓存中没有对应的记录，则需要通过步骤五，查询服务
端的分区表模式记录，并将服务端返回的结果保存在分区表模式缓存中，则分区表模式缓
存可以保存有如下表2中的内容：
表2
表名
分区
分区模式
T2
0
(0，10]
T2
1
(10，20]
T2
2
(20，30]
T2
3
(30，40)
通过分区计算公式(@2，@3)，可以得到计算结果落在分区区间(15,20)中，查询可
得1号分区，进而可以执行后续步骤，在此不赘述。
上面对本申请的方案进行了详细说明。下面再对本申请的方案的优点集中总结如
下：
第一，充分利用客户端的缓存，在同一数据操作请求反复出现的场景下避免多次
访问服务端而可以直接计算出分区物理标识，可以加快数据操作请求转发速度；
第二，客户端与服务端直接可以通过分区表模式记录内部表访问所需的分区表模
式信息，减少了对服务端代码的依赖，这样可以大大简化客户端的代码，有利于实现客户端
与服务端的解耦。
第三，通过缓存分区计算表达式，可以处理很多复杂的数据操作请求及复杂的分
区模式，可以提高客户端进行数据操作请求路由的准确率。
第四、客户端可以对缓存策略进行控制，针对不同的内存配置、时延容忍度采用不
同的缓存策略，灵活性较高。
第五、使用通用的虚拟表模式实现客户端与服务端的交互，避免了使用定制RPC，
增加了方案的灵活性和通用性，有利于客户端与服务端相互独立地维护、升级，提高了兼容
性。
以上为本申请实施例提供的分布式数据库的数据操作请求处理方法，基于同样的
思路，本申请实施例还提供相应的分布式数据库的数据操作请求处理装置，如图6、图7、图8
所示。
图6为本申请实施例提供的对应于图1的分布式数据库的数据操作请求处理装置
结构示意图，该装置位于客户端，包括：
第一接收模块601，接收数据操作请求，所述数据操作请求中包含其所请求操作的
数据对应的关键字和数据表的表名；
第一获取模块602，根据所述关键字和所述表名，当确定所述数据表为分区表时，
获取与所述数据操作请求和所述分区表对应的分区策略；
发送模块603，根据所述分区策略，将所述数据操作请求发送给所述数据操作请求
所请求操作的数据所处的服务器。
可选地，第一获取模块602，对所述数据操作请求进行解析，获得所述表名，根据所
述表名，在所述客户端上保存的分区表模式信息和/或所述客户端的服务端上保存的分区
表模式信息中进行查询，以确定所述数据表是否为分区表，若是，对所述数据操作请求进行
参数化处理，获得所述关键字，并根据所述关键字和所述表名，获取与所述数据操作请求和
所述分区表对应的分区策略。
可选地，第一获取模块602，根据所述表名，在所述客户端上保存的分区表模式信
息中进行查询，以确定所述客户端上保存的分区表模式信息是否包含所述数据表对应的分
区表模式信息，若是，根据所述客户端上保存的分区表模式信息，确定所述数据表是否为分
区表，否则，根据所述表名，在所述客户端的服务端上保存的分区表模式信息中查询，以确
定所述数据表是否为分区表，以及若查询获得所述数据表对应的分区表模式信息，将所述
数据表对应的分区表模式信息保存至所述客户端上。
可选地，第一获取模块602，根据所述关键字和所述表名，从所述客户端和/或所述
客户端的服务端，获取与所述数据操作请求和所述分区表对应的分区策略。
可选地，第一获取模块602，根据所述关键字和所述表名，确定所述客户端上保存
的分区策略中是否包含与所述数据操作请求和所述分区表对应的分区策略，若是，从所述
客户端获取与所述数据操作请求和所述分区表对应的分区策略，否则，从所述客户端的服
务端获取与所述数据操作请求和所述分区表对应的分区策略，以及将与所述数据操作请求
和所述分区表对应的分区策略保存至所述客户端上。
可选地，第一获取模块602，将所述数据操作请求发送给所述客户端的服务端，以
使所述客户端的服务端根据所述数据操作请求包含的所述关键字和所述表名，确定与所述
数据操作请求和所述分区表对应的分区策略并返回给所述客户端。
可选地，第一获取模块602，将携带所述数据操作请求的虚拟表查询请求发送给所
述客户端的服务端，以使所述服务端通过对应的虚拟表，确定与所述数据操作请求和所述
分区表对应的分区策略并返回给所述客户端。
可选地，发送模块603，根据所述分区策略以及所述关键字，确定所述数据操作请
求所请求操作的数据所处分区的分区物理标识，根据所述分区物理标记，在保存的分区物
理位置信息中确定所述分区物理标记对应的分区物理位置信息，根据所述分区物理标记对
应的分区物理位置信息，确定所述数据所请求操作的数据所处的服务器的地址，并将所述
数据操作请求发送给所述服务器。
可选地，当所述分区为范围range分区时，发送模块603，获取所述分区表对应的分
区表模式信息，根据所述分区表对应的分区表模式信息、所述分区策略以及所述关键字，确
定所述数据操作请求所请求操作的数据所处分区的分区物理标识。
可选地，所述客户端上保存的分区策略和/或分区表模式信息和/或分区物理位置
信息分别保存在对应的缓存中。
图7为本申请实施例提供的对应于图2的分布式数据库的数据操作请求处理装置
结构示意图，该装置位于服务端，包括：
第二接收模块701，接收客户端发送的数据操作请求，所述数据操作请求中包含其
所请求操作的数据对应的关键字和数据表的表名，所述数据表为分区表；
第二获取模块702，根据所述关键字和所述表名，获取与所述数据操作请求和所述
分区表对应的分区策略；
返回模块703，将所述分区策略返回给所述客户端，以便于所述客户端根据所述分
区策略，将所述数据操作请求发送给所述数据操作请求所请求操作的数据所处的服务器。
可选地，第二接收模块701，接收客户端发送的携带数据操作请求的虚拟表查询请
求。
可选地，第二获取模块702，响应于所述虚拟表查询请求，通过对应的虚拟表对所
述数据操作请求进行解析，确定与所述数据操作请求和所述分区表对应的分区策略。
可选地，返回模块703，将所述分区策略序列化，将序列化的分区策略返回给所述
服务端，以便于所述客户端对所述序列化的分区策略反序列化后使用。
图8为本申请实施例提供的对应于图3的分布式数据库的数据操作请求处理装置
结构示意图，该装置位于客户端，包括：
请求接收模块801，收数据操作请求，所述数据操作请求中包含其所请求操作的数
据对应的关键字和数据表的表名；
解析模块802，对所述数据操作请求进行解析，获得所述表名；
参数化处理模块803，根据所述表名，当确定所述数据表为分区表时，对所述数据
操作请求进行参数化处理，获得所述关键字；
分区策略获取模块804，根据所述表名和所述关键字，获取与所述数据操作请求和
所述分区表对应的分区策略；
请求转发模块805，根据所述分区策略，将所述数据操作请求发送给所述数据操作
请求所请求操作的数据所处的服务器。
本申请提供的装置是与本申请提供的方法一一对应的，因此，所述装置也具有与
所述方法类似的有益技术效果，由于上面已经对所述方法的有益技术效果进行了详细说
明，因此，这里不再赘述所述装置的有益技术效果。
本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序
产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实
施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机
可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产
品的形式。
本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程
图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流
程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序
指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产
生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实
现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特
定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指
令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或
多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计
算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或
其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一
个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网
络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或
非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的
示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法
或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。
计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动
态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除
可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、
数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备
或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算
机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的
包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包
括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要
素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要
素的过程、方法、商品或者设备中还存在另外的相同要素。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员
来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同
替换、改进等，均应包含在本申请的权利要求范围之内。