CN106095977A - 一种数据库的分布式处理方法及系统 - Google Patents

Abstract

公开一种数据库的分布式处理方法，业务请求的处理包括步骤：(1)业务请求发送给代理服务器proxy；(2)proxy通过本地缓存的数据库服务器列表，利用路由算法找到一个目标服务器，将请求转发给代表该目标服务器的智能计算体agent；(3)agent通过数据库适配器与目标服务器通讯；(4)处理结果返回agent；(5)agent将处理结果返回proxy；(6)proxy将处理结果返回业务；所述步骤(3)中，agent通过定时与目标服务器通讯，维护目标服务器在分布式任务协调中的键‑值对，该键‑值对包含目标服务器的ip地址及端口；所述步骤(5)中，proxy通过监听分布式任务协调中键‑值对的变化情况，实时维护一个本地缓存数据库列表。还提供数据库的分布式处理系统。

Description

一种数据库的分布式处理方法及系统

技术领域

本发明属于数据库应用的技术领域，具体地涉及一种数据库的分布式处理方法，以及数据库的分布式处理系统。

背景技术

数据库(Database)是按照数据结构来组织、存储和管理数据的仓库。从操作数据的方式上讲，数据库可分为事务型数据库及分析型数据库，事务型数据库可以对数据进行增，删，改操作，一般服务于在线业务；分析型数据库主要用于分析及挖掘数据，一般用于离线业务(数据仓库)。

从存贮或处理的数据结构上讲，数据库还可分为关系型数据库，图数据库，键-值数据库，文档数据库等等，其中关系型数据库还可进一步划分为行式存贮数据库与列式存贮数据库。

现有的数据库分布式技术方案存下如下缺点:

1、现有分布式方案都是专门针对某一特定的数据库,不具可移植性，或可移植性较差。

2、现有的分布式数据库数据拆分方案对性能影响较大。

一般的分布式数据库由于存在数据拆分分散存放问题，在数据定位，数据聚合，分拆等方面开销较大，导致在某些小数据量上，集群性能甚至不如单机性能。

3、现有的数据库分布式方案大都采用master-slave模式,扩展及可维护性都较差，容易造成单点故障。

现有分布式方案一般采用一个master多个slave的模式，容易造成master的单点故障，另外，在master失效的情况下，需要从多个slave中选举新的master，因而还需要一个选举算法，增加了系统的复杂性。

4、现有的分布式数据库方案中，业务与数据库大都紧密绑定，难以移植，灵活性差。

发明内容

本发明的技术解决问题是：克服现有技术的不足，提供一种数据库的分布式处理方法，其通用且可移植性高，保证了聚群性能在任何时候都不会低于单机版性能，不存在master与slave之分，扩展性及可维护性好，灵活性强。

本发明的技术解决方案是：这种数据库的分布式处理方法，业务请求的处理包括以下步骤：

(1)业务请求发送给代理服务器proxy；

(2)proxy通过本地缓存的数据库服务器列表，利用路由算法找到一个目标服务器，将请求转发给代表该目标服务器的智能计算体agent；

(3)agent通过数据库适配器与目标服务器通讯；

(4)处理结果返回agent；

(5)agent将处理结果返回proxy；

(6)proxy将处理结果返回业务；

所述步骤(3)中，agent通过定时与目标服务器通讯，维护目标服务器在分布式任务协调中的键-值对，该键-值对包含目标服务器的ip地址及端口；

所述步骤(5)中，proxy通过监听分布式任务协调中键-值对的变化情况，

实时维护一个本地缓存数据库列表。

更进一步地，所述步骤(3)分布式任务协调器具有临时性动态目录，当服务器启动时，在/cluster目录下注册一个有关服务器信息的键-值对，该键-值对包含该服务器的IP地址及端口，当服务器正常运行时该键-值对存在，如果服务器出现故障或当机则该键-值对消亡，通过扫描分布式任务协调/cluster目录下的所有键-值对信息，得到目前集群中正常运行的服务器的数量。

更进一步地，所述步骤(3)中，agent定时通过数据库适配器维持与数据库的心跳检测，当数据库正常时，agent保持该服务器在分布式任务协调器的某一目录下的键-值对；当检测不正常时，agent删除该服务器在分布式任务协调器中对应的键-值。

更进一步地，所述步骤(2)中的路由算法为流量或者负载均衡方法。

更进一步地，当业务请求为数据事务操作时，所述步骤(3)中，为了保证集群其它服务器数据同步，将事务相关数据写入消息服务器，通过数据同步模块将事务相关数据同步到其他服务器中。

更进一步地，如果数据事务操作失效，则重复再试，或另选其他服务器。

更进一步地，所述同步为：监听消息服务器，当有新的事务相关数据写入时，通过proxy的在线服务器缓存列表取得集群所有在线服务器名单，过滤掉已处理事务的数据库服务器，避免事务重复操作，同时将事务信息推送给集群中的其他服务器。

更进一步地，当业务请求为数据查询操作时，所述步骤(3)中，如果数据事务操作失效，则重复再试，或另选其他服务器。

还提供了一种数据库的分布式处理系统，其包括：

数据库适配器，其配置来与目标服务器通讯；

智能计算体agent，其配置来通过数据库适配器与目标服务器通讯，接收目标服务器的处理结果，将处理结果返回proxy；

代理服务器proxy，其配置来接收业务请求，通过本地缓存的数据库服务器列表，利用路由算法找到一个目标服务器，将请求转发给代表该目标服务器的智能计算体agent，并将处理结果返回业务；

其中，agent通过定时与目标服务器通讯，维护目标服务器在分布式任务协调中的键-值对，该键-值对包含目标服务器的ip地址及端口；proxy通过监听分布式任务协调中键-值对的变化情况，实时维护一个本地缓存数据库列表。

更进一步地，该处理系统还包括：

消息服务器，其配置来顺序保存待同步的事务消息；

数据同步模块，其配置来监听消息服务器，当有新的事务相关数据写入时，数据同步模块通过proxy的在线数据库缓存列表取得集群所有在线数据库名单，过滤掉已处理事务的数据库，避免事务重复操作，同时将事务信息推送给集群中的其他数据库。

本发明通过agent与数据库适配器结合，封装了底层数据库细节，agent通过定时与目标服务器通讯，维护目标服务器在分布式任务协调中的键-值对，该键-值对包含目标服务器的ip地址及端口；proxy通过监听分布式任务协调中键-值对的变化情况，实时维护一个本地缓存数据库列表；使业务不需关心具体数据库实现，大大提升灵活性及可移植性，不仅适用于图数据库，也可适用一般事务型数据库及分析型数据库，通用性好；本发明因为不需要数据拆分，从而保证了聚群性能在任何时候都不会低于单机版性能；本发明采用无中心化设计，所有节点同等对待，不存在master与slave之分，扩展性及可维护性好；本发明业务与数据库无需紧密绑定，易于移植，灵活性强。

附图说明

图1为根据本发明的数据库的分布式处理方法的流程图；

图2为根据本发明的系统运行状态集群数据库注册及动态监听时的流程示意图；

图3为根据本发明的proxy加载及监控在线服务器列表时的流程示意图；

图4为根据本发明的当业务请求为数据事务操作时的流程示意图；

图5为根据本发明的数据同步时的流程示意图；

图6为根据本发明的当业务请求为数据查询操作时的流程示意图；

图7为根据本发明的数据库的分布式处理系统的整体结构示意图。

具体实施方式

从存贮或处理的数据结构上讲，数据库还可分为关系型数据库，图数据库，键-值数据库，文档数据库等等，其中关系型数据库还可进一步划分为行式存贮数据库与列式存贮数据库。

图论是图数据库的理论基础，图是计算机科学中较常用的一类抽象数据结构，在结构和语义方面比线性表和树更为复杂，更具有一般性表示能力，可以认为图数据是点，线，树的集合。

与传统的关系型数据库相比，图数据库具有如下特点或优势：

1).图数据库更擅长存储具有联接关系的网状数据结构；

2).图数据库可轻易处理十亿级以上的节点，百亿以上的关系；

3).图数据库在涉及路径计算与迭代方面有较大优势；

图数据库在互联网及社交网络等方面有广泛应用，构成图数据的最核心要素有两个：点(Vertex)，边(edge)，点对应互联网中的单个网页，或社交网络中的单个人；边可类比于网页之间的链接指向以及社交网络中的好友关系。边有方向性，包含三种状态：单向，双向，无向。边也可附带权重属性，表示重要程度。

图存贮与图计算是图数据库的两大核心，图存贮包括图查询(图遍历)，往往需要事务性支持；图计算如pagerank算法，最短路径算法，疾病趋势分析等，因为涉及迭代运算，一般需要在内存中运行，因此图计算不考虑数据的物理存储及事务因素，图计算属于分析型数据库。本专利主要关注事务型图数据库，但也普遍适用于一般的事务型数据库，如键-键数据库,文档数据库，关系型数据库等等。

分布式事务型数据库的数据一致性分为两种：强一致性与最终一致性。所谓强一致性，就是对数据的任何事务操作(增，删，改),在后续查询时立即可见，而弱一致性则充许在数据事务操作后，在有限的一段时间内，后续查询数据可以不一致。强一致性多用于银行，保险，电力等行业，对性能有较大影响，而最终一致性在互联网行业有广泛的应用，最终一致性一般比强一致性有更好的性能。

关于CAP理论。

CAP理论在互联网界有着广泛的知名度，CAP理论包括三原则：

C(Consistency，数据一致性)：分布式系统中数据时刻保持同步；

A(Availability，可用性)：分布式系统随时可用；

P(Partition tolerance，分区容错)：支持分布式。

根据CAP理论，以上三原则只能同时满足二种，牺牲一种。对分布式系统而言，P是必须的，A一般也是必须的，只能牺牲C，所以分布式系统往往通过最终一致性来遵守CAP理论。而要实现强一致性，在不违背CAP理论的原则下，必然需要一些特殊的设计。

相比于传统的关系型数据库，图数据库的分布式有其特殊性，而且难度更大。图数据库由点数据与边数据构成，各种点与边相互关联构成一张大图，因此，如果要实现分布式一种方式就是裁图，将一张大图分割成很多小图分散存放在不同服务器中。这其中涉及几个方面的技术难题，其一是均匀裁图的问题，各小图数据量要大致相同，其二是图分割的问题，是按点分割也是按边分割，各有不同的技术难点，其三是边缘点，边缘边的问题，无论是按点分割还是按边分割，这些边缘点(边)都会涉及交叉计算问题，往往会在各节点重复存放。

另一种数据库分布式思路是不进行数据分割，而是在分布式系统中各服务器里分别保存一份同样的大图，这在很多业务场景中有其合理性，因为对图数据库而言，由于其数据结构的特殊性，单节点服务器就可以轻松存贮及处理具有数十亿点与边关系的图数据，理论上，只要内存足够大，单节点图数据库可以轻松存贮及处理千亿左右的图数据。

目前，开源的图数据库基本不提供分布式支持，某些商业版虽然也有集群功能，但都是针对已身的解决方案，在源码级支持，不具可移植性，且一般不提供强一致性事务支持。

事务型关系数据库有多种实现方式，比如Oracle RAC通过共享存贮实现了分布式，集群实际上是共用一份数据，并不是真正的分布式；mysql数据库通过前端proxy路由也实现了数据分区及读写分离技术，由于存在数据分拆与合并的过程，对性能影响较大，可维护性，可伸缩性都较差。以上两种分布式方案都是针对专门的数据库，不具可移植性。

根据CAP法则，事务型数据库在同时满足高可用性，分区容忍的条件下，不可能实现数据的一致性，因而分布式事务型数据库往往采用最终一致性方案。

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务,集群健康状态维护等。

Zookeeper是本发明中实现数据库分布式方案的核心组件,当然其他分布式协调框架如etcd同样适用本发明。

如图1所示，这种数据库的分布式处理方法，业务请求的处理包括以下步骤：

(1)业务请求发送给代理服务器proxy；

(2)proxy通过本地缓存的数据库服务器列表，利用路由算法找到一个目标服务器，将请求转发给代表该目标服务器的智能计算体agent；

(3)agent通过数据库适配器与目标服务器通讯；

(4)处理结果返回agent；

(5)agent将处理结果返回proxy；

(6)proxy将处理结果返回业务；

所述步骤(3)中，agent通过定时与目标服务器通讯，维护目标服务器在分布式任务协调中的键-值对，该键-值对包含目标服务器的ip地址及端口；

所述步骤(5)中，proxy通过监听分布式任务协调中键-值对的变化情况，实时维护一个本地缓存数据库列表。

本发明通过agent与数据库适配器结合，封装了底层数据库细节，agent通过定时与目标服务器通讯，维护目标服务器在分布式任务协调中的键-值对，该键-值对包含目标服务器的ip地址及端口；proxy通过监听分布式任务协调中键-值对的变化情况，实时维护一个本地缓存数据库列表；使业务不需关心具体数据库实现，大大提升灵活性及可移植性，不仅适用于图数据库，也可适用一般事务型数据库及分析型数据库，通用性好；本发明因为不需要数据拆分，从而保证了聚群性能在任何时候都不会低于单机版性能；本发明采用无中心化设计，所有节点同等对待，不存在master与slave之分，扩展性及可维护性好；本发明业务与数据库无需紧密绑定，易于移植，灵活性强。

更进一步地，所述步骤(3)分布式任务协调器具有临时性动态目录，当服务器启动时，在/cluster目录下注册一个有关服务器信息的键-值对，该键-值对包含该服务器的IP地址及端口，当服务器正常运行时该键-值对存在，如果服务器出现故障或当机则该键-值对消亡，通过扫描分布式任务协调/cluster目录下的所有键-值对信息，得到目前集群中正常运行的服务器的数量。

另外，如图2所示，当系统运行状态集群数据库注册及动态监听时，所述步骤(3)中，agent定时通过数据库适配器维持与数据库的心跳检测，当数据库正常时，agent保持该服务器在分布式任务协调器的某一目录下的键-值对；当检测不正常时，agent删除该服务器在分布式任务协调器中对应的键-值。

图3为根据本发明的proxy加载及监控在线服务器列表时的流程示意图。当业务请求为proxy加载及监控在线服务器列表时，所述步骤(5)中，proxy通过实时监听分布式任务协调器的目录的变化，动态维护本地在线服务器的缓存列表。

另外，所述步骤(2)中的路由算法为流量或者负载均衡方法。

图4为根据本发明的当业务请求为数据事务操作时的流程示意图。当业务请求为数据事务操作时，所述步骤(3)中，为了保证集群其它服务器数据同步，将事务相关数据写入消息服务器，通过数据同步模块将事务相关数据同步到其他服务器中。

更进一步地，如果数据事务操作失效，则重复再试，或另选其他服务器。

如图5所示，所述同步为：监听消息服务器，当有新的事务相关数据写入时，通过proxy的在线服务器缓存列表取得集群所有在线服务器名单，过滤掉已处理事务的数据库服务器，避免事务重复操作，同时将事务信息推送给集群中的其他服务器。

本分布式方案不支持数据的强一致性，符合数据的最终一致性要求。

图6为根据本发明的当业务请求为数据查询操作时的流程示意图。另外，当业务请求为数据查询操作时，所述步骤(3)中，如果数据查询操作失效，则重复再试，或另选其他服务器。

如图7所示，还提供了一种数据库的分布式处理系统，其包括：

数据库适配器，其配置来与目标服务器通讯；

智能计算体agent，其配置来通过数据库适配器与目标服务器通讯，接收目标服务器的处理结果，将处理结果返回proxy；

代理服务器proxy，其配置来接收业务请求，通过本地缓存的数据库服务器列表，利用路由算法找到一个目标服务器，将请求转发给代表该目标服务器的智能计算体agent，并将处理结果返回业务；

其中，agent通过定时与目标服务器通讯，维护目标服务器在分布式任务协调中的键-值对，该键-值对包含目标服务器的ip地址及端口；proxy通过监听分布式任务协调中键-值对的变化情况，实时维护一个本地缓存数据库列表。

更进一步地，该处理系统还包括：

消息服务器，其配置来顺序保存待同步的事务消息；

数据同步模块，其配置来监听消息服务器，当有新的事务相关数据写入时，数据同步模块通过proxy的在线数据库缓存列表取得集群所有在线数据库名单，过滤掉已处理事务的数据库，避免事务重复操作，同时将事务信息推送给集群中的其他数据库。

本发明的技术效果如下：

1.通用性及可移植性好

本方案无需针对具体图数据库，也适用于其他键-值型数据库，关系型数据库，文档型数据库，以及各种分析型数据库。

通过替换不同的数据库适配器就可以支持不同的数据库集群。

2.非侵入式的数据库分布式技术

无需改动数据库源码，无需修改数据库配置信息。

3.集群总吞吐量随服务器数量线性提升

由于没有进行数据拆分，不存在数据的拆分与聚合步骤，集群整体吞吐量与服务器数量成正比。

4.支持负载均衡

通过各种路由算法，将业务流量均匀分摊到集群各服务器中。

5.底层数据库类型对业务安全透明

通过agent及数据库适配器封装，业务无需了解底层数据库细节，因而也不需要专门针对具体数据库设计，大大提高了业务的可移植性及灵活性。

6.无中心化设计

所有数据库服务器完全对等，既支持事务操作，也支持查询操作，因此任何服务器故障都不会影响整个集群运行，哪怕只剩下一台服务器在线。

7.高容错性

故障服务器会自动剔除，新增服务器会自动加入调度列表，只要有一台服务器在线，集群就可以给外部业务提供服务。

以上所述，仅是本发明的较佳实施例，并非对本发明作任何形式上的限制，凡是依据本发明的技术实质对以上实施例所作的任何简单修改、等同变化与修饰，均仍属本发明技术方案的保护范围。

Claims (10)

1.一种数据库的分布式处理方法，其特征在于：业务请求的处理包括以下步骤：

(1)业务请求发送给代理服务器proxy；

(2)proxy通过本地缓存的数据库服务器列表，利用路由算法找到一个目标服务器，将请求转发给代表该目标服务器的智能计算体agent；

(3)agent通过数据库适配器与目标服务器通讯；

(4)处理结果返回agent；

(5)agent将处理结果返回proxy；

(6)proxy将处理结果返回业务；

所述步骤(3)中，agent通过定时与目标服务器通讯，维护目标服务器在分布式任务协调器中的键-值对，该键-值对包含目标服务器的ip地址及端口；

所述步骤(5)中，proxy通过监听分布式任务协调中键-值对的变化情况，实时维护一个本地缓存数据库列表。

2.根据权利要求1所述的数据库的分布式处理方法，其特征在于：所述步骤(3)分布式任务协调器具有临时性动态目录，当服务器启动时，在/cluster目录下注册一个有关服务器信息的键-值对，该键-值对包含该服务器的IP地址及端口，当服务器正常运行时该键-值对存在，如果服务器出现故障或当机则该键-值对消亡，通过扫描分布式任务协调/cluster目录下的所有键-值对信息，得到目前集群中正常运行的服务器的数量。

3.根据权利要求2所述的数据库的分布式处理方法，其特征在于：所述步骤(3)中，agent定时通过数据库适配器维持与数据库的心跳检测，当数据库正常时，agent保持该服务器在分布式任务协调器的某一目录下的键-值对；当检测不正常时，agent删除该服务器在分布式任务协调器中对应的键-值。

4.根据权利要求2所述的数据库的分布式处理方法，其特征在于：所述步骤(2)中的路由算法为流量或者负载均衡方法。

5.根据权利要求4所述的数据库的分布式处理方法，其特征在于：当业务请求为数据事务操作时，所述步骤(3)中，为了保证集群其它服务器数据同步，将事务相关数据写入消息服务器，通过数据同步模块将事务相关数据同步到其他服务器中。

6.根据权利要求5所述的数据库的分布式处理方法，其特征在于：如果数据事务操作失效，则重复再试，或另选其他服务器。

7.根据权利要求5或6所述的数据库的分布式处理方法，其特征在于：所述同步为：监听消息服务器，当有新的事务相关数据写入时，通过proxy的在线服务器缓存列表取得集群所有在线服务器名单，过滤掉已处理事务的数据库服务器，避免事务重复操作，同时将事务信息推送给集群中的其他服务器。

8.根据权利要求4所述的数据库的分布式处理方法，其特征在于：当业务请求为数据查询操作时，所述步骤(3)中，如果数据查询操作失效，则重复再试，或另选其他服务器。

9.一种数据库的分布式处理系统，其特征在于：其包括：

数据库适配器，其配置来与目标服务器通讯；

智能计算体agent，其配置来通过数据库适配器与目标服务器通讯，接收目标服务器的处理结果，将处理结果返回proxy；

代理服务器proxy，其配置来接收业务请求，通过本地缓存的数据库服务器列表，利用路由算法找到一个目标服务器，将请求转发给代表该目标服务器的智能计算体agent，并将处理结果返回业务；

其中，agent通过定时与目标服务器通讯，维护目标服务器在分布式任务协调中的键-值对，该键-值对包含目标服务器的ip地址及端口；proxy通过监听分布式任务协调中键-值对的变化情况，实时维护一个本地缓存数据库列表。

10.根据权利要求9所述的数据库的分布式处理系统，其特征在于：该处理系统还包括：

消息服务器，其配置来顺序保存待同步的事务消息；

数据同步模块，其配置来监听消息服务器，当有新的事务相关数据写入时，数据同步模块通过proxy的在线数据库缓存列表取得集群所有在线数据库名单，过滤掉已处理事务的数据库，避免事务重复操作，同时将事务信息推送给集群中的其他数据库。