CN102053982A - 一种数据库信息管理方法和设备 - Google Patents

Abstract

本申请公开了一种数据库信息管理方法和设备，应用于包括一个管理服务器、一个应用服务器和多个数据服务器的系统中，通过在系统的数据中添加数据标识，标识出该数据的地址信息和读写权限信息，从而可以实现数据库信息的分表分库管理，并可以根据系统中的数据库管理策略进行相应的信息调度，提高系统中的数据信息管理效率。

Description

一种数据库信息管理方法和设备

技术领域

本申请涉及通信技术领域，特别涉及一种数据库信息管理方法和设备。

背景技术

随着信息社会的发展和互联网应用的广泛普及，越来越多的信息被数据化，尤其是伴随着互联网(Internet)技术的发展，数据呈爆炸式增长。作为网络的驱动因素，信息数据正在成为网络的核心，数据的安全、高效存储和管理作为网络发展的基础，日益受到人们的重视，但也正因为数据量的高速增长，海量数据的存储和访问成为了系统设计的瓶颈问题。

对于一个大型的互联网应用系统，现在每天都需要承受多达几十亿次的页面浏览量(Page View，PV)，因此所形成的巨大数据流量和数据处理量对数据库系统造成了相当高的负载，对于系统的稳定性和扩展性造成了极大的负面影响。

在现有的技术中，主要通过数据切分来提高网络性能，其中，横向扩展数据层，即水平切分数据库，已经成为架构研发人员首选的网络系统构建方式。

水平切分数据库，可以降低单台设备的负载，通过负载均衡策略，有效的降低了单台机器所承受的访问负载，降低了该设备因为负载过高而宕机的可能性。同时，水平切分数据库所形成的负载分担也最大限度的降低了某台或某几台设备宕机给整个系统造成的损失。

而另一方面，现有的技术方案还通过在多台网络设备之间建立集群，进行数据库负载分担的方案，解决了数据库宕机带来的单点数据库不能访问的问题。

再进一步的，现有技术还通过读写分离策略，将需要处理量较大的写操作(Write)与对数据的读操作(Read)进行分离处理，大幅提高了应用中读取数据的速度和并发量。

目前，常见的大型互联网应用中，大量的采用了这样的数据切分方案，从而实现了分布式数据访问层(Distributed Data Access Layer，DDAL)的建立。

在实现本申请的过程中，发明人发现现有技术至少存在以下问题：

现有的一些数据库技术，例如iBATIS，不能够支持分表分库的数据库访问，而应用这些数据库技术进行处理的业务数据又是海量的，需要对表进行水平拆分以保证数据库操作语句的性能，这样的矛盾严重影响了数据库的应用体验。

发明内容

本申请提供一种数据库信息管理方法和设备，通过在系统的数据中添加数据标识，标识出该数据的地址信息和读写权限信息，从而实现数据库信息的分表分库管理。

为达到上述目的，本申请一方面提供了一种数据库信息管理方法，应用于包括一个管理服务器、一个应用服务器和多个数据服务器的系统中，所述管理服务器为所述数据服务器中的数据添加数据标识，所述数据标识包括所述数据的地址信息和所述数据的读写权限，所述方法包括：

所述应用服务器向所述管理服务器获取目标数据所对应的数据标识，并在本地进行存储；

所述应用服务器根据所述数据标识中所包含的所述目标数据的地址信息访问所述目标数据，并根据所述数据标识中所包含的所述目标数据的读写权限，对所述目标数据进行相应的操作。

优选的，所述管理服务器为所述数据服务器中的数据添加数据标识之前，还包括：

所述管理服务器根据预设的数据库管理策略，将所述系统中的数据分别存储于相应的数据服务器中。

优选的，所述多个数据服务器组成至少一个数据服务器群落，所述数据服务器群落中包含一个主数据服务器和至少一个从数据服务器，所述管理服务器将所述系统中的数据分别存储于相应的数据服务器中，具体为：

所述管理服务器根据所述系统中的数据的读写负载调整策略，将所述数据分配给各所述数据服务器群落中相应的主数据服务器或从数据服务器进行存储；

其中，所述管理服务器分配给各所述数据服务器群落中的主数据服务器中存储的数据具有可以进行读操作和/或写操作的权限，所述管理服务器分配给各所述数据服务器群落中的从数据服务器中存储的数据只具有进行读操作的权限。

优选的，所述管理服务器根据预设的数据库管理策略，将所述系统中的数据分别存储于相应的数据服务器中之后，还包括：

所述管理服务器根据预设的容灾策略，分别为所述系统中全部或部分数据服务器建立备份服务器，并将所述数据服务器中所存储的数据复制到相应的备份服务器中。

优选的，当所述数据服务器的数据不能被访问时，还包括：

所述管理服务器将所述数据服务器中的数据所对应的数据标识中所包含的地址信息变更为所述数据服务器所对应的备份服务器的地址信息。

优选的，所述应用服务器向所述管理服务器获取目标数据所对应的数据标识，具体为：

当所述应用服务器所发起的业务需要访问所述目标数据时，所述应用服务器向所述管理服务器请求所述目标数据的数据标识，并接收所述管理服务器所返回的所述目标数据的数据标识；或，

当所述应用服务器初始化时，所述应用服务器向所述管理服务器获取所述系统当前所有数据的数据标识，并在本地存储，当所述应用服务器所发起的业务需要访问所述目标数据时，所述应用服务器在本地读取所述目标数据的数据标识。

优选的，所述方法还包括：

如果所述应用服务器是在需要访问目标数据时，向所述管理服务器获取所述目标数据所对应的数据标识，则当所述管理服务器判断所述目标数据的数据标识发生变化时，所述管理服务器向所述应用服务器发送包含新的数据标识的通知消息，更新所述应用服务器所获取的目标数据的数据标识；

如果所述应用服务器是在初始化时，向所述管理服务器获取所述系统当前所有数据的数据标识，并在本地进行存储，则当所述管理服务器判断所述系统当前的数据的数据标识发生变化或有新的数据加入所述系统时，所述管理服务器向所述应用服务器发送包含更新的数据的数据标识或新加入的数据的数据标识的通知消息，更新所述应用服务器所获取的所述系统当前全部数据的数据标识。

另一方面，本申请实施例还提供了一种应用服务器，应用于包括一个管理服务器、一个应用服务器和多个数据服务器的系统中，所述管理服务器为所述数据服务器中的数据添加数据标识，所述数据标识包括所述数据的地址信息和所述数据的读写权限，包括：

获取模块，用于向所述管理服务器获取目标数据所对应的数据标识；

识别模块，与所述获取模块相连接，用于识别所述获取模块所获取的数据标识中所包含的所述目标数据的地址信息和读写权限；

处理模块，与所述识别模块相连接，用于根据所述识别模块所识别的所述目标数据的地址信息访问所述目标数据，并根据所述识别模块所识别的所述目标数据的读写权限，对所述目标数据进行相应的操作。

优选的，所述获取模块，具体包括：

设置子模块，用于设置获取数据标识的策略，其中，所述获取数据标识的策略包括：当所述应用服务器所发起的业务需要访问目标数据时，向所述管理服务器请求所述目标数据的数据标识，或，当所述应用服务器初始化时，向所述管理服务器获取所述系统当前所有数据的数据标识；

获取子模块，与所述设置子模块相连接，用于根据所述设置子模块所设置的获取数据标识的策略，向所述管理服务器获取所述目标数据所对应的数据标识。

优选的，所述获取模块，还包括：

存储子模块，与所述获取子模块相连接，用于存储所述获取子模块所获取的所述目标数据的数据标识；

其中，当所述设置子模块所设置的获取数据标识的策略为当所述应用服务器初始化时，向所述管理服务器获取所述系统当前所有数据的数据标识时，所述存储子模块还用于存储所述系统当前的其他数据所对应的数据标识。

优选的，所述应用服务器还包括：

通信模块，与所述获取模块相连接，用于接收所述管理服务器发送的包含更新后的目标数据所对应的数据标识和/或新加入的数据的数据标识的通知消息，更新所述获取模块所获取的目标数据的数据标识或所述系统当前全部数据的数据标识。

另一方面，本申请实施例还提供了一种管理服务器，应用于包括一个管理服务器、一个应用服务器和多个数据服务器的系统中，包括：

设置模块，用于设置数据库管理策略和读写负载调整策略；

处理模块，与所述设置模块相连接，用于根据所述设置模块所设置的数据库管理策略和读写负载调整策略，将所述系统中的数据分别存储于相应的数据服务器中；

标识模块，用于根据所述设置模块所设置的数据库管理策略和读写负载调整策略，为各所述数据服务器中的数据添加数据标识，所述数据标识包括所述数据的地址信息和所述数据的读写权限。

优选的，所述多个数据服务器组成至少一个数据服务器群落，所述数据服务器群落中包含一个主数据服务器和至少一个从数据服务器，所述处理模块根据所述设置模块所设置的读写负载调整策略，将所述系统中的数据分别存储于相应的数据服务器中，具体为：

所述处理模块根据所述设置模块所设置的当前系统中的数据的读写负载调整策略，将所述数据分配给各所述数据服务器群落中相应的主数据服务器或从数据服务器进行存储；

其中，所述管理服务器分配给各所述数据服务器群落中的主数据服务器中存储的数据具有可以进行读操作和/或写操作的权限，所述管理服务器分配给各所述数据服务器群落中的从数据服务器中存储的数据只具有进行读操作的权限。

优选的，

所述设置模块，还用于设置容灾策略；

所述处理模块，还用于根据所述设置模块所设置的容灾策略，分别为所述系统中全部或部分数据服务器建立备份服务器，并将所述数据服务器中所存储的数据复制到相应的备份服务器中。

优选的，所述管理服务器还包括：

调整模块，用于当所述数据服务器的数据不能被访问时，将所述数据服务器中的数据所对应的数据标识中所包含的所述数据的地址信息变更为所述数据服务器所对应的备份服务器的地址信息。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请的技术方案，可以在系统的数据中添加数据标识，标识出该数据的地址信息和读写权限信息，从而可以实现数据库信息的分表分库管理，并可以根据系统中的数据库管理策略进行相应的信息调度，提高系统中的数据信息管理效率。

附图说明

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

图1为本申请实施例提供的一种数据库信息管理方法的流程示意图；

图2为本申请实施例提供的一种数据服务器集群的结构示意图；

图3为本申请实施例提供的一种数据库信息管理方法的应用场景的结构示意图；

图4为本申请实施例提供的一种数据库信息管理方法的在具体应用场景中的流程示意图；

图5为本申请实施例提供的一种应用服务器的结构示意图；

图6为本申请实施例提供的一种管理服务器的结构示意图。

具体实施方式

如背景技术所述，现有的一些数据库技术，例如iBATIS，并不能支持分表分库的数据库访问，因而，在面对海量的业务数据存储和处理过程时，尤其是面对需要对表进行水平拆分以保证数据库操作性能的应用环境时，现有的数据库技术存在应用上的瓶颈。

基于这样的技术缺陷，本申请提出了一种通过为数据添加数据标识来解决上述的现有技术不足的技术思路，通过管理服务器为数据添加数据标识，以此标明了对应数据在当前系统中的存储位置和进行读写操作权限，应用服务器在需要对数据进行操作时，首先向管理服务器获取目标数据所对应的数据标识，而后根据获取到的数据标识对目标数据进行操作和管理，并实现相应的应用进程，其中，当前系统可以应用分表分库的处理，在此基础上，数据标识中包含了进行分表分库处理后的数据的位置信息，应用服务器可以根据相应的位置信息在分表分库后的系统中，从相应的数据服务器中进行相应数据的获取。

本申请实施例所提出的一种数据库信息管理方法，应用于包括一个管理服务器、一个应用服务器和多个数据服务器的系统中，管理服务器为数据服务器中的数据添加数据标识，其中，数据标识包括数据的地址信息和数据的读写权限。

具体如图1所示，为本申请实施例提供的一种数据库信息管理方法的流程示意图，具体包括以下步骤：

步骤S101、管理服务器为数据服务器中的数据添加数据标识，并在本地进行存储。

具体的，管理服务器为数据添加数据标识的方式如下：

在管理服务器中建立当前系统中所有数据的数据信息列表，在该列表中保存各数据所对应的数据标识信息。在数据标识中，至少保存了各数据所对应的存储位置信息和读写权限信息，在具体的应用场景中，数据标识中还可以进一步包括数据创建或修改的时间信息，数据本身的大小信息，以及数据所具有的其他信息内容。其中，存储位置信息至少包括数据所处的数据列表的位置信息和数据服务器的位置信息。例如，一个十位的存储位置信息：1234567890，其中的前4位1234表示数据存储的数据列表位置信息，中间3位表示数据存储的数据服务器位置信息，后3位表示数据在数据列表中的位置信息，当然，这只是本发明实施例中优选的存储位置信息方式，还可以是其他代码或者标示符信息。

上述信息可以是以具体内容的方式直接存储于数据标识中，也可以是以代码或标示符的方式进行存储，但是，在以代码或标示符的方式进行存储的情况下，管理服务器中需要建立相应的代码或标示符与具体信息内容的对应规则，在能够实现信息记录的基础上，具体应用的存储方式的变化并不影响本发明的保护范围。

其中，在管理服务器为数据服务器中的数据添加数据标识之前，还包括管理服务器根据预设的数据库管理策略，将系统中的数据分别存储于相应的数据服务器中。

这样的处理目的就是为了实现系统中数据的分表分库处理，从而提高系统中的数据负载分担。

在具体的应用场景中，上述系统中的多个数据服务器组成了至少一个数据服务器群落，各数据服务器群落中分别包含一个主数据服务器和至少一个从数据服务器，管理服务器将系统中的数据分别存储于相应的数据服务器中，具体的存储流程为：

管理服务器根据系统中的数据的读写负载调整策略，将数据分配给各数据服务器群落中相应的数据服务器中。

其中，读写负载调整策略中关于分别进行读写操作的数据的分配规则包括：

管理服务器将需要进行写操作的数据分配到各数据服务器群落中的主数据服务器中；

管理服务器将需要进行读操作的数据分配到各数据服务器群落中的从数据服务器中。

需要指出的是，上述的两种分配规则对数据的操作类型范围要求不同，对于存储于主数据服务器中的数据，为具有写操作需求的数据，但是存储于主数据服务器中的数据同样可以进行读操作，但是，与之相对的，对于存储于从数据服务器中的数据，为具有读操作需求的数据，但是存储于从数据服务器中的数据只能进行读操作，而不能进行写操作。

这样进行数据分配的的好处在于：将需要进行较大处理量的写操作分配给主数据服务器来完成，将需要进行的处理量比较小的读操作分配给从数据服务器来完成，不仅如此，由于写操作需要涉及数据信息的修改，因此，需要在更高级别的主数据服务器中进行，这样便于数据的管理和权限的具体分配。

需要进一步指出的是，管理服务器根据预设的数据库管理策略，将系统中的数据分别存储于相应的数据服务器中之后，还包括容灾策略的实现，具体的实现过程包括：

(1)管理服务器根据预设的容灾策略，分别为系统中全部或部分数据服务器建立备份服务器。

具体的备份服务器建立策略可以是在新的服务器设备上建立，也可以是在现有的其他数据服务器中的空余空间中建立。

在新的服务器设备中建立备份服务器有利于备份数据的独立管理，但是需要进行新的设备投入。

在现有的其他数据服务器中的空余空间中建立备份服务器可以有效的降低成本投入，但是需要建立相应的空间监视机制，保障能够及时发现现有的其他数据服务器中的空余存储空间，并保证已被利用作为备份空间的数据服务器空间不会与其他数据的存储发生矛盾。

(2)管理服务器将各数据服务器中所存储的数据复制到相应的备份服务器中。

这样的数据复制在数据服务器初始化时会首先进行数据备份，在后续的处理过程中，如果一个或多个数据服务器中的数据发生了变化，还包括相应的数据服务器和备份服务器之间的数据同步过程，具体的通过过程包括以下三种方案：

方案一、由管理服务器进行定期的数据检测，并主动发起数据服务器和备份服务器之间的数据同步操作

其中，管理服务器进行数据检测的检测周期可以预先设定，具体的检测周期的长度标准以不致因为过于频繁的进行数据检测而影响系统或者相应设备的性能为宜。

如果管理服务器判断一个或者多个数据服务器中的数据发生变化时，将启动相应的数据服务器和备份服务器之间的数据同步操作，以使备份服务器中的数据与数据服务器中的数据信息保持一致。

其中，需要指出的是，数据同步操作的启动时间可以是在检测发现数据发生变化后直接进行启动，也可以是在判断发生变化的数据的总量达到预设的阈值后，才统一进行数据同步操作，这样的变化并不影响本申请的保护范围。

方案二、由数据服务器对自身的数据信息进行定期的数据检测，并在发现数据变化时向管理服务器请求发起该数据服务器和备份服务器之间的数据同步操作

需要指出的是，上述的数据服务器进行数据检测以发现数据是否发生变化的形式包括直接对数据信息本身进行检测，或对接收到的数据操作指令进行检测两种形式。

第一种检测形式具体可以是对数据进行扫描，如果发现数据发生过变化，或者最近的修改时间是在前次数据扫描之后发生的，那么，将判断该数据信息发生了变更，并向管理服务器请求发起在备份服务器中对该数据信息的数据同步操作过程。

第二种检测形式则是对在最近的一个检测周期内所接收到的操作指令的类型进行扫描，如果发现其中具有数据改写功能的操作指令类型(例如写入指令)，则向管理服务器请求发起在备份服务器中对该操作指令所对应的数据信息的数据同步操作过程。

上述的两种检测形式的区别在于具体检测对象的差别，根据数据本身内容或对应的操作指令类型判断数据是否发生变化判断是否向管理服务器请求发起在备份服务器中对相应的数据信息的数据同步操作过程，具体采用哪种检测形式并不会影响本申请的保护范围。

其中，需要进一步指出的是，上述的数据服务器进行数据检测的检测周期可以预先设定，具体的检测周期的长度标准以不致因为过于频繁的进行数据检测而影响系统或者数据服务器本身的性能为宜。

如果数据服务器判断自身的数据发生变化时，将向管理服务器发送请求消息，请求启动自身与相应的备份服务器之间的数据同步操作，以使备份服务器中的数据与数据服务器中的数据信息保持一致。

其中，需要指出的是，数据同步操作的启动时间可以是在管理服务器收到数据同步请求后直接进行启动，也可以是在管理服务器判断发生变化的数据的总量达到预设的阈值后，才统一进行数据同步操作，这样的变化并不影响本申请的保护范围。

方案三、由应用服务器向管理服务器请求发起数据服务器和备份服务器之间的数据同步操作

在具体的应用过程中，如果应用服务器对数据服务器中的数据进行操作的过程中，发现数据信息错误，或直接判断不能对目标数据信息进行读取，则判断该数据信息需要更新，从而向管理服务器请求发起数据服务器和备份服务器之间的数据同步操作。

其中，需要指出的是，数据同步操作的启动时间可以是在管理服务器接收到应用服务器发送的同步请求之后直接进行启动，也可以是在管理服务器判断发生变化的数据的总量达到预设的阈值后，才统一进行数据同步操作，这样的变化并不影响本申请的保护范围。

通过上述的操作流程，可以在系统中为各数据服务器建立相应的备份服务器，并通过相应的数据更新机制保证数据服务器和备份服务器之间的数据信息保持一致。

在建立了备份服务器的基础上，当管理服务器或应用服务器判断数据服务器中的数据不能被访问时，管理服务器将数据服务器中的数据所对应的数据标识中所包含的数据的地址信息变更为数据服务器所对应的备份服务器的地址信息。

通过这样的处理，当后续再接到对于相应数据的操作请求时，管理服务器返回的将是变更后的数据标识，相应的应用服务器将通过更改后的地址向备份服务器获取相应的数据信息，从而，保证具体的应用进程不会因为数据不能访问而中断。

步骤S102、应用服务器向管理服务器获取目标数据所对应的数据标识。

在具体的应用场景中，本步骤具体包括以下两种情况：

情况一、当应用服务器所发起的业务需要访问目标数据时，应用服务器向管理服务器请求目标数据的数据标识，并接收管理服务器所返回的目标数据的数据标识。

这种情况的数据标识获取请求的针对性比较强，需要对指定的目标数据进行数据标识获取操作，所获取的数据标识的范围仅限于目标数据所对应的数据标识，而对其他数据的数据标识则不会进行获取，因此，在进行数据标识的获取时，应用服务器向管理服务器发送的获取请求中需要携带目标数据的指示信息，例如目标数据在当前系统中的数据编号或数据名称等，凡是可以实现对当前系统中的海量数据进行区分的信息形式，都可以作为指示信息，具体的指示信息的类型变化并不会影响本申请的保护范围。

情况二、当应用服务器初始化时，应用服务器向管理服务器获取系统当前所有数据的数据标识，并在本地存储，当应用服务器所发起的业务需要访问目标数据时，应用服务器在本地读取目标数据的数据标识。

这种情况的数据标识获取是一次性的，在应用服务器初始化时，一次性的向管理服务器获取所有当前数据的数据标识，并且在本地进行存储。

这样处理的好处在于，应用服务器发起数据操作时，直接可以根据本地存储的数据标识找到相应的数据信息，而不再需要与管理服务器进行信息交互，节约了信息交互的时间，提高了相应的处理效率。

但是这样的方案需要应用服务器中提供相应的数据标识的存储空间，以保证获取到的全部数据标识都能够存储在相应的空间中，由于数据标识的大小都很有限，所以，并不会造成太大的存储负担，但是否应用此种方案需要根据具体的应用场景来衡量。

上述两种方式都可以实现数据标识信息的获取，具体应用哪种方式并不影响本申请的保护范围。

在通过上述的方式获取到数据标识后，本申请所提出的技术方案还进一步包括被获取的数据标识的更新流程，这个流程的设置目的在于被获取的数据标识可能会发生变化，而如果应用服务器只是获取了变化前的数据标识，那么，应用服务器将不能进行正常的业务操作，从而影响系统中正常业务的实现。

具体的，根据上述的目标数据的数据标识获取方式的不同，后续的更新流程也存在相应的区别，具体说明如下：

如果目标数据的数据标识获取方式对应的是上述的情况一，即应用服务器是在需要访问目标数据时，才向管理服务器获取目标数据所对应的数据标识，那么，当管理服务器判断目标数据的数据标识发生变化(例如，由于数据存储位置的变化，读写权限的变化以及数据本身的增加或删除导致数据标识中所存储的信息发生调整)时，管理服务器向应用服务器发送包含新的数据标识的通知消息，更新应用服务器所获取的目标数据的数据标识。

如果目标数据的数据标识获取方式对应的是上述的情况二，即应用服务器是在初始化时，向管理服务器获取系统当前所有数据的数据标识，那么，当管理服务器判断系统中当前的数据所对应的数据标识发生变化，或有新的数据信息加入系统时，管理服务器向应用服务器发送包含更新的数据的数据标识或新加入的数据的数据标识的通知消息，更新应用服务器所获取的系统当前全部数据的数据标识。

步骤S103、应用服务器根据数据标识中所包含的目标数据的地址信息访问目标数据，并根据数据标识中所包含的目标数据的读写权限，对目标数据进行相应的操作。

对应前述的两种情况，本步骤的具体处理过程包括：

对应情况一，应用服务器向管理服务器获取数据标识，并根据获取到的目标数据的数据标识中所包含的地址信息查询到相应的数据存储位置，并进一步根据获取到的目标数据的数据标识中所包含的读写权限信息判断目标数据是否可以实现对应的操作，如果判断结果成立，则直接进行相应的操作，如果判断结果不成立，则判断相应的操作失败。

对应情况二，应用服务器直接查询本地存储的数据标识，并根据本地存储的目标数据的数据标识中所包含的地址信息查询到相应的数据存储位置，并进一步根据获取到的目标数据的数据标识中所包含的读写权限信息判断目标数据是否可以实现对应的操作，如果判断结果成立，则直接进行相应的操作，如果判断结果不成立，则判断相应的操作失败。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请实施例的技术方案，可以在系统的数据中添加数据标识，标识出该数据的地址信息和读写权限信息，从而可以实现数据库信息的分表分库管理，并可以根据系统中的数据库管理策略进行相应的信息调度，提高系统中的数据信息管理效率。

为了更加清楚的说明本申请的技术方案，首先，对分表分库技术进行相应的阐述。

在具体的应用场景中，负载高点可能考虑使用相关的Replication(复制)机制来提高读写的吞吐和性能，这可能已经可以满足很多需求，但这套机制自身的缺陷还是比较显而易见的。

首先，上述的Replication机制的有效依赖于读操作的比例，Master Server(主服务器)往往会成为瓶颈所在，写操作需要顺序排队来执行，过载的话Master Server首先会出现不能承受当前负载的状况，Slaves Server(从服务器)的数据同步的延迟也可能比较大，而且会大大耗费CPU的计算能力，因为写操作在Master Server上执行以后，还是需要在每台Slave Server上都执行一次。这时候，可以通过开源数据库技术中的Sharding技术将计算、存储、I/O等并行的分发到多台设备上，这样可以充分利用多台机器各种处理能力，同时可以避免单点失败，提供系统的可用性，进行很好的错误隔离。

综合以上因素，数据切分就变得十分必要，具体的数据切分包括以下两种情况：

(1)分库处理技术：数据切分可以是物理上的，对数据通过一系列的切分规则将数据分布到不同的数据库服务器(Data Base Server，DB Server)上，通过路由规则路由访问特定的数据库，这样一来，每次访问操作所面对的就不是单台服务器，而是多台服务器，这样的处理可以降低单台机器的负载压力。

(2)分表处理技术：数据切分也可以是数据库内的，对数据通过一系列的切分规则，将数据分布到一个数据库的不同表中，比如，将一个article表划分为article_001，article_002等多个子表，若干个子表水平拼合组成了逻辑上一个完整的article表。

这样处理的作用通过以下示例进行说明：

假设一个article表中现在有5000万条数据，此时，系统需要在这个article表中增加(insert)一条新的数据。

如果不进行分表处理，insert操作完毕后，数据库会针对这张表重新建立索引，对于5000万行数据建立索引的系统开销是十分巨大的。

但是反过来，如果进行了分表处理，预先将article表分为了100个子表，从article_001一直到article_100，那么，5000万行数据平均下来，每个子表里边就只有50万行数据，因此，对于同样的insert操作，只需要向一张只有50万行数据的子表中进行数据添加操作，并且数据添加完毕后，建立索引的时间也会因为所处理数据量的大幅下降而呈数量级的降低，从而，提高了数据库的运行时效率，提高了数据库的并发量。

当然，分表处理的好处不仅包括以上的处理效率的提高，在诸如写操作的锁操作等诸多领域，都可以通过应用分表技术对数据库进行处理，从而带来很多有益的效果。

综上所述，分库技术的实现降低了单点机器的负载，而分表技术的应用则提高了数据操作的效率，尤其是提高了写操作的效率，进一步的，本申请通过以下说明对切分规则进行详尽的阐述。

首先，为了实现数据的水平切分，在每一个表中都要有相冗余字符作为切分依据和标记字段，通常的应用中，可以选用user_id作为区分字段，基于这种设置，可以进一步的提出如下三种分库的方式和规则：

按号段分：

(1)以user_id为区分依据。

例如：将user_id为1～1000的表对应DB1(数据库1)，将user_id为1001～2000的表对应DB2(数据库2)，并以此类推。其中的user_id分配区间可以根据具体的需要进行调整，这样的变化并不会影响本申请的保护范围。

(2)通过哈希(hash)算法进行取模区分：

对user_id进行hash处理(或者如果user_id是数值型的话直接使用user_id的值也可)，然后用一个特定的数字进行进一步处理计算。

比如，应用中需要将一个数据库切分成4个数据库的话，就用4这个数字对user_id的hash值进行取模运算，也就是user_id％4，这样的话每次运算就有四种可能：

结果为1的时候对应DB1；

结果为2的时候对应DB2；

结果为3的时候对应DB3；

结果为0的时候对应DB4。

由于进行hash处理时的数据分配频率是均匀的，因此，可以非常均匀的将数据分配到4个DB中。

(3)在认证库中保存数据库配置

就是建立一个数据库作为认证库，这个认证库单独保存了各个user_id到各个DB的映射关系，因此，每次访问数据库的时候都要先查询一次这个认证库，以得到具体的DB信息，然后才能进行具体的操作处理。

以上三种方式是通常的开发所选择的三种方式，不同的项目会进行不同的方案选择，有些复杂的项目中可能会混合使用这三种方式。

基于上述的技术思想和方案细节，分布式数据方案提供功能如下：

(1)提供分库规则和路由规则(Route Rule，RR)，将上面的说明中提到的三种切分规则直接内嵌入系统中，具体的嵌入方式在接下来的内容中进行详细的说明和论述。

(2)引入集群(Group)的概念，保证数据的高可用性。

(3)引入负载均衡策略(Load Balance Policy，LBP)。

(4)引入集群节点可用性探测机制，对单点机器的可用性进行定时的侦测，以保证LB策略的正确实施，以确保系统的高度稳定性。

(5)引入读/写分离，提高数据的查询速度。

在具体的应用场景中，仅仅是通过分库分表处理的数据层设计也是不够完善的。

比如，当某个节点上的数据库服务器出现了宕机或其他不能工作的情况时，由于采用了数据库切分方案，也就是说有N台机器共同组成了一个完整的数据库，如果其中有一台机器宕机的话，也仅仅是一个数据库的N分之一的数据不能访问而已，这种情况显然好于切分之前的情况，不至于让整个数据库都不能访问，但毕竟还是存在单点中的部分数据库无法访问的情况。虽然在实际应用中这样的不足是可以接受的，但是，错误本身的存在却是不容忽视的，尤其是当应用的直接目的数据库就是发生故障的单点数据库时，所带来的损失将是不容忽视的，也就是说，即使应用了分表分库技术，具体应用场景中的容错性能还是存在缺陷。

因此，本申请引入了集群的概念来解决相应的问题，也就是将每一个分库的节点引入多台服务器设备，在每台服务器设备中保存的数据是一样的，一般情况下，这多台服务器设备分担负载，而当其中的某台服务器设备出现宕机情况时，负载均衡器将该台服务器设备的负载分配给其他服务器设备。这样一来，就解决了容错性的问题，即使在单点服务器设备出现故障时，也不会对数据库中的数据信息造成损失，从而，保证系统中数据业务的正常实现。

如图2所示，整个数据层有Group1，Group2，Group3三个集群组成，这三个集群就是数据水平切分的结果，当然这三个集群也就组成了一个包含完整数据的数据库。每一个Group包括一个Master Server(当然，在实际的应用场景中，Master Server也可以是多个)和多个Slave Server，这些Master Server和Slave Server的数据是一致的。

比如，Group1中的一个Slave Server发生了宕机现象，那么，在该Group中，还有两个Slave Server是可以用的，而由于各Slave Server中的数据是一致的，因此，不会对正常的数据库操作造成影响，不会出现某部分数据不能访问的问题，除非整个Group里的机器全部宕掉，但是在实际的应用场景中，出现这种故障的概率很小。

在没有引入集群划分的操作规则以前，一次查询的过程大致如下：请求数据层，并传递必要的分库区分字段(通常情况下是user_id)，数据层根据区分字段路由到具体的数据库，并在这个确定的数据库中进行相应的进行数据操作。

而引入集群划分的操作规则的情况下，路由器上所配置的具体规则和策略只能将操作指令路由到具体的Group中，也就是只能路由到一个虚拟的Group中，这个Group并不是某个特定的某个物理的数据库服务器，而是由多个物理的数据库服务器所组成的虚拟集群。

接下来，需要查找具体的物理的数据库服务器，以进行具体的数据操作。基于这个环节的需求，引入了负载均衡器(Load Balance，LB)的概念，负载均衡器的职责就是将具体的操作指令定位到一台具体的数据库服务器。

具体的规则如下：负载均衡器会分析当前操作指令的读写特性，如果是写操作或者是要求实时性很强的操作，直接将操作指令分配到Master Server，而如果是读操作，则通过负载均衡策略，将操作指令分配到一个Slave Server中。

通常情况下，负载均衡包括随机负载均衡和加权负载均衡。

随机负载均衡就是从N个Slave Server中随机选取一个Slave Server。这样的随机负载均衡是不考虑机器性能的，默认为每台服务器设备的性能是一样的。

但是，对于每个Slave Server的机器物理性能和配置不一样的情况，再使用随机的不考虑性能的负载均衡，是非常不科学的，这样一来会给机器性能差的机器带来不必要的高负载，甚至带来宕机的危险，同时高性能的数据库服务器也不能充分发挥其物理性能。

基于此考虑，进一步的引入了加权负载均衡，也就是通过一定的接口，给每台数据库服务器分配一个权值，然后，在运行时，由负载均衡器根据权值在集群中的比重，分配一定比例的负载给该数据库服务器。

有了分库，有了集群，有了负载均衡器，但是这样的设计并不能完全规避数据库宕机的危害。

例如，Group1中的Slave Server 2宕机了，那么，系统的负载均衡器并不能得知，这样的话其实是很危险的，因为负载均衡器不知道，还会以为SlaveServer 2为可用状态，所以，还是会给Slave Server 2分配负载。这样一来，客户端便会发生数据操作失败的错误或者异常。

为了应对上述不足，本申请进一步引入了集群节点的可用性探测机制，或者可用性数据推送机制。

首先，可用性探测机制就是数据层客户端不定时的对集群中各个数据库进行可用性的尝试，实现原理就是尝试性链接，或者数据库端口的尝试性访问，当然也可以用JDBC(Java Data Base Connectivity，Java数据库连接)尝试性链接，利用Java的Exception机制进行可用性的判断，具体尝试形式的变化并不会影响本申请的保护范围。

一般情况下，当前应用的数据库服务器宕机的话，数据库管理员(Database Administrator，DBA)肯定是可以知道的，这个时候，DBA可以手动的将数据库的当前状态通过程序的方式推送到客户端，也就是分布式数据层的应用端，更新一个本地的数据库状态的列表，并告知负载均衡器，这个数据库节点不能使用，请不要给它分配负载。

上述的两种监听策略，一个是主动的监听机制，一个是被动的被告知的机制，两者各有所长，但是都可以达到同样的效果。这样一来，可以有效的避免上述的假设中所存在问题。

对于上述的说明文字中提到的Master Server和Slave Server，具体分布关系如图2所示，一个Group由1个Master Server和N个Slave Server组成。其中，MasterServer负责写操作的负载，也就是说一切写的操作都在Master Server上进行，而读的操作则分摊到Slave Server上进行。

这样一来的可以大大提高读取的效率。在一般的互联网应用中，经过一些数据调查得出结论，读/写的比例大概在10∶1左右，也就是说大量的数据操作是集中在读的操作。

在具体的应用场景中，写操作涉及到锁的问题，并且，无论是行锁、表锁还是块锁，都会造成系统执行效率降低的情况，将写操作独立的部署于Master Server中，可以有效的规避写操作对其他服务器的效率影响，而由于大量的写操作没有分配给Master Server，所以，Master Server可以有更多的系统资源用于进行写操作，从而，提高写操作的处理效率。

在本申请所提出的技术方案中，读写分离是把写操作集中在一个节点上，而读操作在其他的N个节点上进行，从另一个方面，本技术方案可以有效的提高读操作的效率，保证了系统的高可用性。

对于上述的技术方案，系统的实现层面有两种选择：

一种是基于JDBC层面上的选择。

一种是基于现有数据持久层框架层面上的选择，比如：Hibernate、iBATIS等。

基于JDBC层面上的系统实现，系统开发难度和后期的使用难度都将大大提高，大大增加了系统的开发费用和维护费用。

本申请所提出的实施例所提出的技术方案的定位是在成型的iBATIS持久层框架的基础上进行上层的封装，而不是对iBATIS源码的直接修改，这样一来，不会使本系统对现有的框架具有太多的侵入性，并且，也增加了使用的灵活性。

之所以选择iBATIS，原因如下：

(1)iBATIS的学习成本非常低，熟练的Java Programmer可在非常的短时间内熟练使用iBATIS。

(2)iBATIS是轻量级的ORM(Object/Relation Mapping，对象/关系映射)，只是简单的完成了RO(Relation-Object，关系-对象)，OR(Object-Relation，对象-关系)的映射，其查询语句也是通过配置文件(例如，sql-map.xml文件)在原生的SQL的结构层面进行简单的配置。

也就是说，实现上述的技术方案无需引入诸如Hibernate那样的HQL(Hibernate Query Language)的概念，从而增强了SQL的可控性，因此，数据库管理员可以从SQL的层面对SQL进行优化，使数据层的应用有很强的可控性。

与之相对的，Hibernate的功能虽然很强大，但是由于Hibernate是OR的一个重型封装，且引入HQL的概念，不便于数据库管理员团队对SQL语句的控制和性能的调优。

基于以上两点理由，本申请的实施例在ORM的产品的选择上选择了易学易用且轻量级的持久层框架iBATIS。下面的说明也都是特定于iBATIS的基础上的讨论，但是，并不是说本申请的技术方案只能基于iBATIS场景进行，只是为了便于说明而将后续的处理场景具体为iBATIS场景，具体应用场景的变化并不会影响本申请的保护范围。

在一些大型的Java应用中，通常会采用Spring这样的开源框架，尤其是IoC(Inversion of Control，控制反转)这部分，有效的帮助开发人员管理对象的依赖关系和层次，降低系统各层次之间的实体耦合。

上述的技术方案的系统构建工具包括：构建工具Antx(类似于Maven)和Maven，而依赖的开源Jar包括Spring2.0、iBATIS、commons-configuration(读取配置文件)、log4j、junit等。

数据源本身在Java中是没有特殊标记的，通过对数据源的标记，从而能够对数据源进行描述，例如描述该数据源是否支持可写操作。

本申请实施例的技术方案扩展iBATIS的分析特性，提供在项目启动的时候对所有的SQL语句进行一个当前读写性能的分析，并将分析结果缓存到本地内存中，大大提高了性能。

通过配置中心，推送给应用需要的数据库分表分库信息。应用在执行某条SQL的时候，会根据该SQL操作所对应的表，以及配置中心推送的分库分表信息，得到该表的分库依据，再据此获得真正的数据库的位置信息，从而对真正的目标数据库进行数据库操作。

进一步的，对应图3，对本申请的具体技术方案在具体的应用场景中的实现过程进行详细的说明，其中，图3具体为本申请实施例所提供的一种数据库信息管理方法的应用场景的结构示意图。

在具体的实施场景中，如图4所示，为本申请实施例所提供的一种数据库信息管理方法的的流程示意图，具体包括以下步骤：

步骤S401、Web应用向业务中心发送应用操作请求。

在实际的应用场景中，如图3所示，Web应用具体包括博客(Blog)、论坛(Bulletin Board System，BBS)、相册等需要借助Web和相对应的数据库支持来实现的应用。

用户可以通过上述的各种Web应用进行数据的发布和浏览，这样的基础在于该Web应用具有一个相对应的数据库服务器进行数据支持，用户发布的数据存储于数据库中，而数据库中所存储的数据则可以被满足权限要求的用户进行读取浏览或者编辑修改。

步骤S402、业务中心向管理服务器请求应用操作请求的目标数据所对应的数据标识。

步骤S403、业务中心向管理服务器接收应用操作请求的目标数据所对应的数据标识。

其中，数据标识中包含目标数据的位置信息和读写权限信息。

步骤S404、业务中心根据获取到的数据标识判断是否可以对目标数据进行与应用操作请求相对应的业务操作。

具体的判断依据包括：

目标数据的位置信息是否为有效地址，例如：位置信息所对应的数据服务器是否存在或是否处于可用状态，如果该数据服务器不存在或当前由于业务繁忙而暂时不可访问，那么，则判断为不可以对目标数据进行与应用操作请求相对应的业务操作。

目标数据的读写权限信息与应用操作请求的类型是否一致，例如：如果应用操作请求的类型为写入请求，而目标数据的读写权限为只允许读操作，因此，不能对目标数据进行写入操作，那么，则判断为不可以对目标数据进行与应用操作请求相对应的业务操作。

如果判断结果为否，则执行步骤S405；

如果判断结果为是，则执行步骤S406。

步骤S405、业务中心向Web应用返回应用操作请求失败的通知消息。

步骤S406、业务中心向目标数据所对应的数据服务器集群发送操作指令。

步骤S407、数据服务器集群中相对应的数据服务器对目标数据执行相应的操作处理。

具体的，当对目标数据的操作指令为写操作时，可以由该数据服务器集群中的主服务器执行；

当对目标数据的操作指令为读操作时，可以由该数据服务器集群中的从服务器执行。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请实施例的技术方案，可以在系统的数据中添加数据标识，标识出该数据的地址信息和读写权限信息，从而可以实现数据库信息的分表分库管理，并可以根据系统中的数据库管理策略进行相应的信息调度，提高系统中的数据信息管理效率。

为了实现上述的本申请实施例所提出的技术方案，本申请实施例还提出了一种应用服务器，应用于包括一个管理服务器、一个应用服务器和多个数据服务器的系统中，管理服务器为数据服务器中的数据添加数据标识，数据标识包括数据的地址信息和数据的读写权限。

如图5所示，为本申请实施例提出的一种应用服务器的结构示意图，包括：

获取模块51，用于向管理服务器获取目标数据所对应的数据标识。

在具体的应用场景中，获取模块51具体包括：

设置子模块511，用于设置获取数据标识的策略。

获取子模块512，与设置子模块511相连接，用于根据设置子模块511所设置的获取数据标识的策略，向管理服务器获取目标数据的数据标识。

在具体的应用场景中，设置子模块511所设置的获取数据标识的策略包括以下两种情况：

情况一、当应用服务器所发起的业务需要访问目标数据时，向管理服务器请求目标数据的数据标识。

这种情况的数据标识获取请求的针对性比较强，需要对指定的目标数据进行数据标识获取操作，所获取的数据标识的范围为一个或多个目标数据所对应的数据标识，因此，在获取子模块512进行数据标识的获取时，向管理服务器发送的获取请求中需要携带目标数据的指示信息，具体的指示信息的类型变化并不会影响本申请的保护范围。

情况二、当应用服务器初始化时，向管理服务器获取系统当前所有数据的数据标识。

这种情况的数据标识获取是一次性的，在应用服务器初始化时，一次性的向管理服务器获取所有当前数据的数据标识。

在此种情况下，还需要将获取到的系统当前所有数据的数据标识在本地进行存储。

基于上述要求，获取模块511还包括：

存储子模块513，与获取子模块512相连接，用于存储获取子模块512所获取的目标数据的数据标识。

这样处理的好处在于，应用服务器发起数据操作时，直接可以根据本地存储的数据标识找到相应的数据信息，而不再需要与管理服务器进行信息交互，节约了信息交互的时间，提高了相应的处理效率。

识别模块52，与获取模块51相连接，用于识别获取模块51所获取的数据标识中所包含的目标数据的地址信息和读写权限。

但是这样的方案需要应用服务器中提供相应的数据标识的存储空间，以保证获取到的全部数据标识都能够存储在相应的空间中，由于数据标识的大小都很有限，所以，并不会造成太大的存储负担，但是否应用此种方案需要根据具体的应用场景来衡量。

上述两种方式都可以实现数据标识信息的获取，具体应用哪种方式并不影响本申请的保护范围。

处理模块53，与识别模块52相连接，用于根据识别模块52所识别的目标数据的地址信息访问目标数据，并根据识别模块52所识别的目标数据的读写权限，对目标数据进行相应的操作。

在具体的应用场景中，应用服务器还包括：

通信模块54，与获取模块51相连接，用于接收管理服务器发送的包含新的数据标识和/或新加入的数据的数据标识的通知消息，更新获取模块51所获取的目标数据的数据标识或系统当前全部数据的数据标识。

另一方面，本申请实施例还提供了一种管理服务器，应用于包括一个管理服务器、一个应用服务器和多个数据服务器的系统中，其结构示意图如图6所示，包括：

设置模块61，用于设置数据库管理策略和读写负载调整策略。

处理模块62，与设置模块61相连接，用于根据设置模块61所设置的数据库管理策略和读写负载调整策略，将系统中的数据分别存储于相应的数据服务器中。

这样的处理目的就是为了实现系统中数据的分表分库处理，从而提高系统中的数据负载分担。

标识模块63，与设置模块61相连接，用于根据设置模块61所设置的数据库管理策略和读写负载调整策略，为各数据服务器中的数据添加数据标识，数据标识包括数据的地址信息和数据的读写权限。

在具体的应用场景中，多个数据服务器组成至少一个数据服务器群落，数据服务器群落中包含一个主数据服务器和至少一个从数据服务器，处理模块62根据设置模块61所设置的读写负载调整策略，将系统中的数据分别存储于相应的数据服务器中，具体为：

处理模块62根据设置模块61所设置的系统中的数据的读写负载调整策略，将数据分配给各数据服务器群落中相应的数据服务器中；

其中，读写负载调整策略中关于分别进行读写操作的数据的分配规则包括：

处理模块62将需要进行写操作的数据分配到各数据服务器群落中的主数据服务器中；

处理模块62将需要进行读操作的数据分配到各数据服务器群落中的从数据服务器中。

需要指出的是，上述的两种分配规则对数据的操作类型范围要求不同，对于存储于主数据服务器中的数据，为具有写操作需求的数据，但是存储于主数据服务器中的数据同样可以进行读操作，但是，与之相对的，对于存储于从数据服务器中的数据，为具有读操作需求的数据，但是存储于从数据服务器中的数据只能进行读操作，而不能进行写操作。

这样进行数据分配的的好处在于：将需要进行较大处理量的写操作分配给主数据服务器来完成，将需要进行的处理量比较小的读操作分配给从数据服务器来完成，不仅如此，由于写操作需要涉及数据信息的修改，因此，需要在更高级别的主数据服务器中进行，这样便于数据的管理和权限的具体分配。

在另一种具体的应用场景中，设置模块61，还用于设置容灾策略；

处理模块62，还用于根据设置模块61所设置的容灾策略，分别为系统中全部或部分数据服务器建立备份服务器，并将数据服务器中所存储的数据复制到相应的备份服务器中。

具体的备份服务器建立策略可以是在新的服务器设备上建立，也可以是在现有的其他数据服务器中的空余空间中建立。

在新的服务器设备中建立备份服务器有利于备份数据的独立管理，但是需要进行新的设备投入。

在现有的其他数据服务器中的空余空间中建立备份服务器可以有效的降低成本投入，但是需要建立相应的空间监视机制，保障能够及时发现现有的其他数据服务器中的空余存储空间，并保证已被利用作为备份空间的数据服务器空间不会与其他数据的存储发生矛盾。

不仅如此，为了适应数据信息的变化，管理服务器还包括：

调整模块64，用于当数据服务器的数据不能被访问时，将数据服务器中的数据所对应的数据标识中所包含的数据的地址信息变更为数据服务器所对应的备份服务器的地址信息。

通过这样的处理，当后续再接到对于相应数据的操作请求时，管理服务器返回的将是变更后的数据标识，相应的应用服务器将通过更改后的地址向备份服务器获取相应的数据信息，从而，保证具体的应用进程不会因为数据不能访问而中断。

与现有技术相比，本申请实施例所提出的技术方案具有以下优点：

通过应用本申请实施例的技术方案，可以在系统的数据中添加数据标识，标识出该数据的地址信息和读写权限信息，从而可以实现数据库信息的分表分库管理，并可以根据系统中的数据库管理策略进行相应的信息调度，提高系统中的数据信息管理效率。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以通过硬件实现，也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景所述的方法。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。

本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。

以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (16)

1.一种数据库信息管理方法，应用于包括一个管理服务器、一个应用服务器和多个数据服务器的系统中，其特征在于，所述管理服务器为所述数据服务器中的数据添加数据标识，所述数据标识包括所述数据的地址信息，所述方法包括：

所述应用服务器向所述管理服务器获取目标数据所对应的数据标识；

所述应用服务器根据所述数据标识中所包含的所述目标数据的地址信息访问所述目标数据，对所述目标数据进行相应的操作。

2.如权利要求1所述的方法，其特征在于，所述管理服务器为所述数据服务器中的数据添加数据标识之前，还包括：

所述管理服务器根据预设的数据库管理策略，将所述系统中的数据分别存储于相应的数据服务器中。

3.如权利要求2所述的方法，其特征在于，所述多个数据服务器组成至少一个数据服务器群落，所述数据服务器群落中包含一个主数据服务器和至少一个从数据服务器，所述管理服务器将所述系统中的数据分别存储于相应的数据服务器中，具体为：

所述管理服务器根据所述系统中的数据的读写负载调整策略，将所述数据分配给各所述数据服务器群落中相应的主数据服务器或从数据服务器进行存储；

其中，所述管理服务器分配给各所述数据服务器群落中的主数据服务器中存储的数据具有可以进行读操作和/或写操作的权限，所述管理服务器分配给各所述数据服务器群落中的从数据服务器中存储的数据只具有进行读操作的权限。

4.如权利要求2所述的方法，其特征在于，所述管理服务器根据预设的数据库管理策略，将所述系统中的数据分别存储于相应的数据服务器中之后，还包括：

所述管理服务器根据预设的容灾策略，分别为所述系统中全部或部分数据服务器建立备份服务器，并将所述数据服务器中所存储的数据复制到相应的备份服务器中。

5.如权利要求4所述的方法，其特征在于，当所述数据服务器的数据不能被访问时，还包括：

所述管理服务器将所述数据服务器中的数据所对应的数据标识中所包含的地址信息变更为所述数据服务器所对应的备份服务器的地址信息。

6.如权利要求1所述的方法，其特征在于，所述应用服务器向所述管理服务器获取目标数据所对应的数据标识，具体为：

当所述应用服务器所发起的业务需要访问所述目标数据时，所述应用服务器向所述管理服务器请求所述目标数据的数据标识，并接收所述管理服务器所返回的所述目标数据的数据标识；或，

当所述应用服务器初始化时，所述应用服务器向所述管理服务器获取所述系统当前所有数据的数据标识，并在本地存储，当所述应用服务器所发起的业务需要访问所述目标数据时，所述应用服务器在本地读取所述目标数据的数据标识。

7.如权利要求6所述的方法，其特征在于，还包括：

如果所述应用服务器是在需要访问目标数据时，向所述管理服务器获取所述目标数据所对应的数据标识，则当所述管理服务器判断所述目标数据的数据标识发生变化时，所述管理服务器向所述应用服务器发送包含新的数据标识的通知消息，更新所述应用服务器所获取的目标数据的数据标识；

如果所述应用服务器是在初始化时，向所述管理服务器获取所述系统当前所有数据的数据标识，并在本地进行存储，则当所述管理服务器判断所述系统当前的数据的数据标识发生变化或有新的数据加入所述系统时，所述管理服务器向所述应用服务器发送包含更新的数据的数据标识或新加入的数据的数据标识的通知消息，更新所述应用服务器所获取的所述系统当前全部数据的数据标识。

8.如权利要求1所述的方法，其特征在于，所述数据标识还包括所述数据的读写权限；所述应用服务器根据所述数据标识中所包含的所述目标数据的读写权限，对所述目标数据进行相应的操作。

9.一种应用服务器，应用于包括一个管理服务器、一个应用服务器和多个数据服务器的系统中，其特征在于，所述管理服务器为所述数据服务器中的数据添加数据标识，所述数据标识包括所述数据的地址信息，包括：

获取模块，用于向所述管理服务器获取目标数据所对应的数据标识；

识别模块，与所述获取模块相连接，用于识别所述获取模块所获取的数据标识中所包含的所述目标数据的地址信息和读写权限；

处理模块，与所述识别模块相连接，用于根据所述识别模块所识别的所述目标数据的地址信息访问所述目标数据，并根据所述识别模块所识别的所述目标数据的读写权限，对所述目标数据进行相应的操作。

10.如权利要求9所述的应用服务器，其特征在于，所述获取模块，具体包括：

设置子模块，用于设置获取数据标识的策略，其中，所述获取数据标识的策略包括：当所述应用服务器所发起的业务需要访问目标数据时，向所述管理服务器请求所述目标数据的数据标识，或，当所述应用服务器初始化时，向所述管理服务器获取所述系统当前所有数据的数据标识；

获取子模块，与所述设置子模块相连接，用于根据所述设置子模块所设置的获取数据标识的策略，向所述管理服务器获取所述目标数据所对应的数据标识。

11.如权利要求10所述的应用服务器，其特征在于，所述获取模块，还包括：

存储子模块，与所述获取子模块相连接，用于存储所述获取子模块所获取的所述目标数据的数据标识；

其中，当所述设置子模块所设置的获取数据标识的策略为当所述应用服务器初始化时，向所述管理服务器获取所述系统当前所有数据的数据标识时，所述存储子模块还用于存储所述系统当前的其他数据所对应的数据标识。

12.如权利要求9所述的应用服务器，其特征在于，还包括：

通信模块，与所述获取模块相连接，用于接收所述管理服务器发送的包含更新后的目标数据所对应的数据标识和/或新加入的数据的数据标识的通知消息，更新所述获取模块所获取的目标数据的数据标识或所述系统当前全部数据的数据标识。

13.一种管理服务器，应用于包括一个管理服务器、一个应用服务器和多个数据服务器的系统中，其特征在于，包括：

设置模块，用于设置数据库管理策略和读写负载调整策略；

处理模块，与所述设置模块相连接，用于根据所述设置模块所设置的数据库管理策略和读写负载调整策略，将所述系统中的数据分别存储于相应的数据服务器中；

标识模块，用于根据所述设置模块所设置的数据库管理策略和读写负载调整策略，为各所述数据服务器中的数据添加数据标识，所述数据标识包括所述数据的地址信息。

14.如权利要求13所述的管理服务器，其特征在于，所述多个数据服务器组成至少一个数据服务器群落，所述数据服务器群落中包含一个主数据服务器和至少一个从数据服务器，所述处理模块根据所述设置模块所设置的读写负载调整策略，将所述系统中的数据分别存储于相应的数据服务器中，具体为：

所述处理模块根据所述设置模块所设置的当前系统中的数据的读写负载调整策略，将所述数据分配给各所述数据服务器群落中相应的主数据服务器或从数据服务器进行存储；

其中，所述管理服务器分配给各所述数据服务器群落中的主数据服务器中存储的数据具有可以进行读操作和/或写操作的权限，所述管理服务器分配给各所述数据服务器群落中的从数据服务器中存储的数据只具有进行读操作的权限。

15.如权利要求13所述的管理服务器，其特征在于，

所述设置模块，还用于设置容灾策略；

所述处理模块，还用于根据所述设置模块所设置的容灾策略，分别为所述系统中全部或部分数据服务器建立备份服务器，并将所述数据服务器中所存储的数据复制到相应的备份服务器中。

16.如权利要求15所述的管理服务器，其特征在于，还包括：

调整模块，用于当所述数据服务器的数据不能被访问时，将所述数据服务器中的数据所对应的数据标识中所包含的所述数据的地址信息变更为所述数据服务器所对应的备份服务器的地址信息。

Images