Redis集群實例分析

這篇“Redis集群實例分析”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“Redis集群實例分析”文章吧。

一、Why K8s

1、資源隔離

當前的Redis Cluster部署在物理機集群上，為了提高資源利用率節約成本，多業務線的Redis集群都是混布的。由于沒有做CPU的資源隔離，經常出現某Redis節點CPU使用率過高導致其他Redis集群的節點爭搶不到CPU資源引起時延抖動。因為不同的集群混布，這類問題很難快速定位，影響運維效率。K8s容器化部署可以指定 CPU request 和 CPU limit ，在提高資源利用率的同時避免了資源爭搶。

2、自動化部署

當前Redis Cluster在物理機上的部署過程十分繁瑣，需要通過查看元信息數據庫查找有空余資源的機器，手動修改很多配置文件再逐個部署節點，最后使用redis_trib工具創建集群，新集群的初始化工作經常需要一兩個小時。

K8s通過StatefulSet部署Redis集群，使用configmap管理配置文件，新集群部署時間只需要幾分鐘，大大提高了運維效率。

二、How K8s

客戶端通過LVS的VIP統一接入，通過Redis Proxy轉發服務請求到Redis Cluster集群。這里我們引入了Redis Proxy來轉發請求。

1、Redis Cluster部署方式

Redis部署為StatefulSet，作為有狀態的服務，選擇StatefulSet最為合理，可以將節點的RDB/AOF持久化到分布式存儲中。當節點重啟漂移到其他機器上時，可通過掛載的PVC(PersistentVolumeClaim)拿到原來的RDB/AOF來同步數據。

我們選擇的持久化存儲PV(PersistentVolume)是Ceph Block Service。Ceph的讀寫性能低于本地磁盤，會帶來100~200ms的讀寫時延。但由于Redis的RDB/AOF的寫出都是異步的，分布式存儲帶來的讀寫延遲對服務并沒有影響。

2、Proxy選型

開源的Redis Proxy有很多，常見的開源Redis Proxy如下:

我們希望能夠繼續使用Redis Cluster來管理Redis集群，所以Codis和Twemproxy不再考慮。redis-cluster-proxy是Redis官方在6.0版本推出的支持Redis Cluster協議的Proxy，但是目前還沒有穩定版，暫時也無法大規模應用。

備選就只有Cerberus和Predixy兩種。我們在K8s環境上對Cerberus和Predixy進行了性能測試，結果如下:

測試環境

測試工具: redis-benchmark

Proxy CPU: 2 core

Client CPU: 2 core

Redis Cluster: 3 master nodes, 1 CPU per node

測試結果

在相同workload和配置下，Predixy的最高QPS要優于Cerberus，時延也比較接近。綜合來看，Predixy比Cerberus的性能要高33%~60%，并且數據的key/value越大，Predixy優勢越明顯，所以最后我們選擇了Predixy。

為了適應業務和K8s環境，在上線前我們對Predixy做了大量的改動，增加了很多新的功能，比如動態切換后端Redis Cluster、黑白名單、異常操作審計等。

3、Proxy部署方式

Proxy作為deployment部署，無狀態輕量化，通過LB對外提供服務，很容易做到動態擴縮容。同時，我們為Proxy開發了動態切換后端Redis Cluster的功能，可實現在線添加和切換Redis Cluster。

4、Proxy自動擴縮容方式

我們使用K8s原生的HPA(Horizontal Pod Autoscaler)來實現Proxy的動態擴縮容。當Proxy所有pod的平均CPU使用率超過一定閾值時，會自動觸發擴容，HPA會將Proxy的replica數加1，之后LVS就會探測到新的Proxy pod并將一部分流量切過去。如果擴容后CPU使用率仍然超過規定的閾值，會繼續觸發擴容邏輯。但是在擴容成功5分鐘內，不論CPU使用率降到多低，都不會觸發縮容邏輯，這樣就避免了頻繁的擴縮容給集群穩定性帶來的影響。

HPA可配置集群的最少(MINPODS)和最多(MAXPODS)pod數量，集群負載再低也不會縮容到MINPODS以下數量的pods。建議客戶可以根據自己的實際業務情況來決定MINPODS和MAXPODS的值。

三、Why Proxy

1、Redis pod重啟可導致IP變化

使用Redis Cluster的Redis客戶端，都需要配置集群的部分IP和Port，用于客戶端重啟時查找Redis Cluster的入口。對于物理機集群部署的Redis節點，即便遇到實例重啟或者機器重啟，IP和Port都可以保持不變，客戶端依然能夠找到Redis Cluster的拓撲。但是部署在K8s上的Redis Cluster，pod重啟是不保證IP不變的(即便是重啟在原來的K8s node上)，這樣客戶端重啟時，就可能會找不到Redis Cluster的入口。

通過在客戶端和Redis Cluster之間加上Proxy，就對客戶端屏蔽了Redis Cluster的信息，Proxy可以動態感知Redis Cluster的拓撲變化，客戶端只需要將LVS的IP:Port作為入口，請求轉發到Proxy上，即可以像使用單機版Redis一樣使用Redis Cluster集群，而不需要Redis智能客戶端。

2、Redis處理連接負載高

在6.0版本之前，Redis都是單線程處理大部分任務的。當Redis節點的連接較高時，Redis需要消耗大量的CPU資源處理這些連接，導致時延升高。有了Proxy之后，大量連接都在Proxy上，而Proxy跟Redis實例之間只保持很少的連接，這樣降低了Redis的負擔，避免了因為連接增加而導致的Redis時延升高。

3、集群遷移切換需要應用重啟

在使用過程中，隨著業務的增長，Redis集群的數據量會持續增加，當每個節點的數據量過高時，BGSAVE的時間會大大延長，降低集群的可用度。同時QPS的增加也會導致每個節點的CPU使用率增高。這都需要增加擴容集群來解決。目前Redis Cluster的橫向擴展能力不是很好，原生的slots搬移方案效率很低。新增節點后，有些客戶端比如Lettuce，會因為安全機制無法識別新節點。另外遷移時間也完全無法預估，遷移過程中遇到問題也無法回退。

當前物理機集群的擴容方案是：

•  按需創建新集群；

•  使用同步工具將數據從老集群同步到新集群；

•  確認數據無誤后，跟業務溝通，重啟服務切換到新集群。

整個過程繁瑣而且風險較大，還需要業務重啟服務。

有了Proxy層，可以將后端的創建、同步和切換集群對客戶端屏蔽掉。新老集群同步完成之后，向Proxy發送命令就可以將連接換到新集群，可以實現對客戶端完全無感知的集群擴縮容。

4、數據安全風險

Redis是通過AUTH來實現鑒權操作，客戶端直連Redis，密碼還是需要在客戶端保存。而使用Proxy，客戶端只需要通過Proxy的密碼來訪問Proxy，不需要知道Redis的密碼。Proxy還限制了FLUSHDB、CONFIG SET等操作，避免了客戶誤操作清空數據或修改Redis配置，大大提高了系統的安全性。

同時，Redis并沒有提供審計功能。我們在Proxy上增加了高危操作的日志保存功能，可以在不影響整體性能的前提下提供審計能力。

四、Proxy帶來的問題

1、多一跳帶來的時延

Proxy在客戶端和Redis實例之間，客戶端訪問Redis數據需要先訪問Proxy再訪問Redis節點，多了一跳，會導致時延增加。經測試，多一跳會增加0.2~0.3ms的時延，不過通常這對業務來說是可以接受的。

2、Pod漂移造成IP變化

Proxy在K8s上是通過deployment部署的，一樣會有節點重啟導致IP變化的問題。我們K8s的LB方案可以感知到Proxy的IP變化，動態的將LVS的流量切到重啟后的Proxy上。

3、LVS帶來的時延

LVS也會帶來時延，如下表中的測試，不同的數據長度get/set操作，LVS引入的時延小于0.1ms。

五、K8s帶來的好處

1、部署方便

通過運維平臺調用K8s API部署集群，大大提高了運維效率。

2、解決端口管理問題

目前小米在物理機上部署Redis實例是通過端口來區分的，并且下線的端口不能復用，也就是說整個公司每個Redis實例都有唯一的端口號。目前65535個端口已經用到了40000多，按現在的業務發展速度，將在兩年內耗盡端口資源。而通過K8s部署，每一個Redis實例對應的K8s pod都有獨立的IP，不存在端口耗盡問題和復雜的管理問題。

3、降低客戶使用門檻

對應用來說，只需要使用單機版的非智能客戶端連接VIP，降低了使用門檻，避免了繁瑣復雜的參數設置。同時由于VIP和端口是固定不變的，應用程序不再需要自己管理Redis Cluster的拓撲。

4、提高客戶端性能

使用非智能客戶端還可以降低客戶端的負載，因為智能客戶端需要在客戶端對key進行hash以確定將請求發送到哪個Redis節點，在QPS比較高的情況下會消耗客戶端機器的CPU資源。當然，為了降低客戶端應用遷移的難度，我們讓Proxy也支持了智能客戶端協議。

5、動態升級和擴縮容

Proxy支持動態添加切換Redis Cluster的功能，這樣Redis Cluster的集群升級和擴容切換過程可以做到對業務端完全無感知。例如，業務方使用30個節點的Redis Cluster集群，由于業務量的增加，數據量和QPS都增長的很快，需要將集群規模擴容兩倍。如果在原有的物理機上擴容，需要以下過程:

•  協調資源，部署60個節點的新集群；

•  手動配置遷移工具，將當前集群的數據遷移到新集群；

•  驗證數據無誤后，通知業務方修改Redis Cluster連接池拓撲，重啟服務。

雖然Redis Cluster支持在線擴容，但是擴容過程中slots搬移會對線上業務造成影響，同時遷移時間不可控，所以現階段很少采用這種方式，只有在資源嚴重不足時才會偶爾使用。

在新的K8s架構下，遷移過程如下：

•  通過API接口一鍵創建60個節點的新集群；

•  同樣通過API接口一鍵創建集群同步工具，將數據遷移到新集群；

•  驗證數據無誤后，向Proxy發送命令添加新集群信息并完成切換。

整個過程對業務端完全無感知。

集群升級也很方便：如果業務方能接受一定的延遲毛刺，可以在低峰時通過StatefulSet滾動升級的方式來實現；如果業務對延遲有要求，可以通過創建新集群遷移數據的方式來實現。

6、提高服務穩定性和資源利用率

通過K8s自帶的資源隔離能力，實現和其他不同類型應用混部，在提高資源利用率的同時，也能保證服務穩定性。

六、遇到的問題

1、Pod重啟導致數據丟失

K8s的pod碰到問題重啟時，由于重啟速度過快，會在Redis Cluster集群發現并切主前將pod重啟。如果pod上的Redis是slave，不會造成什么影響。但如果Redis是master，并且沒有AOF，重啟后原先內存的數據都被清空，Redis會reload之前存儲的RDB文件，但是RDB文件并不是實時的數據。之后slave也會跟著把自己的數據同步成之前的RDB文件中的數據鏡像，會造成部分數據丟失。

StatefulSet是有狀態服務，部署的pod名是固定格式(StatefulSet名+編號)。我們在初始化Redis Cluster時，將相鄰編號的pod設置為主從關系。在重啟pod時，通過pod名確定它的slave，在重啟pod前向從節點發送cluster failover命令，強制將活著的從節點切主。這樣在重啟后，該節點會自動以從節點方式加入集群。

LVS映射時延

Proxy的pod是通過LVS實現負載均衡的，LVS對后端IP:Port的映射生效有一定的時延，Proxy節點突然下線會導致部分連接丟失。為減少Proxy運維對業務造成影響，我們在Proxy的deployment模板中增加了如下選項：

lifecycle:    preStop:      exec:        command:        - sleep        - "171"

對于正常的Proxy pod下線，例如集群縮容、滾動更新Proxy版本以及其它K8s可控的pod下線，在pod下線前會發消息給LVS并等待171秒，這段時間足夠LVS將這個pod的流量逐漸切到其他pod上，對業務無感知。

2、K8s StatefulSet無法滿足Redis Cluster部署要求

K8s原生的StatefulSet不能完全滿足Redis Cluster部署的要求：

1）Redis Cluster不允許同為主備關系的節點部署在同一臺機器上。這個很好理解，如果該機器宕機，會導致這個數據分片不可用。

2）Redis Cluster不允許集群超過一半的主節點失效，因為如果超過一半主節點失效，就無法有足夠的節點投票來滿足gossip協議的要求。因為Redis Cluster的主備是可能隨時切換的，我們無法避免同一個機器上的所有節點都是主節點這種情況，所以在部署時不能允許集群中超過1/4的節點部署在同一臺機器上。

為了滿足上面的要求，原生StatefulSet可以通過 anti-affinity 功能來保證相同集群在同一臺機器上只部署一個節點，但是這樣機器利用率很低。

因此我們開發了基于StatefulSet的CRD：RedisStatefulSet，會采用多種策略部署Redis節點。同時，還在RedisStatefulSet中加入了一些Redis管理功能。這些我們將會在其他文章中來繼續詳細探討。

七、總結

目前集團內部已經有多個業務的數十個Redis集群部署到了K8s上并運行了半年多。得益于K8s的快速部署和故障遷移能力，這些集群的運維工作量比物理機上的Redis集群低很多，穩定性也得到了充分的驗證。

在運維過程中我們也遇到了不少問題，文章中提到的很多功能都是根據實際需求提煉出來的。目前還是有很多問題需要在后續逐步解決，以進一步提高資源利用率和服務質量。

1、混布 Vs. 獨立部署

物理機的Redis實例是獨立部署的，單臺物理機上部署的都是Redis實例，這樣有利于管理，但是資源利用率并不高。Redis實例使用了CPU、內存和網絡IO，但存儲空間基本都是浪費的。在K8s上部署Redis實例，其所在的機器上可能也會部署其他任意類型的服務，這樣雖然可以提高機器的利用率，但是對于Redis這樣的可用性和時延要求都很高的服務來說，如果因為機器內存不足而被驅逐，是不能接受的。這就需要運維人員監控所有部署了Redis實例的機器內存，一旦內存不足，就切主和遷移節點，但這樣又增加運維的工作量。

同時，如果混部的其他服務是網絡吞吐很高的應用，也可能對Redis服務造成影響。雖然K8s的anti-affinity功能可以將Redis實例有選擇地部署到沒有這類應用的機器上，但是在機器資源緊張時，還是無法避免這種情況。

2、Redis Cluster管理

Redis Cluster是一個P2P無中心節點的集群架構，依靠gossip協議傳播協同自動化修復集群的狀態，節點上下線和網絡問題都可能導致Redis Cluster的部分節點狀態出現問題，例如會在集群拓撲中出現failed或者handshake狀態的節點，甚至腦裂。對這種異常狀態，我們可以在Redis CRD上增加更多的功能來逐步解決，進一步提高運維效率。

3、審計與安全

Redis本身只提供了Auth密碼認證保護功能，沒有權限管理，安全性較差。通過Proxy，我們可以通過密碼區分客戶端類型，管理員和普通用戶使用不同的密碼登錄，可執行的操作權限也不同，這樣就可以實現權限管理和操作審計等功能。

4、支持多Redis Cluster

單個Redis Cluster由于gossip協議的限制，橫向擴展能力有限，集群規模在300個節點時，節點選主這類拓撲變更的效率就明顯降低。同時，由于單個Redis實例的容量不宜過高，單個Redis Cluster也很難支持TB以上的數據規模。通過Proxy，我們可以對key做邏輯分片，這樣單個Proxy就可以接入多個Redis Cluster，從客戶端的視角來看，就相當于接入了一個能夠支持更大數據規模的Redis集群。

以上就是關于“Redis集群實例分析”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。