CN102404390A - 高速实时数据库的智能化动态负载均衡方法 - Google Patents

Abstract

本发明公开了一种高速实时数据库的智能化动态负载均衡方法，本方法包括如下步骤：在每个客户端和集群服务器节点中配置内容一致的集群仲裁表；将后台数据存储模块划分为不同的物理存储分区；将客户端与每个集群服务器节点建立通讯连接；各个集群服务器节点维护各个集群服务器节点上的服务器端集群仲裁表内容一致；接收并处理客户端发送过来的任务；客户端对全局的虚拟IP地址发起数据读写的请求；网络通讯管理模块最终发送往目地集群服务器节点；目标集群服务器节点在接收到客户端提交来的请求后，进行必要的校验，然后对合法的请求进行处理。本法本方法灵活地整合了多个服务器节点的硬软件资源，达到硬件平台资源利用调度最优化。

Description

高速实时数据库的智能化动态负载均衡方法

技术领域

本发明涉及一种服务器动态负载均衡方法，具体来说涉及一种高速实时数据库的智能化动态负载均衡方法。

背景技术

目前，实时/历史数据库系统的部署技术中，无一例外都采用了传统双机热备的传统集群方式：两台服务器主机共享一个物理存储设备，两台主机之间通过心跳信号来决定谁将成为“主机”，谁将成为“备机”。同一时刻，只有其中一台主机可以成为“主机”并接管共享的阵列资源。也就是说，传统实时/历史数据库系统的双机热备技术中同时只有一台服务器主机在提供服务，其余另外一台是闲置的，当且仅当当前“主机”故障时，另外一台服务器才会进行实际的工作负担。如此以来导致的一个问题就是大多数情况下即便两台服务器都无故障，也只能发挥其中一台的业务处理能力而另外一台闲置，本发明将重点解决这个难题。

现有的技术的缺点主要体现在：

1.不能充分利用多台服务器的资源优势，大多数情况下昂贵的服务器资源是闲置的

2.在单机故障时，需要切换和控制权交替的资源数量庞大，造成业务阻塞时间相对较长

3.由于现行技术中的“非A即B”模型，造成对于业务负载逻辑的管理灵活性很差，无法有机地将资源、负载和需求整合到一起，部署更为高阶的技术方案

4.现有一些技术通过网络消息转发的方式来实现负载的分配，虽然一定程度上达到了负载分担的目地，但是多次的网络转发不仅造成了对网络带宽的极大浪费，而且由于转发所引起的性能降低非常明显。

发明内容

本发明的目的在于提供一种高速实时数据库的智能化动态负载均衡方法，本方法能够实现将多台服务器有机地整合在一起，形成一个服务器集群网络，并共享一个磁盘存储设备，各个服务都正常工作的情况下各自对外提供既定的业务处理负载，本方法灵活地整合了多个服务器节点的硬软件资源，达到硬件平台资源利用调度最优化。

本发明的目的可通过以下的技术措施来实现：

一种高速实时数据库的智能化动态负载均衡方法，包括如下步骤：

1)、在每个客户端中配置内容一致的客户端集群仲裁表，内容包括：

所有客户端统一使用的一个全局的虚拟IP地址；

各个集群服务器节点的物理信息：集群服务器节点的物理IP地址、监听端口；

各个集群服务器节点的逻辑信息：各集群服务器节点可处理的任务的标签范围；

各个集群服务器节点的接替节点：当前集群服务器节点故障时，接替处理任务的集群服务器节点号；

各个集群服务器节点对于各个任务的优先级列表；

2)、在每个集群服务器节点中配置内容一致的服务器端集群仲裁表，内容包括：

各个集群服务器节点的物理信息：集群服务器节点的物理IP地址、监听端口；

各个集群服务器节点的逻辑信息：各集群服务器节点可处理的任务的标签范围；

各个集群服务器节点的接替节点：当前集群服务器节点故障时，接替处理任务的集群服务器节点号；

各个集群服务器节点间的心跳超时间隔、集群服务器节点间的TCP发送和接收超时间隔、通讯失败重试次数；

各个集群服务器节点对于各个任务的优先级列表；

3)、将后台数据存储模块划分为不同的物理存储分区，各个集群服务器节点对应其中一个物理存储分区；

4)、将客户端与每个集群服务器节点建立通讯连接；并不断从可用的集群服务器节点上同步服务器端集群仲裁表的相应内容到客户端集群仲裁表中，用于保证客户端集群仲裁表和服务器端集群仲裁表中相应内容始终保持一致；

5)、各个集群服务器节点开始主控控制过程，用于维护各个集群服务器节点上的服务器端集群仲裁表内容一致；

6)、各个集群服务器节点开始负载配置过程，用于接收并处理客户端发送过来的任务，如果某个集群服务器节点出现故障，则根据服务器端集群仲裁表中的内容，将任务转发到下一个正常服务器上处理该任务；

7)、客户端对全局的虚拟IP地址发起数据读写的请求，该请求中包含该读写操作任务的标签，并根据所述客户端集群仲裁表来判断当前的任务应该被最终发往哪个目标集群服务器节点；

8)、网络通讯管理模块根据请求的类型和请求的数据将当前请求组成一个TCP数据包，在前后加入CRC校验信息以确保数据包的完整性；并与目标集群服务器节点模块建立TCP连接，并最终发送往目地集群服务器节点；

9)、目标集群服务器节点在接收到客户端提交来的请求后，进行必要的校验，然后对合法的请求进行处理，并对后台数据存储模块中对应的物理存储分区进行读写访问，丢弃非法的请求并将错误信息回复给客户端。

所述步骤5)中集群服务器节点的主控控制流程的具体过程是：

5a)：首先从当前集群服务器节点中读取自身的配置信息，用于构成当前集群服务器节点的服务器端集群仲裁表。

5b)：启动心跳接受线程：为每一个集群服务器节点提供一个单独的线程来接收其他集群服务器节点的心跳状态；

启动状态发布线程：为每一个集群服务器节点提供一个单独的线程将当前集群服务器节点的状态定时地发给集群服务器组中其它集群服务器节点；

各个集群服务器节点根据心跳接收线程和状态发布线程实时地将检测到的其他集群服务器节点的状态更新各自的服务端集群仲裁表，以使各个服务端集群仲裁表内容一致。

所述步骤6)中的负载配置过程的具体步骤如下：

6a)、各个集群服务器节点定时地轮询服务端集群仲裁表，如果发现服务器端集群仲裁表发生变化并表明其中有某个节点不可用时，进入下一步处理；或者，任何时刻，当检测到某个远端集群服务器节点不可用时，也进入下一步处理；

6b)、对不可用的集群服务器节点上的任务进行转移：根据优先级列表的内容，将该故障的集群服务器节点上的所有任务转移到各个任务所对应的最高优先级次级的集群服务器节点上；任务转移成功后，回到步骤6a)。

所述步骤6b)中将任务转移的具体过程如下：

b1)、对于不可用的集群服务器节点上的每一个任务，检查当前集群服务器节点是不是除故障节点外，最高优先级最高的集群服务器节点，如果不是，结束本流程；否则，进入下一步；

b2)、对于当前任务，发送“请求转换”的信息给其他各个集群服务器节点；

b3)、如果在集群服务器节点间的心跳接收线程的超时间隔内没有收到某个其它的集群服务器节点对该“请求转换”信号的确认回复，结束本流程；否则，进入下一步骤；

b4)、在服务器端集群仲裁表中将检测到的故障的集群服务器节点状态标记为不可用，并更改相应的优先级列表中能够处理该任务的各个集群服务器节点的新的优先级，最后，在当前集群服务器节点上启动相应操作来处理所述的转移的任务，最后，将“转化成功”的结果发布给其它节点。

所述步骤2)和步骤3)中，各个集群服务器节点对于各个任务的优先级列表具体形式为：对于某一个任务j，1＜j＜M，M为集群服务器节点可处理的任务的总个数，编号为i的集群服务器节点对于任务j具有最高的优先级1，1＜i＜N，N为集群服务器节点的总个数；编号i+1的集群服务器节点对于这个任务的优先级加1，即优先级为2，依次类推，一直编排完全部的集群服务器节点，且编号为i-1的集群服务器节点对于任务j的优先级最低，最低优先级为N；对于任务j+1，集群服务器节点i+1的优先级为1，依次类推。

所述步骤6a)轮询服务器端集群仲裁表的时间间隔为100毫秒。

所述步骤6a)中检测到某个远端集群服务器节点不可用的方式是：对某一个远端集群服务器节点的心跳接收失败；或者，向远端集群服务器节点的状态发布失败。

所述步骤8)中网络通讯管理模块还处理由于网络故障的超时重发以及在所有集群节点故障宕机时的本地磁盘文件缓存功能，在网络恢复后，再将本地磁盘文件恢复到远程集群服务器节点，以保证任何情况下数据都不会丢失。

所述步骤7)中客户端请求处理过程中如果请求执行失败了，错误结果会被回复到客户端，客户端根据错误的信息进行进一步的处理，具体过程是：如果失败的原因是因为在处理的过程中先前的集群服务器节点故障，则根据客户端集群仲裁表做出决策，决定当前请求应该被重发到哪一个作为接替节点的集群服务器节点上；如果接替节点不能处理，再寻找下一个接替节点，依次类推，如果经过一定的超时处理重试后，所有的服务器节点都不可用，那么报告这个请求最终执行失败。

本发明对比现有技术，有如下优点：

1、本方法实现了在正常多台服务器都正常工作的情况下，各自都对外提供既定的业务处理负载，充分利用了昂贵的服务器资源。与此同时，由于本发明的方案中业务负载分布在多个服务器之上，因此在故障切换和资源控制权交替的时候需要进行交替的资源数量减少，最大限度地降低了业务阻塞时间。可以有机地将服务器硬软件资源、负载和业务需求有机地整合在一起，进行灵活的分发和部署以进行更为高阶的技术部署方案，和当前新进的“云计算”方向相得益彰；

2、本方法不仅彻底解决传统技术模型的局限性，而且还将服务器节点扩展到N(N＞＝2)节点(现行技术中是2个节点)，灵活地整合了N个节点的硬软件资源，达到硬件平台资源利用调度最优化，形成真正意义上的“N-N集群”技术。相比传统的应用模型，在同样的硬件环境中软件的处理能力将提升到约N-1倍以上。本发明彻底解决了实时/历史数据库系统中的“动态负载均衡”难题，借助于本发明的技术，多台计算机资源可以被灵活地整合在一起，形成一个性能强劲的服务集群组，而对用户层而言，所有的这些服务器群组都是透明的；

3、本方法和现行的虚拟IP地址技术不同的是，本发明的集群阶段各自以节点的物理IP地址运行并提供服务，相比以往的一个内部往的物理地址进行数据转发的模式相比，这种虚拟IP地址技术可以完全屏蔽以往物理虚拟IP节点导致的数据转发延迟。不仅如此，使用物理IP地址的技术实现可以极大地降低内部网络由于转发所引起的带宽占用。简而言之，这里实现的虚拟IP技术是一种真正意义上的虚拟IP地址，并不在内部私有网络上实际存在，而是一个纯粹的虚拟地址。每一个物理节点都配置了完全一致的集群节点IP地址列表，列表中的IP地址先后顺序就是单点故障时服务器负载转移的优先级和顺序；

4、本方法使得当集群组中所有的服务器都处于正常工作状态时，由于各自只承担相对小的一部分业务负载，应用的请求被处理会很高效，表现在响应快速并且用户感受好；当集群组中有一台或者多台服务器出现故障的情况下，故障节点被转移到可以正常服务的节点上面。

附图说明

图1是本发明的高速实时数据库的智能化动态负载均衡方法的流程图；

图2是本发明的高速实时数据库的智能化动态负载均衡方法中的集群软件主控算法实现流程图；

图3是本发明的高速实时数据库的智能化动态负载均衡方法中的集群软件仲裁算法实现流程图；

图4是一个典型的集群负载配置模块中的集群仲裁表的内容示意图；

图5是本发明方法中各个集群服务器节点对于各个任务的优先级列表；

图6是拥有3个节点和3个任务的优先级列表结构。

具体实施方式

下面结合附图对本发明做进一步的详细说明，如图1所示，本发明所示的智能化动态负载均衡技术包含客户端SDK模块(100)、网络通讯管理模块(200)、集群服务器节点模块(300)和后台数据存储模块(400)。其中客户端SDK模块(100)包含集群负载配置模块(110)和SDK通讯仲裁模块(120)；在集群服务器节点模块(300)中，包含服务器端集群负载配置模块(310)、服务器端负载均衡仲裁模块(320)和服务器端数据管理模块(330)。其中服务器端数据管理模块(330)就是传统意义上的实时/历史数据库系统实例，不同的实时/历史数据库系统可能包含一个或者多个进程或者配置模块，在本发明的系统实施体系中，是其中一个局部模块。在本发明实施中，集群服务器节点模块(300)可能包含N个，N通常是大于等于2的服务器节点数目，不同于在现行实时/历史数据库系统的双机部署技术中，N为固定为2的双机冗余。后台数据存储模块(400)一般是存储系统，可以是目前主流的存储解决方案。

如图2所示，本发明的高速实时数据库的智能化动态负载均衡方法的完整处理步骤如下：

1)、首先，在每个客户端的集群负载均衡配置模块(110)中配置内容一致的客户端集群仲裁表，如图4所示，内容包括：

所有客户端统一使用的一个全局的虚拟IP地址；

各个集群服务器节点的物理信息：集群服务器节点的物理IP地址、监听端口；(以下将“集群服务器节点”简称为“节点”。)

各个集群服务器节点的逻辑信息：各集群服务器节点可处理的任务的标签范围；

各个集群服务器节点的接替节点：当前集群服务器节点故障时，接替处理任务的集群服务器节点号；

各个集群服务器节点对于各个任务的优先级列表；

2)、在每个集群服务器节点的集群负载配置模块(310)中配置内容一致的服务器端集群仲裁表，内容包括：

各个集群服务器节点的物理信息：集群服务器节点的物理IP地址、监听端口；

各个集群服务器节点的逻辑信息：各集群服务器节点可处理的任务的标签范围；

各个集群服务器节点的接替节点：当前集群服务器节点故障时，接替处理任务的集群服务器节点号；

各个集群服务器节点间的心跳超时间隔、集群服务器节点间的TCP发送和接收超时间隔、通讯失败重试次数；

服务器端集群负载配置模块(310)和客户端集群负载配置模块(110)作用是完全一样的，只不过服务器端集群负载配置模块(310)还包含心跳接收超时设置等其它参数。

各个集群服务器节点对于各个任务的优先级列表；具体形式如图5所示：对于某一个任务j，1＜j＜M，M为集群服务器节点可处理的任务的总个数，编号为i的集群服务器节点对于任务j具有最高的优先级1，1＜i＜N，N为集群服务器节点的总个数；编号i+1的集群服务器节点对于这个任务的优先级加1，即优先级为2，依次类推，一直编排完全部的集群服务器节点，且编号为i-1的集群服务器节点对于任务j的优先级最低，最低优先级为N；对于任务j+1，集群服务器节点i+1的优先级为1，依次类推。从而得到一个从高到底的优先级列表，并将优先级列表中的信息加入客户端集群仲裁表中；客户端集群仲裁表包含每一个服务器节点的状态和每一个任务在各个服务器节点上的优先级；如图5所示。

3)、将后台数据存储模块(400)划分为不同的物理存储分区，各个集群服务器节点对应其中一个物理存储分区；

(不同的物理存储分区具体是和集群服务器节点的数据管理模块(330)一对一对应的，当一个集群服务器节点的数据管理模块(330)从一个物理计算机转移到另外一个计算机的时候，这种对应关系不变。所有集群服务器节点的数据管理模块(330)启动后就如运行在一台独立服务器上面一样，接收SDK端的发起的请求并统一访问后台数据存储模块(400)以及进行相应的处理。)

4)、将客户端与每个集群服务器节点建立通讯连接；并不断从可用的集群服务器节点上同步服务器端集群仲裁表的相应内容到客户端集群仲裁表中，用于保证客户端集群仲裁表和服务器端集群仲裁表中相应内容始终保持一致；

(SDK通讯仲裁模块(120)根据服务器集群仲裁表来维护客户端集群仲裁表，客户端集群仲裁表和服务器端集群仲裁表是一致统一的，内容是相同的；工作循环：SDK通讯仲裁模块(120)和每一个集群服务器节点建立连接，根据客户端的集群负载均衡配置模块(110)中确立的优先级，始终从优先级最高的可用节点上同步服务器集群仲裁表到客户端集群仲裁表，因为服务器集群仲裁表由服务器端的负载均衡仲裁模块(320)同步和管理，保证客户端的这种工作方式的正确性。当SDK通讯仲裁模块(120)检测到某些服务器集群节点故障而导致的连接中断时，SDK通讯仲裁模块(120)会尝试重现建立连接，因此一旦有服务器节点故障又恢复后，SDK通讯仲裁模块(120)都会第一时间刷新到最新状态。)

5)、各个集群服务器节点的负载均衡仲裁模块(320)开始主控控制过程，用于维护各个集群服务器节点上的服务器端集群仲裁表内容一致，如图3所示，具体过程是：

5a)、首先从当前集群服务器节点中读取自身的配置信息，用于构成当前集群服务器节点的服务器端集群仲裁表。(在本发明的中，要求集群组中的各个节点的节点IP和负载设置参数完全一致，否则在后续的切换和负载交互的过程中可能出现冲突。)

5b)、启动心跳接受线程：为每一个集群服务器节点提供一个单独的线程来接收其他集群服务器节点的心跳状态；一个群集服务器节点在接收到一个来自其它节点的心跳状态后，如果接收到心跳的时间没有超过服务器集群负载配置模块(310)中设置的心跳接收超时间隔，则更新当前节点的集群仲裁表，标记发动端节点状态为可用，同时记录接收到心跳的时间；相反，如果在设置的心跳接收超时间隔内没有收到某个节点的心跳，则认为这个远端节点发生了故障，并标记该远端节点为不可用。(这里启动线程的数据和集群组中配置的节点数目一致，每一个节点通过单独的线程来进行心跳接受。这样设计的目的是为了避免单个节点网络故障或者其它主机故障而导致心跳的实时性。因此单点的故障完全不影响其它节点并且可以被其它节点实时准确地检测到。)

启动状态发布线程：为每一个集群服务器节点提供一个单独的线程将当前集群服务器节点的状态定时地发给集群服务器组中其它集群服务器节点；

各个集群服务器节点根据心跳接收线程和状态发布线程实时地将检测到的其他集群服务器节点的状态更新各自的服务端集群仲裁表，以使各个服务端集群仲裁表内容一致；

(状态发布线程用以确保其它节点可以实时地同步到集群组中其它节点去。和心跳接收部分的策略一样，状态发送部分也是为每一个集群服务器节点提供一个单独的线程来进行状态发布，其主要的原因也是为了避免单点的网络故障、延时或者其它故障导致心跳的实时性问题。值得注意的是，虽然在主控算法中引入了集群组中节点数目两倍的线程数，但是这些线程都是轻量级的，大多数时间都是在等待触发或者发送流量很小的心跳或者状态信息帧，因此对节点主机、整理集群组网络等都不会造成资源竞争问题。)

6)、各个集群服务器节点的负载配置模块(310)开始负载配置过程，用于接收并处理客户端发送过来的任务，如果某个集群服务器节点出现故障，则根据服务器端集群仲裁表中的内容，将任务转发到下一个正常服务器上处理该任务，负载配置具体过程如下：

6a)、服务器端负载均衡仲裁模块(320)定时地轮询服务端集群仲裁表，如果发现服务器端集群仲裁表发生变化并表明其中有某个节点不可用时，进入下一步处理；或者，任何时刻，当检测到某个远端集群服务器节点不可用时，也进入下一步处理；否则，重复步骤6a)；

所述轮询服务器端集群仲裁表的时间间隔为100毫秒；

其中，检测到某个远端集群服务器节点不可用的方式是：对某一个远端集群服务器节点的心跳接收失败；或者，向远端集群服务器节点模块(300)状态发布失败。

紧急事件发生的含义也就是当状态发布线程检测到发往某一个集群节点的动作执行失败，通常意味着对端节点故障。对于这个故障检测，另一方面是通过“心跳接收”来被动检测到某个节点不可用了，是双向的，一方面是通过“状态发布”线程来主动检测到某个节点不可用了；因为实际存在一些网络或者硬件原因，一个方向的信息是畅通的，而相反的方向是阻塞的，遇到这样的情况会导致仲裁表更新不准确或者延时，从而使得状态检测更加可靠严谨。

轮询的目地是周期性地查看服务端集群仲裁表是否发生变化，如果有变化，根据这个变化去决定是否要做一些操作来应对这个变化。比如对于某个任务，优先级第一的节点故障了，那么标记该集群服务器节点“不可用”，同时，按照优先级列表，该任务由优先级次一级的集群服务器节点来处理，具体判断和的处理过程如下：

如果检测到有紧急事件，首先还是会改变服务器集群仲裁表，因为紧急事件肯定是有状态发布线程或者心跳接收线程发起的，当检测到紧急事件时，无论状态发布线程还是心跳接收线程，首先都是根据紧急事件是发生在和哪一个节点的通讯过程中，然后将相应节点对应的状态改为不可用(这一点先前可能说得不清楚)，轮询的动作只根据服务器集群仲裁表的情况执行相应的动作，有变化继续执行步骤c，无变化就回到步骤a；另外，轮询检查的目地是因为现在有状态发布和心跳接收两个方向的通讯，心跳接收线程除了将接收到其它节点的心跳后，认为这个发送节点可用的同时，还会将接收到心跳的时间记录下来；但是在某些情况下，比如网络路由器故障等，会出现这两个方向的通讯阻塞而没有返回，因此当前轮询的节点是要避免这种情况，通过设置在服务器集群负载配置模块(310)中的心跳接收超时间隔来确保服务端仲裁表的准确性。请结合步骤二的补充整理一下)，并回到步骤6a)；否则，进入下一步骤；

6b)、对不可用的集群服务器节点上的任务进行转移：根据优先级列表的内容，将该故障的集群服务器节点上的所有任务转移到各个任务所对应的最高优先级次级的集群服务器节点上。由于不可用的集群服务器节点，即表明该节点发生故障无法正常处理各种，需要将该故障节点上的所有任务都转移到其他正常的集群服务器节点上，因此需要进行任务的转移。这个检查过程是各个集群服务器节点都在并行地进行，但是针对同一个范围内的标签对应的处理负载任务，各个节点的优先级是不一样的。任务转移结束后，回到步骤6a)。

步骤6b)的任务进行转移的具体过程如下：

b1)、对于不可用的集群服务器节点上的每一个任务，检查当前集群服务器节点是不是最高优先级次级的集群服务器节点，如果不是，回到步骤a；否则，进入下一步；

b2)、对于当前任务，发送“请求转换”的信息给其他各个集群服务器节点；(发送这个“请求转换”是告诉其它节点，已经有一个优先级较高的活动节点在处理这个任务了，其它节点不需要针对这个事件做任何动作了)；

b3)、如果在集群服务器节点间的心跳接收线程的超时间隔内没有收到某个其它的集群服务器节点对该“请求转换”信号的确认回复，则回到步骤a；否则，进入下一步骤；因为，确立为优先级最高的节点Node1，在向其他节点(Node2-NodeN)等待确认“请求转换”信号的时候，如果其中一个节点NodeX(2＜X＜N)又发生故障了，因此无法对当前节点的“请求转换”信息进行回复，而这个节点X的故障可能会导致优先级列表发生新的变化，因此，这个时候要重新来开始负载配置过程，即可重新根据优先级列表重新进行任务的转移操作。

b4)、在服务器端集群仲裁表中将检测到的故障的集群服务器节点状态标记为不可用，并更改相应的优先级列表中能够处理该任务的各个集群服务器节点的新的优先级，最后，在当前集群服务器节点上启动相应操作来处理所述的转移的任务，最后，将“转化成功”的结果发布给其它节点。由于每一个集群服务器节点都在进行负载配置过程，因此，总有一个优先级最高的节点来接替并处理需要转移的任务。

举一个比较简单的例子来说明一个仲裁和任务的优先级处理逻辑：

如图6所示的优先级列表，在最简单有3个服务器节点，也只有3个任务的情况下，那么默认情况下：Task1在Node1上有最高的优先级，Task2在Node2上有最高的优先级，Task3在Node3上有最高的优先级；如果Node3故障，那么Task3由于有用最高固定优先级的节点故障，其最高可用优先级为Node1上面的优先级2，因此Task3应该被Node1启动起来。在上面的情况中，Node3故障，Node1和Node2都会检测到，Node1检测到Node3故障后，根据Node1/Node2/Node3都完全一致的仲裁表和任务优先级表，Node1可以判断出自己成为Task3最高的可用优先级节点，因此Node1向Node2发送“请求转换”的消息，Node2回复后开始执行启动Task3；如果没有收到Node2的回复，说明Node2故障了；这种情况下就不继续下面的流程了，而是回到第一步，根据最新的仲裁表执行流程；因为Node2故障意味着Task2的最高可用优先级几点也变成Node1了(Node3已经故障了)。这种情况下Task1/Task2/Task3都会被启动在Node1上面。

实际应用中，同一个节点上可能有多个任务Task和节点Node。各个节点都在发布状态并接收心跳，以及超时轮询操作。任何一个Node的故障其它节点都会检测到，只是由于任务分布优先级的不一样，各个节点要做的动作是不一样的，而任何一个节点在执行动作的过程中，相对于自己的其它节点还可能有故障了。

5)、客户端的SDK模块(100)对全局的虚拟IP地址发起数据读写的请求，该请求中包含该读写操作任务的标签，所述请求由SDK通讯仲裁模块(120)根据集群负载配置模块(110)的客户端集群仲裁表来判断当前的任务应该被最终发往哪个目标集群服务器节点；

6)、网络通讯管理模块(200)根据请求的类型和请求的数据(例如：标签号、开始时间和结束时间等)将当前请求组成一个TCP数据包，在前后加入CRC校验信息以确保数据包的完整性；并与目标集群服务器节点模块建立TCP连接，SDK通讯仲裁模块(120)选择已经建立到目标集群服务器节点模块(300)的TCP连接，通过网络通讯管理模块(200)来管理并最终发送往目地服务器；

另外网络通讯管理模块(200)还处理由于网络故障的超时重发以及在所有集群节点故障宕机时的本地磁盘文件缓存功能，在网络恢复后，再将本地磁盘文件恢复到远程集群服务器节点，以保证任何情况下数据都不会丢失。

步骤6)的发送过程中，如果目标集群服务器节点由于硬软件故障等原因当前不可用，那么SDK通讯仲裁模块(120)会按照客户端集群仲裁表中的信息来查找下一个可用的集群服务器节点，直到找到一个正常可用的集群服务器节点；最终将这个请求提交到正确并工作正常的集群服务器节点上面去；

7)、目标集群服务器节点的数据管理模块(330)在接收到客户端提交来的请求后，进行必要的校验，然后对合法的请求进行处理，并对后台数据存储模块(400)中对应的物理存储分区进行读写访问，丢弃非法的请求并将错误信息回复给客户端。

请求处理过程中如果请求执行失败了，错误结果会被回复到客户端，客户端根据错误的信息进行进一步的处理，具体过程是：如果失败的原因是因为在处理的过程中先前的集群服务器节点故障(宕机、断电或者OS异常等)，SDK通讯仲裁模块(120)将根据客户端集群仲裁表做出决策，决定当前请求应该被重发到哪一个作为接替节点的集群服务器节点上。如果接替节点不能处理，再寻找下一个接替节点，依次类推，如果经过一定的超时处理重试后，所有的服务器节点都不可用，那么报告这个请求最终执行失败。通常这是一种极端异常的请求，是严重的事故。

本发明的内容主要包含实时/历史数据库系统服务器端的负载均衡模块和应用程序开发端SDK内部负载均衡模块。对于SDK端的负载均衡模块，现行技术中的实现一般是配置一个虚拟的IP地址，不论后台集群服务器各个节点的状态如何，对应客户端都是透明的，SDK端的接口都是针对这个唯一的虚拟IP地址里进行数据的写入和查询操作。而本发明的中SDK端的实现是基于一个和服务器集群端配置内容一样的集群节点物理IP地址列表，其中可以包含N(N＞＝2)个物理IP地址，本发明的实现将客户端SDK对该物理IP地址列表实现封装成一个统一的模块。对于传统的集群部署方式或者其它地方系统，可以在不修改应用逻辑的情况下将本发明的技术集成到现有的应用系统中，当然也可以无缝地替换已经存在的其它集群解决方案。

本发明SDK配置文件主要包含各个几点的物理IP地址、节点默认承担的负载比重和节点的参数，例如负载转移策略、负载恢复策略等。与此同时，我们SDK内部实现会提供一个虚拟IP地址给用户，这个虚拟IP可以是非常特殊的IP地址，不和网络中的物理IP地址冲突即可，例如：“99.99.99.99”，因为它仅仅是一个纯用户层面的虚拟地址。SDK内部智能维护和管理“用户-＞虚拟IP-＞配置映射表-＞远端集群组”的通讯逻辑，实际上因为内部维护的是当前客户端和集群组内各个节点的点对点连接，通过这种技术实现的通讯方式十分高效，避免和传统技术中通过网络数据包转发的方式引起的性能损失。

本发明中服务器端的负载均衡模块的实现和传统的集群实现方式也有很大的区别，和现行的虚拟IP地址技术不同的是，本发明的集群阶段各自以节点的物理IP地址运行并提供服务，相比以往的一个内部往的物理地址进行数据转发的模式相比，这种虚拟IP地址技术可以完全屏蔽以往物理虚拟IP节点导致的数据转发延迟。不仅如此，使用物理IP地址的技术实现可以极大地降低内部网络由于转发所引起的带宽占用。简而言之，这里实现的虚拟IP技术是一种真正意义上的虚拟IP地址，并不在内部私有网络上实际存在，而是一个纯粹的虚拟地址。虚拟IP地址的技术实现需要结合用户层的统一访问技术实现所阐述的技术细节来实现，在这里我们只阐述内部节点的同步转移机制。每一个物理节点都配置了完全一致的集群节点IP地址列表，列表中的IP地址先后顺序就是单点故障时服务器负载转移的优先级和顺序。

本发明可以将多台服务器有机地整合在一起，形成一个服务器集群网络，各个服务器节点通过内部私有网络连接起来，内部的私有网络一般是千兆高速网络。这个服务器集群组共享一个磁盘存储设备，集群组内的任何一台服务器都可以访问这个共享的磁盘存储设备。在集群组内部的各个服务器节点上，运行本发明设计中的实时通讯软件，用于各个节点间必要信息的实时同步和分发同步缓存数据。实时通讯软件将整个集群组有机地组织在一起，对外提供一个统一的IP地址，任何时候上层应用和最终用户只需要向这个统一的IP地址发起请求即可。只有集群组里面有一台服务器能够提供正常的对外服务，其它应用都可以在不间断业务的情况进行日常工作，对应用软件来说是完全透明的，只不过唯一的差别在于：当集群组中所有的服务器都处于正常工作状态时，由于各自只承担相对小的一部分业务负载，应用的请求被处理会很高效，表现在响应快速并且用户感受好；当集群组中有一台或者多台服务器出现故障的情况下，故障节点被转移到可以正常服务的节点上面，导致优先的可用服务节点的负载率较高，极端情况下可能会对上层应用造成延迟。但是这个情况是客观存在且不可避免的，因为最极端的负载率情况和传统现行技术实现是完全等同的。

本发明所述的实时/历史数据库系统的智能化负载均衡技术应用于流程行业需要7*24小时稳定运行的数据库服务器系统上，也可以应用于任何有负载均衡需求同时不想引入其它复杂的第三方硬软件模块的系统中。

本发明的实施方式不限于此，在本发明上述基本技术思想前提下，按照本领域的普通技术知识和惯用手段对本发明内容所做出其它多种形式的修改、替换或变更，均落在本发明权利保护范围之内。

Claims (9)

1.一种高速实时数据库的智能化动态负载均衡方法，包括如下步骤：

1)、在每个客户端中配置内容一致的客户端集群仲裁表，内容包括：

所有客户端统一使用的一个全局的虚拟IP地址；

各个集群服务器节点的物理信息：集群服务器节点的物理IP地址、监听端口；

各个集群服务器节点的逻辑信息：各集群服务器节点可处理的任务的标签范围；

各个集群服务器节点的接替节点：当前集群服务器节点故障时，接替处理任务的集群服务器节点号；

各个集群服务器节点对于各个任务的优先级列表；

2)、在每个集群服务器节点中配置内容一致的服务器端集群仲裁表，内容包括：

各个集群服务器节点的物理信息：集群服务器节点的物理IP地址、监听端口；

各个集群服务器节点的逻辑信息：各集群服务器节点可处理的任务的标签范围；

各个集群服务器节点的接替节点：当前集群服务器节点故障时，接替处理任务的集群服务器节点号；

各个集群服务器节点间的心跳超时间隔、集群服务器节点间的TCP发送和接收超时间隔、通讯失败重试次数；

各个集群服务器节点对于各个任务的优先级列表；

3)、将后台数据存储模块划分为不同的物理存储分区，各个集群服务器节点对应其中一个物理存储分区；

4)、将客户端与每个集群服务器节点建立通讯连接；并不断从可用的集群服务器节点上同步服务器端集群仲裁表的相应内容到客户端集群仲裁表中，用于保证客户端集群仲裁表和服务器端集群仲裁表中相应内容始终保持一致；

5)、各个集群服务器节点开始主控控制过程，用于维护各个集群服务器节点上的服务器端集群仲裁表内容一致；

6)、各个集群服务器节点开始负载配置过程，用于接收并处理客户端发送过来的任务，如果某个集群服务器节点出现故障，则根据服务器端集群仲裁表中的内容，将任务转发到下一个正常服务器上处理该任务；

7)、客户端对全局的虚拟IP地址发起数据读写的请求，该请求中包含该读写操作任务的标签，并根据所述客户端集群仲裁表来判断当前的任务应该被最终发往哪个目标集群服务器节点；

8)、网络通讯管理模块根据请求的类型和请求的数据将当前请求组成一个TCP数据包，在前后加入CRC校验信息以确保数据包的完整性；并与目标集群服务器节点模块建立TCP连接，并最终发送往目地集群服务器节点；

9)、目标集群服务器节点在接收到客户端提交来的请求后，进行必要的校验，然后对合法的请求进行处理，并对后台数据存储模块中对应的物理存储分区进行读写访问，丢弃非法的请求并将错误信息回复给客户端。

2.根据权利要求1所述的高速实时数据库的智能化动态负载均衡方法，其特征在于：所述步骤5)中集群服务器节点的主控控制流程的具体过程是：

5a)、首先从当前集群服务器节点中读取自身的配置信息，用于构成当前集群服务器节点的服务器端集群仲裁表；

5b)、启动心跳接受线程：为每一个集群服务器节点提供一个单独的线程来接收其他集群服务器节点的心跳状态；

启动状态发布线程：为每一个集群服务器节点提供一个单独的线程将当前集群服务器节点的状态定时地发给集群服务器组中其它集群服务器节点；

各个集群服务器节点根据心跳接收线程和状态发布线程实时地将检测到的其他集群服务器节点的状态更新各自的服务端集群仲裁表，以使各个服务端集群仲裁表内容一致。

3.根据权利要求1所述的高速实时数据库的智能化动态负载均衡方法，其特征在于：所述步骤6)中的负载配置过程的具体步骤如下：

6a)、各个集群服务器节点定时地轮询服务端集群仲裁表，如果发现服务器端集群仲裁表发生变化并表明其中有某个节点不可用时，进入下一步处理；或者，任何时刻，当检测到某个远端集群服务器节点不可用时，也进入下一步处理；

6b)、对不可用的集群服务器节点上的任务进行转移：根据优先级列表的内容，将该故障的集群服务器节点上的所有任务转移到各个任务所对应的最高优先级次级的集群服务器节点上；任务转移成功后，回到步骤6a)。

4.根据权利要求1所述的高速实时数据库的智能化动态负载均衡方法，其特征在于：所述步骤6b)中将任务转移的具体过程如下：

b1)、对于不可用的集群服务器节点上的每一个任务，检查当前集群服务器节点是不是除故障节点外，最高优先级最高的集群服务器节点，如果不是，结束本流程；否则，进入下一步；

b2)、对于当前任务，发送“请求转换”的信息给其他各个集群服务器节点；

b3)、如果在集群服务器节点间的心跳接收线程的超时间隔内没有收到某个其它的集群服务器节点对该“请求转换”信号的确认回复，结束本流程；否则，进入下一步骤；

b4)、在服务器端集群仲裁表中将检测到的故障的集群服务器节点状态标记为不可用，并更改相应的优先级列表中能够处理该任务的各个集群服务器节点的新的优先级，最后，在当前集群服务器节点上启动相应操作来处理所述的转移的任务，最后，将“转化成功”的结果发布给其它节点。

5.根据权利要求1所述的高速实时数据库的智能化动态负载均衡方法，其特征在于：所述步骤2)和步骤3)中，各个集群服务器节点对于各个任务的优先级列表具体形式为：对于某一个任务j，1＜j＜M，M为集群服务器节点可处理的任务的总个数，编号为i的集群服务器节点对于任务i具有最高的优先级1，1＜i＜N，N为集群服务器节点的总个数；编号i+1的集群服务器节点对于这个任务的优先级加1，即优先级为2，依次类推，一直编排完全部的集群服务器节点，且编号为i-1的集群服务器节点对于任务j的优先级最低，最低优先级为N；对于任务j+1，集群服务器节点i+1的优先级为1，依次类推。

6.根据权利要求1所述的高速实时数据库的智能化动态负载均衡方法，其特征在于：所述步骤6a)轮询服务器端集群仲裁表的时间间隔为100毫秒。

7.根据权利要求1所述的高速实时数据库的智能化动态负载均衡方法，其特征在于：所述步骤6a)中检测到某个远端集群服务器节点不可用的方式是：对某一个远端集群服务器节点的心跳接收失败；或者，向远端集群服务器节点的状态发布失败。

8.根据权利要求1所述的高速实时数据库的智能化动态负载均衡方法，其特征在于：所述步骤8)中网络通讯管理模块还处理由于网络故障的超时重发以及在所有集群节点故障宕机时的本地磁盘文件缓存功能，在网络恢复后，再将本地磁盘文件恢复到远程集群服务器节点，以保证任何情况下数据都不会丢失。

9.根据权利要求1所述的高速实时数据库的智能化动态负载均衡方法，其特征在于：所述步骤7)中客户端请求处理过程中如果请求执行失败了，错误结果会被回复到客户端，客户端根据错误的信息进行进一步的处理，具体过程是：如果失败的原因是因为在处理的过程中先前的集群服务器节点故障，则根据客户端集群仲裁表做出决策，决定当前请求应该被重发到哪一个作为接替节点的集群服务器节点上；如果接替节点不能处理，再寻找下一个接替节点，依次类推，如果经过一定的超时处理重试后，所有的服务器节点都不可用，那么报告这个请求最终执行失败。

Images