一种大规模Redis集群云运维技术

屠雪真

摘要：Redis是互联网时代广泛使用的NoSQL数据库。随着数据规模的快速增长，传统的运维管理方式已不能满足应用软件对Redis集群的大规模、灵活和高效的部署与运维需求。近年来云计算技术的成熟和Kubernetes的快速发展，基于容器的微服务架构已成为应用软件的首选架构。该文从Redis集群的现状和需求出发，结合Docker容器管理和微服务关键技术，提出一种基于云计算和微服务的大规模Redis集群云运维方案，实现了Redis集群的云化管理、按需服务和高效运维。通过实验，证明了该方案在快速部署和便捷运维方面具有较大的优势。

关键词：Redis；NoSQL；云计算；Kubernetes；Docker；微服务

中图分类号：TP391 文献标识码：A

文章编号：1009-3044（2019）08-0001-03

开放科学（资源服务）标识码（OSID）：

A Large-Scale Redis Cluster Cloud Operation and Maintenance Technology

TU Xue-zhen

（School of Computer and Information Engineering， Henan University， Kaifeng 475001， China）

Abstract： Redis is a NoSQL database widely used in the Internet age. With the rapid growth of data scale， traditional operation and maintenance management methods can no longer meet the large-scale， flexible and efficient maintenance and operation requirements of application software for Redis clusters. With the maturity of cloud computing technology and the rapid development of Kubernetes in recent years， container-based microservice architecture has become the preferred architecture for application software. Based on the current situation and requirements of Redis cluster， combined with Docker container management and micro-service key technologies， this paper proposes a large-scale Redis cluster cloud operation and maintenance scheme， which realizes the efficient operation and maintenance of Redis clusters. Experiments show that the scheme has great advantages in rapid deployment and convenient operation and maintenance.

Key words： redis； NoSQL； cloud computing； Kubernetes； microservice

1引言

隨着信息技术的飞速发展，许多新型应用面临着高并发、低时延、弹性扩展和高可用等挑战。基于key-value的NoSQL数据库系统凭借高性能、高可扩展性的优势和简单灵活的数据模型脱颖而出[1]，并在大规模数据处理和存储领域得到了广泛应用。

在诸多的K-V系统中，Redis是应用最广泛且具有代表性的方案[2]。它支持多种数据类型的存储和丰富的操作，提供 RDB 和 AOF两种持久化方式，但这只是其保证数据恢复的措施。Redis适用于多种应用场景，在互联网和分布式计算领域有很多成功的应用范例。

为了保证效率，Redis的数据存取都是在内存中。由于内存容量的限制，仅使用单台服务器提供Redis服务在很多应用中是不够的。Redis在3.0版本后提供了官方的集群化方案，但是其集群化方案在很多场景下还没有得到充分的验证，很多使用者根据自己的生产环境定制解决方案[3]。

随着数据量的不断增大，Redis集群的规模也会变大。例如，某局点用户规模10万，数据量50GB，每秒请求数为600，每次用户请求操作Redis20次，则Redis的负载为1.2WTPS。使用Redis单实例即可满足需求，考虑到高可用，可以使用Redis哨兵方案。现在该局点的用户规模增长到1000万，数据量在2TB左右，需要80台资源为8C/128G的虚拟机，每台虚拟机上运行3个Redis实例，则一共需要120个Redis主节点和120个Redis从节点。

对于这种大规模Redis集群，传统的运维方法遇到了很大的困难和挑战。首先是耗时长。传统运维自动化安装部署方案流程一般为修改配置、上传版本、启动程序、校验服务四个步骤。首选运维工程师需要先在PC客户端把配置文件修改好，对于Redis集群来讲主要需要修改redis.conf中的IP和端口，手动修改或者界面修改；然后执行程序和各个安装部署服务器（一般为FTP服务）建立链接并鉴权，上传版本；再然后执行程序远程执行启动程序服务；最后登录某一个节点或者全部节点，用模拟客户端访问校验服务是否正常。整个流程自动化程度低、耗时比较大。其次是运维难。业界Redis系统监控告警一般基于各个集群节点的日志信息上报，监控中心需要维护各个节点信息，一旦需要扩缩容，节点信息发生变更，需要更新监控中心的服务节点列表，很难做到自动化和业务无感知。运维人员除了需要熟悉Redis业务相关运维知识，还需要熟悉组网架构和底层网络排查，对运维人员的技能要求高。

2 基于微服务的Redis云运维方案

随着云计算技术的成熟，基础设施自动化、按需虚拟化和大型集群系统的理念逐步成为主流，应用软件开发也从单体架构转到微服务化架构[4]。将微服务装入容器进行独立的部署和扩展，使其具有高可移植性，成为一种必然的趋势[5]。Kubernetes是主流的分布式容器集群编排管理引擎，用于管理云平台中多个主机上的容器化应用，为容器集群提供调度服务、服务注册、服务发现、资源调度、均衡容灾、动态扩缩容等支持[6]。

本文设计了一种基于云计算技术和微服务架构的Redis集群云运维方案，实现了多种Redis类型（Redis Standalone、Redis Sentinel、Redis Cluster）的快速自动部署和平滑升级，解决Redis实例碎片化现象、提供完善统计、监控、运维功能、减少运维成本和误操作，提高机器的利用率，提供灵活的伸缩性。

在IaaS层采用Openstack和K8S對虚拟机和容器做资源池化，这一层主要是对基础设施进行管理以给用户提供资源使用，如提供计算服务、安全备份、负载管理等。IaaS上面是PaaS层，这一层主要是简化应用的部署、运行等，提供一些通用中间件能力，如消息服务、数据库服务等[7]。

Redis以公共服务中间件的形式集成到PaaS层[8]。Redis云运维流程如图1所示。其中，CSM（Common Service Management）是公共服务管理模块，主要负责公共服务镜像管理、公共服务资源（硬盘、CPU、内存、网络）等的管理。MSB是微服务总线模块，主要负责服务注册、服务发现、服务健康检查、服务路由等功能。

Redis公共服务中包括Redis微服务和Redis Service Broker微服务。Redis Service Broker的作用是检测Redis服务是否正常，和Redis协议紧密结合。Redis Service Broker的高可用由K8S保证，一旦容器挂掉则由K8S负责重启。

安装服务流程。用户发起安装服务请求给CSM，CSM识别出服务类型为Redis，则通过K8S从后台镜像仓库取出Redis 的Service Broker镜像，运行该镜像，将运行结果返回给用户。

创建服务流程。用户发送“创建服务请求”给CSM，CSM通过K8S从镜像仓库中取出并运行Redis的镜像。镜像运行时会自启动镜像中的redis-server程序和redis-agent程序，redis-agent启动后会发送MSB注册消息，注册消息中携带redis-server的IP、PORT、密码等信息。MSB收到注册消息后，会一方面给Redis-server的IP和PORT分配一个PaaS平台的唯一服务名，另一方面给Redis Service Broker发送查询服务状态消息，消息中携带redis-server的IP、PORT、密码等信息。Redis Service Broker收到查询消息后，会根据IP、PORT、密码访问redis-server，执行简单的Set、Get、Del操作来验证redis-server是否工作正常，然后返回MSB检测结果。MSB根据检测结果返回用户创建服务结果，如果检测成功，则返回用户“创建服务成功”，如果检测失败，则返回用户“创建服务失败”。用户在创建过程中，每个Redis服务在MSB对应不同且唯一的域名，通过这种方式，可以做到租户隔离。

服务提供。应用程序通过API把服务名转换为IP，然后根据IP找到对应的Redis节点，访问该节点提供Redis服务。

2.1 Redis云运维的部署和升级

传统运维方法采用Redis集群节点串行升级方式。而云运维方案通过前述的Redis集群云运维流程和docker容器的快速启动，实现了Redis集群快速自动化安装部署。

以主备N+N集群模式为例。首先启动N个Redis微服务容器，PaaS云平台将这N个容器均匀分布在虚拟化资源上，PaaS自身提供资源的负载均衡启动功能。这些容器内部集成Redis-server、Redis-agent程序。

然后启动控制中心容器，启动控制中心容器时，通过环境变量获取到启动好的N个容器的IP地址，结合默认Redis端口将N个Redis程序添加到Redis集群中，这N个Redis程序成为集群的master。

然后在控制中心容器中调用PaaS接口再次批量启动N个容器，并且调用PaaS接口获取到新启动容器的IP，然后逐个把这些Redis程序作为slave添加到集群中。从而完成集群的快速安装部署。

需要注意的是，控制中心无法感知并且也没有必要感知到容器所在服务器信息，如果slave和master分到同一台虚拟机上，也没关系，一旦整台虚拟机出现异常，该虚拟机上所有的docker容器会启动在另一台虚拟机上，这个机制保证在由于硬件问题或者系统问题导致的某个复制组整体异常时继续提供正常服务。

云运维方案也能解决Redis集群平滑升级耗时长的问题[8]。平滑升级时，由控制中心向所有的复制组的slave发送shutdown指令，所有的复制组升级的步骤是同步并行执行的，使得升级的时间可以在一个可控范围之内，不会和集群的节点数目呈线性关系。

2.2 Redis云运维的日常维护

Redis云运维的日常维护主要有系统监控告警和在线动态修改配置。

Redis云运维从4个维度对Redis服务进行监控运维。

·告警监控主要对平台的当前告警、历史告警和通知进行展示，用户可以对告警进行查询和确认等操作。

·性能监控主要对平台的节点、组件和组件实例的性能数据进行展示，包括CPU、内存、磁盘等。

·事件页面提供PaaS平台组件上报的事件呈現，查询，过滤。

·日志页面提供PaaS平台组件调测日志和用户操作日志的查询，过滤，导出及下载功能。

Redis规模化运维遇到的一个比较常见的问题是修改配置，比如客户需要定期修改Redis的密码以提高Redis数据的安全性，假设我们的Redis集群有上百个集群节点，手动修改显然不合适，我们需要批量修改Redis配置信息。

具体实施方案如下：首先用户在用户界面以key-value形式输入要修改的配置，比如：。浏览器客户端组装成REST接口发送给CSM，由CSM转发给Service Broker，Service Broker逐个调用Redis config指令修改redis.conf配置文件，并执行write写入磁盘。为了防止重启容器后redis.conf中被修改的信息丢失，使用到了Ceph分布式存储技术。

云运维方案把Redis需要保存的数据文件，比如redis.conf存放入Ceph文件系统，如果Redis容器重启，容器里的Redis服务自动从Ceph的redis.conf配置文件加载配置信息。Ceph是一个可靠地、自动重均衡、自动恢复的分布式存储系统，可以提供文件、对象和块存储服务[10]。由于Ceph采用了CRUSH算法、HASH环等良好设计，使得它不存在单点故障问题，随着规模的扩大性能也不会受到影响。

2.3云运维下的Redis实例

虽然Docker提供了应用程序打包，Kubernetes提供了应用部署和调度机制，但它在Pod-to-Pod通信网络上还缺少一个普适的解决方案。Kubernetes默认网络采用的方法是创建具有IP范围的虚拟网桥，然后在每个主机上手动添加主机之间的路由，该方法管理配置比较困难。采用容器网络接口（CNI）和网络插件的方法可以自动生成基本配置，简化了网络的创建和管理。云运维方案在创建CNI插件时，使用了Flannel方案，提供了更好的异构资源兼容性。

如图2所示，云运维环境下的Redis实例运行在docker容器中，采用libnetwork内置驱动的bridge网络模式，libnetwork将创建出来的Docker容器连接到Docker网桥上。

为了容器之间能够数据通信，Docker在各个容器之间创建了一个docker0网桥，类似于交换机[11]，该网桥以eth pair连接各容器的网络，容器中的数据通过docker0网桥转发到eth0网卡，网桥上的veth网卡设备相当于交换机上的端口，可以将多个容器或虚拟机连接在上面，这些端口工作在二层，所以是不需要配置IP信息的。图中docker0网桥就为连在其上的容器转发数据帧，使得同一台宿主机上的Docker容器之间可以相互通信。

3实验结果及分析

实验中使用8台服务器，配置如下： 64 GB 内存，酷睿2 双核CPU，500 GB 硬盘，CentOS Linux release 7.3.1611 操作系统。实验使用Redis版本4.0.10。

测试结果如图3所示。在部署耗时方面，传统运维自动化部署时间随着Redis集群节点数目增多会逐渐增大，而PaaS方案的Redis自动化安装部署时间可以控制部署时间在一个很小的数据范围之内。

为了检验云运维对Redis性能的影响，我们做了虚拟机和云运维环境的性能对比实验。Redis配置为：HA（1主2从），Redis maxmemory为2G，Payload大小64字节/512字节/1K/2K，客户端链接数32/64/96/128/160个链接。测试结果如图3右图所示，Redis性能在云运维环境下和纯虚拟机环境下大致相当，性能损耗在可接受范围内。

4 结束语

在传统IT架构向云计算架构转型的过程中，云计算和基于Docker的微服务架构的技术特点、管理理念和服务理念相互融合，对构建云原生应用带来较高的参考价值。基于分布式模型的Redis在带来高性能、高可扩展性的同时，也加大了部署和运维的难度。Redis集群的规模化运维还没有统一的标准规范。基于对云计算、微服务、Docker和K8S技术的研究，本文提出的Redis集群云运维方案，实现了多种Redis高可用方案的有效管理，简化运维并提升效率，满足了企业低成本地打造大规模Redis服务集群的需求。

但是，受限于虚拟化和docker自身的机制，Redis在容器内的性能还不能和物理裸机相等。随着容器技术的快不断成熟，相信这个问题将得到有效解决。

参考文献：

[1]马文龙，朱妤晴，蒋德钧，等.Key-Value型NoSQL本地存储系统研究[J].计算机学报，2018，41（8）：1722-1751.

[2]姚经纬，杨福军.Redis分布式缓存技术在Hadoop平台上的应用[J].计算机技术与发展，2017，27（6）：146-150.

[3]闫明.高可用可扩展集群化Redis设计与实现[D].西安：西安电子科技大学，2016.

[4]陈春霞.基于容器的微服务架构的浅析[J].信息系统工程，2016（3）：95-96.

[5]YOUSIF M.Microservices[J].IEEE Cloud Computing，2016，3（5）：4-5.

[6]龚正，吴治辉，叶伙荣，等.Kubernets权威指南[M].北京：电子工业出版社，2016.

[7]刘欢欢，麻志毅，陈泓婕 .基于PaaS的云应用软件部署环境的元模型[J].计算机科学，2015，42（10）：45-49.

[8]师德清. 基于Docker 的PaaS 架构设计研究[J].信息与电脑，2017（8）：35-36.

[9]田玉靖，张晨光，任女尔.基于Docker的Redis缓存架构的研究[J].电脑知识与技术，2015，11（23）：56-58.

[10]杨飞，朱志祥，梁小江.基于Ceph对象存储集群的高可用设计与实现.微电子学与计算机，2016，33（01）：60-64.

[11]郭栋，王伟，曾国荪.一种基于微服务架构的新型云件PaaS平台[J]. 信息网络安全，2015（11）：15-20.

【通联编辑：唐一东】