屠雪真

摘要：Redis是互聯(lián)網(wǎng)時代廣泛使用的NoSQL數(shù)據(jù)庫。隨著數(shù)據(jù)規(guī)模的快速增長，傳統(tǒng)的運維管理方式已不能滿足應(yīng)用軟件對Redis集群的大規(guī)模、靈活和高效的部署與運維需求。近年來云計算技術(shù)的成熟和Kubernetes的快速發(fā)展，基于容器的微服務(wù)架構(gòu)已成為應(yīng)用軟件的首選架構(gòu)。該文從Redis集群的現(xiàn)狀和需求出發(fā)，結(jié)合Docker容器管理和微服務(wù)關(guān)鍵技術(shù)，提出一種基于云計算和微服務(wù)的大規(guī)模Redis集群云運維方案，實現(xiàn)了Redis集群的云化管理、按需服務(wù)和高效運維。通過實驗，證明了該方案在快速部署和便捷運維方面具有較大的優(yōu)勢。

關(guān)鍵詞：Redis；NoSQL；云計算；Kubernetes；Docker；微服務(wù)

中圖分類號：TP391 文獻標(biāo)識碼：A

文章編號：1009-3044（2019）08-0001-03

開放科學(xué)（資源服務(wù)）標(biāo)識碼（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引言

隨著信息技術(shù)的飛速發(fā)展，許多新型應(yīng)用面臨著高并發(fā)、低時延、彈性擴展和高可用等挑戰(zhàn)?；趉ey-value的NoSQL數(shù)據(jù)庫系統(tǒng)憑借高性能、高可擴展性的優(yōu)勢和簡單靈活的數(shù)據(jù)模型脫穎而出[1]，并在大規(guī)模數(shù)據(jù)處理和存儲領(lǐng)域得到了廣泛應(yīng)用。

在諸多的K-V系統(tǒng)中，Redis是應(yīng)用最廣泛且具有代表性的方案[2]。它支持多種數(shù)據(jù)類型的存儲和豐富的操作，提供 RDB 和 AOF兩種持久化方式，但這只是其保證數(shù)據(jù)恢復(fù)的措施。Redis適用于多種應(yīng)用場景，在互聯(lián)網(wǎng)和分布式計算領(lǐng)域有很多成功的應(yīng)用范例。

為了保證效率，Redis的數(shù)據(jù)存取都是在內(nèi)存中。由于內(nèi)存容量的限制，僅使用單臺服務(wù)器提供Redis服務(wù)在很多應(yīng)用中是不夠的。Redis在3.0版本后提供了官方的集群化方案，但是其集群化方案在很多場景下還沒有得到充分的驗證，很多使用者根據(jù)自己的生產(chǎn)環(huán)境定制解決方案[3]。

隨著數(shù)據(jù)量的不斷增大，Redis集群的規(guī)模也會變大。例如，某局點用戶規(guī)模10萬，數(shù)據(jù)量50GB，每秒請求數(shù)為600，每次用戶請求操作Redis20次，則Redis的負載為1.2WTPS。使用Redis單實例即可滿足需求，考慮到高可用，可以使用Redis哨兵方案?，F(xiàn)在該局點的用戶規(guī)模增長到1000萬，數(shù)據(jù)量在2TB左右，需要80臺資源為8C/128G的虛擬機，每臺虛擬機上運行3個Redis實例，則一共需要120個Redis主節(jié)點和120個Redis從節(jié)點。

對于這種大規(guī)模Redis集群，傳統(tǒng)的運維方法遇到了很大的困難和挑戰(zhàn)。首先是耗時長。傳統(tǒng)運維自動化安裝部署方案流程一般為修改配置、上傳版本、啟動程序、校驗服務(wù)四個步驟。首選運維工程師需要先在PC客戶端把配置文件修改好，對于Redis集群來講主要需要修改redis.conf中的IP和端口，手動修改或者界面修改；然后執(zhí)行程序和各個安裝部署服務(wù)器（一般為FTP服務(wù)）建立鏈接并鑒權(quán)，上傳版本；再然后執(zhí)行程序遠程執(zhí)行啟動程序服務(wù)；最后登錄某一個節(jié)點或者全部節(jié)點，用模擬客戶端訪問校驗服務(wù)是否正常。整個流程自動化程度低、耗時比較大。其次是運維難。業(yè)界Redis系統(tǒng)監(jiān)控告警一般基于各個集群節(jié)點的日志信息上報，監(jiān)控中心需要維護各個節(jié)點信息，一旦需要擴縮容，節(jié)點信息發(fā)生變更，需要更新監(jiān)控中心的服務(wù)節(jié)點列表，很難做到自動化和業(yè)務(wù)無感知。運維人員除了需要熟悉Redis業(yè)務(wù)相關(guān)運維知識，還需要熟悉組網(wǎng)架構(gòu)和底層網(wǎng)絡(luò)排查，對運維人員的技能要求高。

2 基于微服務(wù)的Redis云運維方案

隨著云計算技術(shù)的成熟，基礎(chǔ)設(shè)施自動化、按需虛擬化和大型集群系統(tǒng)的理念逐步成為主流，應(yīng)用軟件開發(fā)也從單體架構(gòu)轉(zhuǎn)到微服務(wù)化架構(gòu)[4]。將微服務(wù)裝入容器進行獨立的部署和擴展，使其具有高可移植性，成為一種必然的趨勢[5]。Kubernetes是主流的分布式容器集群編排管理引擎，用于管理云平臺中多個主機上的容器化應(yīng)用，為容器集群提供調(diào)度服務(wù)、服務(wù)注冊、服務(wù)發(fā)現(xiàn)、資源調(diào)度、均衡容災(zāi)、動態(tài)擴縮容等支持[6]。

本文設(shè)計了一種基于云計算技術(shù)和微服務(wù)架構(gòu)的Redis集群云運維方案，實現(xiàn)了多種Redis類型（Redis Standalone、Redis Sentinel、Redis Cluster）的快速自動部署和平滑升級，解決Redis實例碎片化現(xiàn)象、提供完善統(tǒng)計、監(jiān)控、運維功能、減少運維成本和誤操作，提高機器的利用率，提供靈活的伸縮性。

在IaaS層采用Openstack和K8S對虛擬機和容器做資源池化，這一層主要是對基礎(chǔ)設(shè)施進行管理以給用戶提供資源使用，如提供計算服務(wù)、安全備份、負載管理等。IaaS上面是PaaS層，這一層主要是簡化應(yīng)用的部署、運行等，提供一些通用中間件能力，如消息服務(wù)、數(shù)據(jù)庫服務(wù)等[7]。

Redis以公共服務(wù)中間件的形式集成到PaaS層[8]。Redis云運維流程如圖1所示。其中，CSM（Common Service Management）是公共服務(wù)管理模塊，主要負責(zé)公共服務(wù)鏡像管理、公共服務(wù)資源（硬盤、CPU、內(nèi)存、網(wǎng)絡(luò)）等的管理。MSB是微服務(wù)總線模塊，主要負責(zé)服務(wù)注冊、服務(wù)發(fā)現(xiàn)、服務(wù)健康檢查、服務(wù)路由等功能。

Redis公共服務(wù)中包括Redis微服務(wù)和Redis Service Broker微服務(wù)。Redis Service Broker的作用是檢測Redis服務(wù)是否正常，和Redis協(xié)議緊密結(jié)合。Redis Service Broker的高可用由K8S保證，一旦容器掛掉則由K8S負責(zé)重啟。

安裝服務(wù)流程。用戶發(fā)起安裝服務(wù)請求給CSM，CSM識別出服務(wù)類型為Redis，則通過K8S從后臺鏡像倉庫取出Redis 的Service Broker鏡像，運行該鏡像，將運行結(jié)果返回給用戶。

創(chuàng)建服務(wù)流程。用戶發(fā)送“創(chuàng)建服務(wù)請求”給CSM，CSM通過K8S從鏡像倉庫中取出并運行Redis的鏡像。鏡像運行時會自啟動鏡像中的redis-server程序和redis-agent程序，redis-agent啟動后會發(fā)送MSB注冊消息，注冊消息中攜帶redis-server的IP、PORT、密碼等信息。MSB收到注冊消息后，會一方面給Redis-server的IP和PORT分配一個PaaS平臺的唯一服務(wù)名，另一方面給Redis Service Broker發(fā)送查詢服務(wù)狀態(tài)消息，消息中攜帶redis-server的IP、PORT、密碼等信息。Redis Service Broker收到查詢消息后，會根據(jù)IP、PORT、密碼訪問redis-server，執(zhí)行簡單的Set、Get、Del操作來驗證redis-server是否工作正常，然后返回MSB檢測結(jié)果。MSB根據(jù)檢測結(jié)果返回用戶創(chuàng)建服務(wù)結(jié)果，如果檢測成功，則返回用戶“創(chuàng)建服務(wù)成功”，如果檢測失敗，則返回用戶“創(chuàng)建服務(wù)失敗”。用戶在創(chuàng)建過程中，每個Redis服務(wù)在MSB對應(yīng)不同且唯一的域名，通過這種方式，可以做到租戶隔離。

服務(wù)提供。應(yīng)用程序通過API把服務(wù)名轉(zhuǎn)換為IP，然后根據(jù)IP找到對應(yīng)的Redis節(jié)點，訪問該節(jié)點提供Redis服務(wù)。

2.1 Redis云運維的部署和升級

傳統(tǒng)運維方法采用Redis集群節(jié)點串行升級方式。而云運維方案通過前述的Redis集群云運維流程和docker容器的快速啟動，實現(xiàn)了Redis集群快速自動化安裝部署。

以主備N+N集群模式為例。首先啟動N個Redis微服務(wù)容器，PaaS云平臺將這N個容器均勻分布在虛擬化資源上，PaaS自身提供資源的負載均衡啟動功能。這些容器內(nèi)部集成Redis-server、Redis-agent程序。

然后啟動控制中心容器，啟動控制中心容器時，通過環(huán)境變量獲取到啟動好的N個容器的IP地址，結(jié)合默認Redis端口將N個Redis程序添加到Redis集群中，這N個Redis程序成為集群的master。

然后在控制中心容器中調(diào)用PaaS接口再次批量啟動N個容器，并且調(diào)用PaaS接口獲取到新啟動容器的IP，然后逐個把這些Redis程序作為slave添加到集群中。從而完成集群的快速安裝部署。

需要注意的是，控制中心無法感知并且也沒有必要感知到容器所在服務(wù)器信息，如果slave和master分到同一臺虛擬機上，也沒關(guān)系，一旦整臺虛擬機出現(xiàn)異常，該虛擬機上所有的docker容器會啟動在另一臺虛擬機上，這個機制保證在由于硬件問題或者系統(tǒng)問題導(dǎo)致的某個復(fù)制組整體異常時繼續(xù)提供正常服務(wù)。

云運維方案也能解決Redis集群平滑升級耗時長的問題[8]。平滑升級時，由控制中心向所有的復(fù)制組的slave發(fā)送shutdown指令，所有的復(fù)制組升級的步驟是同步并行執(zhí)行的，使得升級的時間可以在一個可控范圍之內(nèi)，不會和集群的節(jié)點數(shù)目呈線性關(guān)系。

2.2 Redis云運維的日常維護

Redis云運維的日常維護主要有系統(tǒng)監(jiān)控告警和在線動態(tài)修改配置。

Redis云運維從4個維度對Redis服務(wù)進行監(jiān)控運維。

·告警監(jiān)控主要對平臺的當(dāng)前告警、歷史告警和通知進行展示，用戶可以對告警進行查詢和確認等操作。

·性能監(jiān)控主要對平臺的節(jié)點、組件和組件實例的性能數(shù)據(jù)進行展示，包括CPU、內(nèi)存、磁盤等。

·事件頁面提供PaaS平臺組件上報的事件呈現(xiàn)，查詢，過濾。

·日志頁面提供PaaS平臺組件調(diào)測日志和用戶操作日志的查詢，過濾，導(dǎo)出及下載功能。

Redis規(guī)?；\維遇到的一個比較常見的問題是修改配置，比如客戶需要定期修改Redis的密碼以提高Redis數(shù)據(jù)的安全性，假設(shè)我們的Redis集群有上百個集群節(jié)點，手動修改顯然不合適，我們需要批量修改Redis配置信息。

具體實施方案如下：首先用戶在用戶界面以key-value形式輸入要修改的配置，比如：。瀏覽器客戶端組裝成REST接口發(fā)送給CSM，由CSM轉(zhuǎn)發(fā)給Service Broker，Service Broker逐個調(diào)用Redis config指令修改redis.conf配置文件，并執(zhí)行write寫入磁盤。為了防止重啟容器后redis.conf中被修改的信息丟失，使用到了Ceph分布式存儲技術(shù)。

云運維方案把Redis需要保存的數(shù)據(jù)文件，比如redis.conf存放入Ceph文件系統(tǒng)，如果Redis容器重啟，容器里的Redis服務(wù)自動從Ceph的redis.conf配置文件加載配置信息。Ceph是一個可靠地、自動重均衡、自動恢復(fù)的分布式存儲系統(tǒng)，可以提供文件、對象和塊存儲服務(wù)[10]。由于Ceph采用了CRUSH算法、HASH環(huán)等良好設(shè)計，使得它不存在單點故障問題，隨著規(guī)模的擴大性能也不會受到影響。

2.3云運維下的Redis實例

雖然Docker提供了應(yīng)用程序打包，Kubernetes提供了應(yīng)用部署和調(diào)度機制，但它在Pod-to-Pod通信網(wǎng)絡(luò)上還缺少一個普適的解決方案。Kubernetes默認網(wǎng)絡(luò)采用的方法是創(chuàng)建具有IP范圍的虛擬網(wǎng)橋，然后在每個主機上手動添加主機之間的路由，該方法管理配置比較困難。采用容器網(wǎng)絡(luò)接口（CNI）和網(wǎng)絡(luò)插件的方法可以自動生成基本配置，簡化了網(wǎng)絡(luò)的創(chuàng)建和管理。云運維方案在創(chuàng)建CNI插件時，使用了Flannel方案，提供了更好的異構(gòu)資源兼容性。

如圖2所示，云運維環(huán)境下的Redis實例運行在docker容器中，采用libnetwork內(nèi)置驅(qū)動的bridge網(wǎng)絡(luò)模式，libnetwork將創(chuàng)建出來的Docker容器連接到Docker網(wǎng)橋上。

為了容器之間能夠數(shù)據(jù)通信，Docker在各個容器之間創(chuàng)建了一個docker0網(wǎng)橋，類似于交換機[11]，該網(wǎng)橋以eth pair連接各容器的網(wǎng)絡(luò)，容器中的數(shù)據(jù)通過docker0網(wǎng)橋轉(zhuǎn)發(fā)到eth0網(wǎng)卡，網(wǎng)橋上的veth網(wǎng)卡設(shè)備相當(dāng)于交換機上的端口，可以將多個容器或虛擬機連接在上面，這些端口工作在二層，所以是不需要配置IP信息的。圖中docker0網(wǎng)橋就為連在其上的容器轉(zhuǎn)發(fā)數(shù)據(jù)幀，使得同一臺宿主機上的Docker容器之間可以相互通信。

3實驗結(jié)果及分析

實驗中使用8臺服務(wù)器，配置如下： 64 GB 內(nèi)存，酷睿2 雙核CPU，500 GB 硬盤，CentOS Linux release 7.3.1611 操作系統(tǒng)。實驗使用Redis版本4.0.10。

測試結(jié)果如圖3所示。在部署耗時方面，傳統(tǒng)運維自動化部署時間隨著Redis集群節(jié)點數(shù)目增多會逐漸增大，而PaaS方案的Redis自動化安裝部署時間可以控制部署時間在一個很小的數(shù)據(jù)范圍之內(nèi)。

為了檢驗云運維對Redis性能的影響，我們做了虛擬機和云運維環(huán)境的性能對比實驗。Redis配置為：HA（1主2從），Redis maxmemory為2G，Payload大小64字節(jié)/512字節(jié)/1K/2K，客戶端鏈接數(shù)32/64/96/128/160個鏈接。測試結(jié)果如圖3右圖所示，Redis性能在云運維環(huán)境下和純虛擬機環(huán)境下大致相當(dāng)，性能損耗在可接受范圍內(nèi)。

4 結(jié)束語

在傳統(tǒng)IT架構(gòu)向云計算架構(gòu)轉(zhuǎn)型的過程中，云計算和基于Docker的微服務(wù)架構(gòu)的技術(shù)特點、管理理念和服務(wù)理念相互融合，對構(gòu)建云原生應(yīng)用帶來較高的參考價值?；诜植际侥Ｐ偷腞edis在帶來高性能、高可擴展性的同時，也加大了部署和運維的難度。Redis集群的規(guī)模化運維還沒有統(tǒng)一的標(biāo)準(zhǔn)規(guī)范?；趯υ朴嬎恪⑽⒎?wù)、Docker和K8S技術(shù)的研究，本文提出的Redis集群云運維方案，實現(xiàn)了多種Redis高可用方案的有效管理，簡化運維并提升效率，滿足了企業(yè)低成本地打造大規(guī)模Redis服務(wù)集群的需求。

但是，受限于虛擬化和docker自身的機制，Redis在容器內(nèi)的性能還不能和物理裸機相等。隨著容器技術(shù)的快不斷成熟，相信這個問題將得到有效解決。

參考文獻：

[1]馬文龍，朱妤晴，蔣德鈞，等.Key-Value型NoSQL本地存儲系統(tǒng)研究[J].計算機學(xué)報，2018，41（8）：1722-1751.

[2]姚經(jīng)緯，楊福軍.Redis分布式緩存技術(shù)在Hadoop平臺上的應(yīng)用[J].計算機技術(shù)與發(fā)展，2017，27（6）：146-150.

[3]閆明.高可用可擴展集群化Redis設(shè)計與實現(xiàn)[D].西安：西安電子科技大學(xué)，2016.

[4]陳春霞.基于容器的微服務(wù)架構(gòu)的淺析[J].信息系統(tǒng)工程，2016（3）：95-96.

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

[6]龔正，吳治輝，葉伙榮，等.Kubernets權(quán)威指南[M].北京：電子工業(yè)出版社，2016.

[7]劉歡歡，麻志毅，陳泓婕 .基于PaaS的云應(yīng)用軟件部署環(huán)境的元模型[J].計算機科學(xué)，2015，42（10）：45-49.

[8]師德清. 基于Docker 的PaaS 架構(gòu)設(shè)計研究[J].信息與電腦，2017（8）：35-36.

[9]田玉靖，張晨光，任女爾.基于Docker的Redis緩存架構(gòu)的研究[J].電腦知識與技術(shù)，2015，11（23）：56-58.

[10]楊飛，朱志祥，梁小江.基于Ceph對象存儲集群的高可用設(shè)計與實現(xiàn).微電子學(xué)與計算機，2016，33（01）：60-64.

[11]郭棟，王偉，曾國蓀.一種基于微服務(wù)架構(gòu)的新型云件PaaS平臺[J]. 信息網(wǎng)絡(luò)安全，2015（11）：15-20.

【通聯(lián)編輯：唐一東】