CN108833503B - 一种基于ZooKeeper的Redis集群方法 - Google Patents

Abstract

本发明公开了一种基于ZooKeeper的Redis集群方法。该方法以Zookeeper作为一致性中间件来维护的分布式Redis集群的数据分片信息，客户端通过ZooKeeper获得Redis集群的数据分片信息并建立路由算法，从而使Redis客户端与服务端之间不需要通过代理层即可直接通信，并实现Redis集群的动态扩缩容和数据自动迁移的能力。同时，该方法结合Redis‑Sentinel和ZooKeeper实现了集群故障的自动转移能力，保证了Redis集群的高可用性。本发明减少Redis集群代理层所带来的额外网络开销，提高Redis集群的性能，同时保证Redis集群的扩展能力，数据自动迁移能力和可用性。

Description

一种基于ZooKeeper的Redis集群方法

技术领域

本发明属于分布式Key-Value系统领域内的一种集群方法，尤其涉及一种基于ZooKeeper的Redis集群方法及其实现。

背景技术

作为NoSQL(Not Only Sql)数据库中一个子集的Key-Value存储系统，如Redis等，采用简单的Key-Value数据模型，并基于内存提供了类似于传统Hash表的快速查询操作。它们通常作为提升数据中心或者应用的数据访问速度的重要手段，已经成为了很多数据中心中关键基础设施的重要组成部分。在工业界，很多大公司，如Facebook、Amazon等，都部署着大规模的分布式Key-Value系统集群充当关键系统的数据层。可见这些Key-Value存储系统的性能将直接影响到很多大规模服务的QoS(服务质量)，提升分布式Key-Value系统的性能具有很大的意义和价值。

Redis是一个基于内存的Key-Value数据库，它把所有的数据都存在了内存中，提供了很快的访问速度，同时提供了丰富的特性，如Key-Value对的过期和淘汰策略、复制功能和Redis Sentinel可用性方案等，所以得到了很多用户的青睐，已经成为目前最著名的开源Key-Value系统之一。然而，虽然Redis在分布式集群方案方面已经有了Codis和Twemproxy这些目前主流的集群方案，但这些方案采用代理方式来对客户端的请求进行转发造成集群性能的损失，仍存在着不足，所以本发明提供了一种基于ZooKeeper的Redis集群方法，实现了一个支持在线动态扩缩容，并且可以自动进行数据迁移的更高性能且高可用的分布式Redis集群。

ZooKeeper是Apache开源的一个分布式服务，可以为分布式程序提供协调服务。ZooKeeper本身就是一个可靠的、可扩展的分布式软件，可以为分布式应用提供一致性服务，典型的应用场景是配置管理、域名服务、集群管理和分布式锁等。ZooKeeper提供了比较简单的数据模型，它维护了一个类似于文件系统数据结构。每个节点被称作一个znode，所有的znode都可以由一条路径唯一表示。但与文件系统不同的是，ZooKeeper中每一个znode都可以存储数据，所有对znode数据的读写操作也都是原子性的。用户可以监控znode，当znode数据发生变化，或者子节点发生变化等，设置监控的客户端可以收到通知，这也是Zookeeper的核心功能，很多应用功能的开发都基于这个特性。

发明内容

本发明的目的在于针对目前Redis在集群方案和网络处理方面的不足，提出并实现了一种基于ZooKeeper的支持动态扩缩容、数据自动迁移并且更高性能的高可用Redis集群方法。

为了实现本发明，采用的主要技术方案如下。

采用ZooKeeper这第三方中间件来提供可靠的一致性服务，来统一维护Redis集群的数据分片信息，数据分片信息主要包括节点的IP地址、端口、迁移时间和slot分配等信息。对客户端进行优化封装，让客户端从ZooKeeper获得Redis集群的数据分片信息，建立数据路由算法，同时继续监控ZooKeeper集群znode节点中数据的变化，当Redis集群拓扑发生变化的时候能及时知道并根据变化的情况做出路由调整。当发生Redis集群的扩缩容的时候，服务端动态地根据Redis节点的权重重新计算每个Redis节点负责的slot数量，对slot进行迁移调整，并更新ZooKeeper中节点的信息，客户端通过监控znode节点中数据的变化获得通知，更新slot与Redis节点的路由关系，并根据znode节点配置的迁移时间确定是否需要进行数据迁移，如果需要进行数据迁移则维护一个临时的slot与Redis节点的映射表，表示slot与迁移前原属Redis节点的映射关系，方便在需要的时候数据可以从旧的节点迁移到新的节点，从而实现Redis集群的动态扩缩容和数据自动迁移能力。方法还为Redis集群中每个Redis主节点配备了若干个备节点，备节点负责与主节点进行数据同步复制，同时采用Redis Sentinel来对所有的Redis主节点和备节点进行监控，当有某个Redis主节点发生故障无法正常提供服务的时候，Redis Sentinel自动从发生故障的主节点下的所有备节点中选择一个备节点提升为新的主节点代替原来的主节点提供服务，并更新ZooKeeper中相应znode节点中的主节点IP地址和端口，客户端获得通知后会更新相应节点的客户端实例，从而实现Redis集群的故障自动转移，保证Redis集群的可用性。

与现有技术相比，本发明具有如下优点和技术效果：本发明减少Redis集群代理层所带来的额外网络开销，现有主流的Redis集群方案，如Codis和Twemproxy都采用代理来对客户端的请求进行转发，导致客户端的请求在网络传送上都需要经过代理层，多了一跳，造成性能的损失，而本发明去掉了代理层，让客户端可以直接与服务端通信，减少了网络开销，提高Redis集群的性能，同时本发明在实现上也保证了Redis集群的扩展能力，数据自动迁移能力和可用性。

附图说明

图1为实例中一种基于ZooKeeper的Redis集群方法整体框架图。

图2为ZooKeeper中的数据分片信息示意图。

图3为添加新节点前后数据分片信息的变化对比图。

图4为数据路由主要结构图。

图5为数据迁移过程中数据路由结构变化图。

图6为数据迁移处理流程图。

图7为数据迁移线程处理流程图。

图8不同负载下的系统吞吐量

图9系统延迟

具体实施方式

下面结合附图，对本发明的具体实施作进一步说明，但本发明的实施和保护不限于此，需指出的是，以下若有未特别详细说明之处，均是本领域技术人员可根据现有技术理解或实现的。

本实例一种基于ZooKeeper的Redis集群方法如图1所示，下面分点进行详细地说明。

1、数据分片信息维护

本实例选择将数据分片信息交给第三方中间件ZooKeeper维护，并利用ZooKeeper提供的一致性保证所有客户端可以看到一致的信息，同时利用znode可以被监控的方式，让客户端在集群拓扑等信息有变更的时候，可以及时地得到通知并做出更新，实现集群的动态变更。图2说明了数据分片信息在ZooKeeper中的组织方式。名为节点名称的znode节点代表的是一个Redis集群的信息，该znode节点下节点1至节点N代表的是Redis集群中的每一个节点，Redis集群的每一个节点都在名为节点名称的znode节点下有唯一对应的节点，每个节点存储着节点的详细信息，包括节点的IP地址、端口、节点权重和slot分配等信息。

2、动态增删节点

当需要增删节点的时候，本发明会依据各个节点的权重从现有的节点中将一部分slots重新分配给新加入的节点或者把原来分配给被删除节点的slots回收回来重新分配给剩下的节点，并更新ZooKeeper中整个集群各个节点的数据分片信息，并通知所有客户端，让所有客户端获取最新的数据分片信息并做出相应的调整从而实现节点的动态添加与删除。如图3所示，假设Redis集群原来有两个节点，每个节点的权重都是10，1号节点负责slot 1、2、3，2号节点负责slot 3、4、5，当向集群中新增加一个权重也为10的新节点3后，原来属于节点1的slot 2和原来属于节点2的slot 5被迁移到了新节点3。

3、数据迁移

当Redis集群有节点的增加或删除操作发生时，集群slots会有迁移操作，管理员需要根据业务需要指定znode节点中的迁移时间来说明数据是否也要由旧节点迁移到新的节点。如果迁移时间指定为0时，则表示不需要进行数据迁移操作，如果迁移时间指定为大于0的值，那么客户端会进入数据迁移状态，当用户访问到处于迁移状态中的数据时，客户端会先到新节点查询数据，如果数据不存在则会到旧的节点中查询数据，如果数据存在旧节点中，则会将数据迁移到新节点，并在新节点执行用户的数据操作。迁移状态的持续时间为管理员在znode节点中指定的迁移时间。

4、客户端优化封装

客户端通过ZooKeeper的API获取集群所有znode节点的信息，也就获得了Redis节点的所有信息，包括IP，端口，迁移时间，slot信息等。如图4所示，客户端将slot与Redis节点的映射关系组织成一个简单列表的方式，列表中每一项代表着一个slot，并存储着该slot所属的节点编号，然后利用一个HashMap将节点编号映射到具体的Redis客户端实例。这样两个映射表就构成了客户端的数据路由表。客户端采用murmurhash3算法来计算Key的哈希值，并对集群的slot数量取模从而将Key映射到某个slot，再通过路由表查找对应的Redis客户端实例。

在客户端中，当需要进行数据迁移操作的时候，客户端会维护两个slot与Redis节点的映射表，如图5所示，主映射表表示的是集群当前的映射关系，而临时映射表表示的是发生迁移操作前的映射关系。当集群处理迁移状态时，数据操作首先根据主映射表进行路由查询，到相应Redis节点进行操作，如果无法找到相应数据则通过临时映射表查看数据所在slot是否处于迁移状态，是的话通过临时映射表到迁移前的节点查找数据，并进行数据迁移，否则说明数据不存在。

图6以Get或Update操作的处理流程为例说明了当集群处于迁移状态时客户端对数据操作的处理流程。假设集群原来只有节点A，后面加入的新的节点B并且slot 2从节点A迁移到了节点B，当客户端处理映射到slot 2的Key时，客户端首先会向节点B发起操作请求，如果节点B返回Key不存在，客户端通过临时映射表发现slot 2处于迁移状态，则到slot2原属的节点A查找Key，如果节点A也不存在相应Key则说明Key不存在，否则客户端将Key及其Value写回到节点B，从而实现数据从节点A迁移到节点B的操作。在将数据写回节点B的时候，为了保证数据的一致性，预防在客户端处理该数据迁移操作的过程中已经有其他客户端完成了该迁移操作并对数据做了更新，客户端采用Redis的SETNX命令进行数据的写入操。SETNX是SET if Not Exists的缩写，也就是Key不存在的时候才会执行SET命令，它原子性地判断数据是否存在，如果不存在则写入数据，如果数据已经存在，则不做任何操作。

客户端中数据迁移状态的维护则交给了一个单独的线程来负责。在客户端中将需要进行数据迁移操作的节点按迁移结束时间组织成一个最小堆，这样最近要结束迁移操作的节点将位于最小堆的根部，迁移线程将根据最小堆根部节点的结束时间来决定等待多长时间，到点的时候迁移线程会唤醒并执行迁移结束的清理工作，如清理迁移状态，关闭已经删除节点的客户端实例等，算法核心流程如下图7所示。

5、性能测试对比

在性能测试中，采用的测试环境如表1所示。

表1.测试环境

本文主要测试对比EmosRedis(代表本发明提出的方案)与现有的几个方案Twemproxy、Codis和Redis Cluster(Redis官方的集群方案)的性能。在本测试中，我们为各个系统都配置三个Redis节点，三个Redis节点都是同一台IBM System x3650M4服务器上，同时在另一台同样的服务器上安装配置YCSB(Yahoo！Cloud Serving Benchmark，雅虎的云服务基准测试工具)并启动40个客户端，每次进行100万次操作来对各个集群进行性能测试。本文采用YCSB定义的多种负载类型，如表2所示，来对系统不同的方面进行测试对比。

表2.负载类型

为了测试各个系统在不同负载下的性能表现，本文采用了数据大小为512字节，数量为500000条的数据集在YCSB定义的不同负载下对各个系统进行了测试。其中，Workloada、Workloadb和Workloadc采用的请求模式是zipfian模式(数据的访问服从齐夫分布)，而Workloadd则采用了latest模式，即访问最新的数据。如图8所示，在Workloada中，EmosRedis的吞吐量达到了19.9万每秒，而Redis Cluster是11.1万每秒，Codis和Twemproxy则分别为9.7万每秒和6.2万每秒，可见EmosRedis的吞吐量有了很大的提高。在Workloadb和Workloadc负载中，GET请求的比例不断上升，从图中可以发现随着GET请求比例的增加，EmosRedis的吞吐量慢慢地下降了，但是Twemproxy和Codis的吞吐量基本没有太多变化，这里的原因是由于随着GET请求比例的增加，服务器的网络带宽渐渐地成为了EmosRedis系统的瓶颈导致了其吞吐量的下降，在Workloadc这种纯GET的负载，EmosRedis的吞吐下降到了17.4万每秒。在Workloadd中，本文采用了95％GET请求和5％INSERT请求，在该负载下EmosRedis的吞吐量达到了17.8万每秒，相比Twemproxy、Codis和RedisCluster分别提高了190％、85％和43％左右的提升。可见，在各种负载模式下，EmosRedis的吞吐量相比其他系统的吞吐量都有了比较大的提升。

为了说明EmosRedis在取得更高吞吐量的同时也获得了相对比较低的延迟，本文对各个系统进行了系统延迟的对比测试。测试中采用了数据大小为512字节，数量为500000条的数据集在uniform模式(所有数据被访问的概率都相同)用Workloada对各个系统分别进行了测试，并控制吞吐量，观察吞吐量与延迟的关系。图9描述了平均延迟与吞吐量的关系，误差线的上下部分别表示95th-Percentile latency和5th-Percentile latency。从图中可以看到，随着吞吐量从1.2万每秒增加6万每秒，Twemproxy的平均延迟由299微秒增加到567微秒，当Codis的吞吐量从1.9万每秒逐渐增加到9.6万每秒的时候，平均延迟则由261微秒增加到了392微秒，Redis Cluster则随着吞吐从1.9万每秒增加到9.5万每秒，平均延迟由161微秒增加到236微秒，而EmosRedis在吞吐量从3.9万每秒增加到19.5万每秒的时候，平均延迟则只是由131微秒增加了180μ。可见，EmosRedis的延迟随着吞吐量的增加变化并不是很大，并且都远比Twemproxy和Codis这两种基于代理的主流方案的延迟低，就算EmosRedis增加到19.5万每秒的吞吐量，其延迟也比Twemproxy和Codis在比较低的吞吐量时的延迟还要低。而Redis Cluster的平均延迟也比较低，EmosRedis相比Redis Cluster只有比较小的改善，但当吞吐量比较高的时候EmosRedis的延迟还是比Redis Cluster的低不少。所以相比于Twemproxy、Codis和Redis Cluster这三个现有的分布式Redis集群方案，EmosRedis可以在获得更高的吞吐量的同时获得更低的延迟。

Claims (4)

1.一种基于ZooKeeper的Redis集群方法，其特征在于用第三方中间件ZooKeeper来提供一致性服务，统一维护Redis集群的数据分片信息，客户端通过ZooKeeper获得Redis集群的数据分片信息并建立路由算法，实现Redis集群的动态扩缩容和数据自动迁移的能力，并结合Redis-Sentinel，为每个Redis主节点配备若干个备节点，利用Redis备节点可以对Redis主节点进行数据同步复制的能力和Redis-Sentinel集群来保障Redis集群的可用性，同时通过ZooKeeper与客户端通信来将后端Redis主节点和备节点的切换信息通知给客户端，实现集群故障的自动转移，保证Redis集群的高可用性；Redis集群的数据分片信息被维护在ZooKeeper集群上，每个Redis节点对应ZooKeeper上一个znode节点，znode节点的存储的数据包括：节点是否有效，节点更新时间，Redis节点IP地址，Redis节点端口，迁移时间，节点权重，slot信息；客户端通过ZooKeeper获得Redis集群的信息并构建路由算法，并采用murmurhash3算法将Key映射到slot；Redis集群的动态扩缩容能力，具体是：当需要增删节点的时候，依据各个节点的权重重新计算每个节点负责的slot数量，并把多余的slot分配给新加入的节点或者把原来分配给被删除节点的slots回收回来重新分配给剩下的节点，并更新ZooKeeper中整个集群各个节点的数据分片信息，通知所有客户端，让所有客户端获取最新的数据分片信息并做出相应的调整。

2.根据权利要求1所述的一种基于ZooKeeper的Redis集群方法，其特征在于数据自动迁移的实现过程为：当集群发生节点增删的时候，会发现slot的迁移导致slot与Redis节点的对应关系发生变化，管理员需要在增删节点时指定相应znode节点中数据迁移时间，如果需要数据迁移，当访问数据的时候客户端会首先到新的节点访问数据，如果数据不存在则到数据原属的节点访问数据，如果数据存在则将数据迁移到新的节点并返回，否则说明数据不存在。

3.根据权利要求1所述的一种基于ZooKeeper的Redis集群方法，其特征在于客户端从ZooKeeper获得Redis集群的数据分片信息后，会建立slot与节点的映射关系和节点与客户端实例的映射关系，实现路由表，并且在数据迁移状态中，会额外维护一个临时的slot与节点的映射表，表示slot与原属节点的映射关系，方便在需要的时候数据能从旧的节点迁移到新的节点。

4. 根据权利要求1所述的一种基于ZooKeeper的Redis集群方法，其特征在于为每个Redis主节点配备了若干个备节点，并利用Redis Sentinel节点对所有的主节点和备节点进行监控，当有主节点发生故障的时候，Redis Sentinel会进行主节点和备节点的切换，并通过ZooKeeper将主节点和备节点的切换信息通知给客户端，从而实现Redis集群的故障自动迁移，保证集群的可用性。

Images