CN108199909A - 一种基于一致性哈希的高可用负载均衡系统 - Google Patents

Abstract

本发明公开了一种基于一致性哈希的高可用负载均衡系统，包含信息采集模块、信息注册模块和客户端插件；信息采集模块用于采集应用服务节点的CPU、内存信息，定时向信息注册模块发送心跳协议包，表明应用服务节点自身的存活；信息注册模块根据信息采集模块发送的消息，将对应的应用服务节点加入存活列表，并根据CPU和内存的负载信息生成每个节点对应的权重；客户端插件从信息注册模块获得应用服务集群存活节点地址以及负载信息，生成一致性哈希环，并根据客户端应用程序的请求返回应用服务节点IP。本发明能够实现负载均衡器Active/Active高可用，可以在更短的时间内使服务集群的变更情况趋于收敛，可以使物理器资源得到充分的利用，具有较好的服务表现和可靠性。

Description

一种基于一致性哈希的高可用负载均衡系统

技术领域

本发明涉及高可用负载均衡技术，尤其涉及一种基于一致性哈希的高可用负载均衡系统。

背景技术

目前，Web应用中普遍使用负载均衡技术来支持服务器的横向扩展。业界针对应用服务集群一般通过部署负载均衡服务作为集群的入口，将工作负载按照一定的策略(轮询、权重、随机)转发到后端的一组应用服务上，实现应用服务的高可用性和安全性。

负载均衡服务器本身的高可用通常是通过主备两台或多台负载均衡服务器实现，当主服务器停机时，备用服务器接管负载均衡功能。这样的方案有两个缺点：主备切换有一定的延迟，在这段时间内应用服务无响应；备份节点长期处于等待状态，资源没有得到合理的利用。

发明内容

本发明的主要目的在于针对传统负载均衡高可用方案中主备节点切换延迟以及备份节点资源浪费的问题，提供一种基于一致性哈希的高可用负载均衡系统。

本发明的目的是通过以下技术方案来实现：一种基于一致性哈希的高可用负载均衡系统，该系统包含信息采集模块、信息注册模块和客户端插件；具体功能如下：

信息采集模块：该模块安装在应用服务节点上，用于采集应用服务节点的CPU、内存信息，并定时向信息注册模块发送心跳协议包，表明应用服务节点自身的存活，心跳协议包以UDP协议为载体；

信息注册模块：根据信息采集模块发送的消息，将对应的应用服务节点加入存活列表，并根据CPU和内存的负载信息生成每个节点对应的权重；

客户端插件：从信息注册模块获得应用服务集群存活节点地址以及负载信息，生成一致性哈希环，并根据客户端应用程序的请求返回应用服务节点的IP，连接应用服务节点。

进一步地，所述心跳协议包包括用于检测识别心跳功能的字符串、CPU内核数和CPU使用百分比、剩余内存大小。

进一步地，所述信息注册模块中，节点的权重公式如下：

节点权重＝节点空闲内存*100/节点总内存+(100-节点CPU使用率)*节点CPU核数/节点CPU总核数)

进一步地，所述信息注册模块包括“南北”两个接口：“南口”用于接收每一个客户端插件的请求，并针对该请求返回应用服务存活信息和权重；“北口”用于接收信息采集模块发送的信息，在接到信息采集模块推送过来的消息后，针对每个UDP包建立一个worker线程；worker线程将对接收到的数据进行处理，然后存储到Heartbeat仓库中；Heartbeat仓库中的数据将以一定的时间间隔被另外一个固定的check_live线程读取，check_alive线程从Heartbeat仓库得到返回值后，维护一个节点存活列表临时变量，然后等待客户端插件的请求，将数据返回给客户端插件。

进一步地，所述worker线程收到“北口”传递过来的数据后，将该数据整理并存入Heartbeat仓库中，具体为：用发送者的IP地址作为字典的键，然后新生成一个时间戳与剩余字段拼接在一起，作为对应的值，所述剩余字段包括CPU内核数、CPU使用百分比、剩余内存大小。

进一步地，所述Heartbeat仓库是一个具有字典存储功能的类对象，并且具有对对象内部数据进行审查的功能，用于存储所有存活的应用服务节点以及相关信息。

进一步地，所述信息注册模块只有一个Heartbeat仓库，会有多个worker线程同时往Heartbeat仓库里写数据更新节点信息；当一个worker线程往Heartbeat更新数据时，先给这条数据上锁，完成数据更新后进行解锁操作，保证同一时刻一条记录只有一个写操作。

进一步地，当check_alive线程要求获取最新的存活主机列表时，Heartbeat仓库检测不存活的主机，首先记录系统当前的时间戳，减去设定的超时间隔timeout，将值设为limit；然后对Heartbeat仓库字典中的每一条节点的时间戳和设定的limit值进行比对，大于等于limit的跳过；小于limit的，标记为节点死亡，将其从整个Heartbeat仓库字典中移除出去，之后将整个Heartbeat字典返回给check_alive线程。

进一步地，所述客户端插件执行以下操作：

①.客户端插件启动时，向信息注册模块获取应用服务列表，并据此构建一致性哈希环，用于为客户端选择处理请求的应用服务器节点，同时将超时计数器变量count初始化为0；

②.客户端生成节点迭代器，用于从步骤①生成的一致性哈希环中根据权重返回最优应用服务节点；

③.调用步骤②的节点迭代器，获取一个最优应用服务节点；

④.向选定的应用服务节点发送请求并设定计时器；

⑤.如果超时仍没有收到响应，则count加1，同时检测超时count次数是否已经超过设定超时次数，如果没有，则转到步骤②节点迭代器，从环中取下一个节点再次进行请求，如果超时次数超过或刚好等于设定超时次数，需要更新本地应用服务存活列表，转到步骤①，向信息注册模块获取应用服务列表，重新生成一致性哈希环；

⑥.如果本次请求正常返回，则正常结束，如果有新的请求，则从步骤②正常开始。

本发明的有益效果是：

(1)实现负载均衡器Active/Active高可用，负载均衡可以作为集群存在，当一台节点停机后，用户的请求将分配到另外一台存活节点上，中间不会出现请求延迟，不影响客户端体验。而传统的Active/Passive高可用方案节点宕机时，会出现一段时间的停机时间。

(2)可以在更短的时间内使服务集群的变更情况趋于收敛，并且采用一致性哈希作为客户端的调度方案，再辅以一定的负载权重，可以使物理器资源得到充分的利用。

(3)使用一致性哈希作为客户端的调度算法。传统的做法是在服务器端做调度，本发明在客户端做服务地址调度，一致性哈希算法再辅以注册机制和超时机制，具有较好的服务表现和较高的可靠性。

附图说明

图1为本发明高可用负载均衡系统的模块关系图；

图2为信息注册模块功能流程；

图3Heartbeat仓库的结构图；

图4Heartbeat仓库检测不存活主机示意图；

图5为客户端插件功能流程。

具体实施方式

本发明提供的一种基于一致性哈希的高可用负载均衡系统，该系统包含信息采集模块、信息注册模块和客户端插件，如图1所示。

(1)信息采集模块：信息采集模块(Module Gather and Report，简称MGR)，安装在应用服务节点上，收集服务器的CPU、内存信息，并定时(1分钟、3分钟、5分钟)向信息注册模块发送心跳协议包，表明自身的存活。发送的心跳协议包主要包括以下内容：一个用于检测识别心跳功能的字符串、CPU内核数和CPU使用百分比，剩余内存大小(以M为单位)。心跳协议包以UDP协议为载体，具体格式顺序如下表所示，每一个应用服务节点都要将该模块作为后台服务运行。

(2)信息注册模块：信息注册模块(Module Registry and Weight，简称MRW)主要用于接收信息采集模块发送的存活应用服务节点的消息，同时完成响应客户端插件的请求。根据信息采集模块发送的消息将对应的主机加入存活列表，并根据CPU和内存的负载信息生成每个节点对应的权重，权重设置公式：

节点权重＝节点空闲内存*100/节点总内存+(100-节点CPU使用率)*节点CPU核数/节点CPU总核数)

该模块包括“南北”两个接口：“南口”⑥用于接收每一个客户端插件的请求，并针对该请求返回应用服务存活信息和权重；“北口”①主要用于接收信息采集模块发送的信息，在接到信息采集模块②推送过来的消息后，会针对每个UDP包建立一个线程worker③。worker线程将对接收到的数据处理，然后存储到Heartbeat④仓库中。之后Heartbeat仓库中的数据将以一定的时间间隔被另外一个固定的线程check_live⑤读取，check_alive线程从Heartbeat仓库得到返回值后，check_alive线程将维护一个节点存活列表临时变量。然后等待客户端插件⑦的请求，将数据返回给客户端插件，如图2所示。

“南口”：用于接收每一个客户端插件的请求；

“北口”：用于接收信息采集模块发送的信息；

worker线程：worker线程收到“北口”传递过来的数据后，会将该数据整理并存入Heartbeat仓库中。用发送者的IP地址作为字典的键，然后新生成一个时间戳与剩余的字段拼接在一起，作为对应的值。在Heartbeat仓库中存储条目的格式如下：

check_alive线程：作为整个模块中的监控线程，以一定的时间间隔(默认30秒)连接Heartbeat仓库请求存活应用服务节点信息。

Heartbeat仓库：Heartbeat仓库是一个具有字典存储功能的类对象，并且具有对对象内部数据进行审查的功能，主要用于存储所有存活的应用服务节点以及相关信息。Heartbeat仓库的结构如图3所示。

整个信息注册模块只有一个Heartbeat仓库，会有多个worker线程同时往Heartbeat仓库里写数据更新节点信息，需要在存储数据的过程中对该Heartbeat仓库上锁，如：当一个worker线程往Heartbeat更新数据时，会先调用lock.acquire()给这条数据上锁，然后调用update_item()更新数据，完成数据更新后调用lock.release()解锁，保证同一时刻一条记录只有一个写操作；

当check_alive线程要求获取最新的存活主机列表时，Heartbeat仓库将调用Reject函数功能，检测不存活的主机；当Reject函数被调用时，首先调用time.time()，记录系统当前的时间戳，减去设定的超时间隔timeout(默认60秒)，将值设为limit。然后check_server_status()函数对Heartbeat仓库字典中的每一条节点的时间戳(timestamp)和设定的limit值进行比对，大于等于limit的跳过；小于limit的，标记为节点死亡，通过pop_inactive_servers()将主机从整个Heartbeat仓库字典中移除出去，过程如图4所示。之后，将整个Heartbeat字典返回给check_alive线程。

(3)客户端插件：从信息注册模块获得应用服务集群存活地址以及相关负载信息，生成一致性哈希环，并根据客户端应用程序的请求，连接应用服务节点。该模块安装在每一个需要访问后台应用服务的客户端上。

在每个客户端插件的进程中，都会执行以下操作，如图5所示：

①.客户端插件启动时，向信息注册模块获取应用服务列表，并据此构建一致性哈希环，用于为客户端选择处理请求的应用服务器节点，同时将超时计数器变量count初始化为0；

②.客户端生成节点迭代器，用于从步骤①生成的一致性哈希环中根据权重返回最优应用服务节点；

③.调用步骤②的节点迭代器，获取一个最优应用服务节点；

④.向选定的应用服务节点发送请求并设定计时器；

⑤.如果超时仍没有收到响应，则count计数器加1，同时检测超时count次数是否已经超过三次，如果没有，则转到步骤②节点迭代器，从环中取下一个节点再次进行请求，此时获得的节点一定是不同于上一个“暂定失效”的节点的。如果超时次数已经超过或刚好等于三次，说明已经出现严重错误，需要更新本地的应用服务存活列表，转到步骤①，向信息注册模块获取应用服务列表，重新生成一致性哈希环。

⑥.如果本次请求正常返回，则正常结束，如果有新的请求，则从步骤②正常开始。

以上所述仅为本发明创造的较佳实施例而已，并不用以限制本发明创造，凡在本发明创造的精神和原则之内所作的任何修改、等同替换和改进等，均应包含在本发明创造的保护范围之内。

Claims (9)

1.一种基于一致性哈希的高可用负载均衡系统，其特征在于，该系统包含信息采集模块、信息注册模块和客户端插件；

信息采集模块：该模块安装在应用服务节点上，用于采集应用服务节点的CPU、内存信息，并定时向信息注册模块发送心跳协议包，表明应用服务节点自身的存活，心跳协议包以UDP协议为载体；

信息注册模块：根据信息采集模块发送的消息，将对应的应用服务节点加入存活列表，并根据CPU和内存的负载信息生成每个节点对应的权重；

客户端插件：从信息注册模块获得应用服务集群存活节点地址以及负载信息，生成一致性哈希环，并根据客户端应用程序的请求返回应用服务节点的IP，连接应用服务节点。

2.根据权利要求1所述的一种基于一致性哈希的高可用负载均衡系统，其特征在于，所述心跳协议包包括用于检测识别心跳功能的字符串、CPU内核数和CPU使用百分比、剩余内存大小。

3.根据权利要求1所述的一种基于一致性哈希的高可用负载均衡系统，其特征在于，所述信息注册模块中，节点的权重公式如下：

节点权重＝节点空闲内存*100/节点总内存+(100-节点CPU使用率)*节点CPU核数/节点CPU总核数)

4.根据权利要求1所述的一种基于一致性哈希的高可用负载均衡系统，其特征在于，所述信息注册模块包括“南北”两个接口：“南口”用于接收每一个客户端插件的请求，并针对该请求返回应用服务存活信息和权重；“北口”用于接收信息采集模块发送的信息，在接到信息采集模块推送过来的消息后，针对每个UDP包建立一个worker线程；worker线程将对接收到的数据进行处理，然后存储到Heartbeat仓库中；Heartbeat仓库中的数据将以一定的时间间隔被另外一个固定的check_live线程读取，check_alive线程从Heartbeat仓库得到返回值后，维护一个节点存活列表临时变量，然后等待客户端插件的请求，将数据返回给客户端插件。

5.根据权利要求4所述的一种基于一致性哈希的高可用负载均衡系统，其特征在于，所述worker线程收到“北口”传递过来的数据后，将该数据整理并存入Heartbeat仓库中，具体为：用发送者的IP地址作为字典的键，然后新生成一个时间戳与剩余字段拼接在一起，作为对应的值，所述剩余字段包括CPU内核数、CPU使用百分比、剩余内存大小。

6.根据权利要求4所述的一种基于一致性哈希的高可用负载均衡系统，其特征在于，所述Heartbeat仓库是一个具有字典存储功能的类对象，并且具有对对象内部数据进行审查的功能，用于存储所有存活的应用服务节点以及相关信息。

7.根据权利要求6所述的一种基于一致性哈希的高可用负载均衡系统，其特征在于，所述信息注册模块只有一个Heartbeat仓库，会有多个worker线程同时往Heartbeat仓库里写数据更新节点信息；当一个worker线程往Heartbeat更新数据时，先给这条数据上锁，完成数据更新后进行解锁操作，保证同一时刻一条记录只有一个写操作。

8.根据权利要求6所述的一种基于一致性哈希的高可用负载均衡系统，其特征在于，当check_alive线程要求获取最新的存活主机列表时，Heartbeat仓库检测不存活的主机，首先记录系统当前的时间戳，减去设定的超时间隔timeout，将值设为limit；然后对Heartbeat仓库字典中的每一条节点的时间戳和设定的limit值进行比对，大于等于limit的跳过；小于limit的，标记为节点死亡，将其从整个Heartbeat仓库字典中移除出去，之后将整个Heartbeat字典返回给check_alive线程。

9.根据权利要求1所述的一种基于一致性哈希的高可用负载均衡系统，其特征在于，所述客户端插件执行以下操作：

①.客户端插件启动时，向信息注册模块获取应用服务列表，并据此构建一致性哈希环，用于为客户端选择处理请求的应用服务器节点，同时将超时计数器变量count初始化为0；

②.客户端生成节点迭代器，用于从步骤①生成的一致性哈希环中根据权重返回最优应用服务节点；

③.调用步骤②的节点迭代器，获取一个最优应用服务节点；

④.向选定的应用服务节点发送请求并设定计时器；

⑤.如果超时仍没有收到响应，则count加1，同时检测超时count次数是否已经超过设定超时次数，如果没有，则转到步骤②节点迭代器，从环中取下一个节点再次进行请求，如果超时次数超过或刚好等于设定超时次数，需要更新本地应用服务存活列表，转到步骤①，向信息注册模块获取应用服务列表，重新生成一致性哈希环；

⑥.如果本次请求正常返回，则正常结束，如果有新的请求，则从步骤②正常开始。