共計(jì) 6829 個(gè)字符，預(yù)計(jì)需要花費(fèi) 18 分鐘才能閱讀完成。

這篇“Redis 集群實(shí)例分析”文章的知識(shí)點(diǎn)大部分人都不太理解，所以丸趣 TV 小編給大家總結(jié)了以下內(nèi)容，內(nèi)容詳細(xì)，步驟清晰，具有一定的借鑒價(jià)值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來(lái)看看這篇“Redis 集群實(shí)例分析”文章吧。

一、Why K8s

1、資源隔離

當(dāng)前的 Redis Cluster 部署在物理機(jī)集群上，為了提高資源利用率節(jié)約成本，多業(yè)務(wù)線的 Redis 集群都是混布的。由于沒(méi)有做 CPU 的資源隔離，經(jīng)常出現(xiàn)某 Redis 節(jié)點(diǎn) CPU 使用率過(guò)高導(dǎo)致其他 Redis 集群的節(jié)點(diǎn)爭(zhēng)搶不到 CPU 資源引起時(shí)延抖動(dòng)。因?yàn)椴煌募夯觳迹@類問(wèn)題很難快速定位，影響運(yùn)維效率。K8s 容器化部署可以指定 CPU request 和 CPU limit，在提高資源利用率的同時(shí)避免了資源爭(zhēng)搶。

2、自動(dòng)化部署

當(dāng)前 Redis Cluster 在物理機(jī)上的部署過(guò)程十分繁瑣，需要通過(guò)查看元信息數(shù)據(jù)庫(kù)查找有空余資源的機(jī)器，手動(dòng)修改很多配置文件再逐個(gè)部署節(jié)點(diǎn)，最后使用 redis_trib 工具創(chuàng)建集群，新集群的初始化工作經(jīng)常需要一兩個(gè)小時(shí)。

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

二、How K8s

客戶端通過(guò) LVS 的 VIP 統(tǒng)一接入，通過(guò) Redis Proxy 轉(zhuǎn)發(fā)服務(wù)請(qǐng)求到 Redis Cluster 集群。這里我們引入了 Redis Proxy 來(lái)轉(zhuǎn)發(fā)請(qǐng)求。

1、Redis Cluster 部署方式

Redis 部署為 StatefulSet，作為有狀態(tài)的服務(wù)，選擇 StatefulSet 最為合理，可以將節(jié)點(diǎn)的 RDB/AOF 持久化到分布式存儲(chǔ)中。當(dāng)節(jié)點(diǎn)重啟漂移到其他機(jī)器上時(shí)，可通過(guò)掛載的 PVC(PersistentVolumeClaim)拿到原來(lái)的 RDB/AOF 來(lái)同步數(shù)據(jù)。

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

2、Proxy 選型

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

我們希望能夠繼續(xù)使用 Redis Cluster 來(lái)管理 Redis 集群，所以 Codis 和 Twemproxy 不再考慮。redis-cluster-proxy 是 Redis 官方在 6.0 版本推出的支持 Redis Cluster 協(xié)議的 Proxy，但是目前還沒(méi)有穩(wěn)定版，暫時(shí)也無(wú)法大規(guī)模應(yīng)用。

備選就只有 Cerberus 和 Predixy 兩種。我們?cè)?K8s 環(huán)境上對(duì) Cerberus 和 Predixy 進(jìn)行了性能測(cè)試，結(jié)果如下:

測(cè)試環(huán)境

測(cè)試工具: redis-benchmark

Proxy CPU: 2 core

Client CPU: 2 core

Redis Cluster: 3 master nodes, 1 CPU per node

測(cè)試結(jié)果

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

為了適應(yīng)業(yè)務(wù)和 K8s 環(huán)境，在上線前我們對(duì) Predixy 做了大量的改動(dòng)，增加了很多新的功能，比如動(dòng)態(tài)切換后端 Redis Cluster、黑白名單、異常操作審計(jì)等。

3、Proxy 部署方式

Proxy 作為 deployment 部署，無(wú)狀態(tài)輕量化，通過(guò) LB 對(duì)外提供服務(wù)，很容易做到動(dòng)態(tài)擴(kuò)縮容。同時(shí)，我們?yōu)?Proxy 開發(fā)了動(dòng)態(tài)切換后端 Redis Cluster 的功能，可實(shí)現(xiàn)在線添加和切換 Redis Cluster。

4、Proxy 自動(dòng)擴(kuò)縮容方式

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

HPA 可配置集群的最少 (MINPODS) 和最多(MAXPODS)pod 數(shù)量，集群負(fù)載再低也不會(huì)縮容到 MINPODS 以下數(shù)量的 pods。建議客戶可以根據(jù)自己的實(shí)際業(yè)務(wù)情況來(lái)決定 MINPODS 和 MAXPODS 的值。

三、Why Proxy

1、Redis pod 重啟可導(dǎo)致 IP 變化

使用 Redis Cluster 的 Redis 客戶端，都需要配置集群的部分 IP 和 Port，用于客戶端重啟時(shí)查找 Redis Cluster 的入口。對(duì)于物理機(jī)集群部署的 Redis 節(jié)點(diǎn)，即便遇到實(shí)例重啟或者機(jī)器重啟，IP 和 Port 都可以保持不變，客戶端依然能夠找到 Redis Cluster 的拓?fù)洹５遣渴鹪?K8s 上的 Redis Cluster，pod 重啟是不保證 IP 不變的(即便是重啟在原來(lái)的 K8s node 上)，這樣客戶端重啟時(shí)，就可能會(huì)找不到 Redis Cluster 的入口。

通過(guò)在客戶端和 Redis Cluster 之間加上 Proxy，就對(duì)客戶端屏蔽了 Redis Cluster 的信息，Proxy 可以動(dòng)態(tài)感知 Redis Cluster 的拓?fù)渥兓蛻舳酥恍枰獙?LVS 的 IP:Port 作為入口，請(qǐng)求轉(zhuǎn)發(fā)到 Proxy 上，即可以像使用單機(jī)版 Redis 一樣使用 Redis Cluster 集群，而不需要 Redis 智能客戶端。

2、Redis 處理連接負(fù)載高

在 6.0 版本之前，Redis 都是單線程處理大部分任務(wù)的。當(dāng) Redis 節(jié)點(diǎn)的連接較高時(shí)，Redis 需要消耗大量的 CPU 資源處理這些連接，導(dǎo)致時(shí)延升高。有了 Proxy 之后，大量連接都在 Proxy 上，而 Proxy 跟 Redis 實(shí)例之間只保持很少的連接，這樣降低了 Redis 的負(fù)擔(dān)，避免了因?yàn)檫B接增加而導(dǎo)致的 Redis 時(shí)延升高。

3、集群遷移切換需要應(yīng)用重啟

在使用過(guò)程中，隨著業(yè)務(wù)的增長(zhǎng)，Redis 集群的數(shù)據(jù)量會(huì)持續(xù)增加，當(dāng)每個(gè)節(jié)點(diǎn)的數(shù)據(jù)量過(guò)高時(shí)，BGSAVE 的時(shí)間會(huì)大大延長(zhǎng)，降低集群的可用度。同時(shí) QPS 的增加也會(huì)導(dǎo)致每個(gè)節(jié)點(diǎn)的 CPU 使用率增高。這都需要增加擴(kuò)容集群來(lái)解決。目前 Redis Cluster 的橫向擴(kuò)展能力不是很好，原生的 slots 搬移方案效率很低。新增節(jié)點(diǎn)后，有些客戶端比如 Lettuce，會(huì)因?yàn)榘踩珯C(jī)制無(wú)法識(shí)別新節(jié)點(diǎn)。另外遷移時(shí)間也完全無(wú)法預(yù)估，遷移過(guò)程中遇到問(wèn)題也無(wú)法回退。

當(dāng)前物理機(jī)集群的擴(kuò)容方案是：

  按需創(chuàng)建新集群；

  使用同步工具將數(shù)據(jù)從老集群同步到新集群；

  確認(rèn)數(shù)據(jù)無(wú)誤后，跟業(yè)務(wù)溝通，重啟服務(wù)切換到新集群。

整個(gè)過(guò)程繁瑣而且風(fēng)險(xiǎn)較大，還需要業(yè)務(wù)重啟服務(wù)。

有了 Proxy 層，可以將后端的創(chuàng)建、同步和切換集群對(duì)客戶端屏蔽掉。新老集群同步完成之后，向 Proxy 發(fā)送命令就可以將連接換到新集群，可以實(shí)現(xiàn)對(duì)客戶端完全無(wú)感知的集群擴(kuò)縮容。

4、數(shù)據(jù)安全風(fēng)險(xiǎn)

Redis 是通過(guò) AUTH 來(lái)實(shí)現(xiàn)鑒權(quán)操作，客戶端直連 Redis，密碼還是需要在客戶端保存。而使用 Proxy，客戶端只需要通過(guò) Proxy 的密碼來(lái)訪問(wèn) Proxy，不需要知道 Redis 的密碼。Proxy 還限制了 FLUSHDB、CONFIG SET 等操作，避免了客戶誤操作清空數(shù)據(jù)或修改 Redis 配置，大大提高了系統(tǒng)的安全性。

同時(shí)，Redis 并沒(méi)有提供審計(jì)功能。我們?cè)?Proxy 上增加了高危操作的日志保存功能，可以在不影響整體性能的前提下提供審計(jì)能力。

四、Proxy 帶來(lái)的問(wèn)題

1、多一跳帶來(lái)的時(shí)延

Proxy 在客戶端和 Redis 實(shí)例之間，客戶端訪問(wèn) Redis 數(shù)據(jù)需要先訪問(wèn) Proxy 再訪問(wèn) Redis 節(jié)點(diǎn)，多了一跳，會(huì)導(dǎo)致時(shí)延增加。經(jīng)測(cè)試，多一跳會(huì)增加 0.2~0.3ms 的時(shí)延，不過(guò)通常這對(duì)業(yè)務(wù)來(lái)說(shuō)是可以接受的。

2、Pod 漂移造成 IP 變化

Proxy 在 K8s 上是通過(guò) deployment 部署的，一樣會(huì)有節(jié)點(diǎn)重啟導(dǎo)致 IP 變化的問(wèn)題。我們 K8s 的 LB 方案可以感知到 Proxy 的 IP 變化，動(dòng)態(tài)的將 LVS 的流量切到重啟后的 Proxy 上。

3、LVS 帶來(lái)的時(shí)延

LVS 也會(huì)帶來(lái)時(shí)延，如下表中的測(cè)試，不同的數(shù)據(jù)長(zhǎng)度 get/set 操作，LVS 引入的時(shí)延小于 0.1ms。

五、K8s 帶來(lái)的好處

1、部署方便

通過(guò)運(yùn)維平臺(tái)調(diào)用 K8s API 部署集群，大大提高了運(yùn)維效率。

2、解決端口管理問(wèn)題

目前小米在物理機(jī)上部署 Redis 實(shí)例是通過(guò)端口來(lái)區(qū)分的，并且下線的端口不能復(fù)用，也就是說(shuō)整個(gè)公司每個(gè) Redis 實(shí)例都有唯一的端口號(hào)。目前 65535 個(gè)端口已經(jīng)用到了 40000 多，按現(xiàn)在的業(yè)務(wù)發(fā)展速度，將在兩年內(nèi)耗盡端口資源。而通過(guò) K8s 部署，每一個(gè) Redis 實(shí)例對(duì)應(yīng)的 K8s pod 都有獨(dú)立的 IP，不存在端口耗盡問(wèn)題和復(fù)雜的管理問(wèn)題。

3、降低客戶使用門檻

對(duì)應(yīng)用來(lái)說(shuō)，只需要使用單機(jī)版的非智能客戶端連接 VIP，降低了使用門檻，避免了繁瑣復(fù)雜的參數(shù)設(shè)置。同時(shí)由于 VIP 和端口是固定不變的，應(yīng)用程序不再需要自己管理 Redis Cluster 的拓?fù)洹?/p>

4、提高客戶端性能

使用非智能客戶端還可以降低客戶端的負(fù)載，因?yàn)橹悄芸蛻舳诵枰诳蛻舳藢?duì) key 進(jìn)行 hash 以確定將請(qǐng)求發(fā)送到哪個(gè) Redis 節(jié)點(diǎn)，在 QPS 比較高的情況下會(huì)消耗客戶端機(jī)器的 CPU 資源。當(dāng)然，為了降低客戶端應(yīng)用遷移的難度，我們讓 Proxy 也支持了智能客戶端協(xié)議。

5、動(dòng)態(tài)升級(jí)和擴(kuò)縮容

Proxy 支持動(dòng)態(tài)添加切換 Redis Cluster 的功能，這樣 Redis Cluster 的集群升級(jí)和擴(kuò)容切換過(guò)程可以做到對(duì)業(yè)務(wù)端完全無(wú)感知。例如，業(yè)務(wù)方使用 30 個(gè)節(jié)點(diǎn)的 Redis Cluster 集群，由于業(yè)務(wù)量的增加，數(shù)據(jù)量和 QPS 都增長(zhǎng)的很快，需要將集群規(guī)模擴(kuò)容兩倍。如果在原有的物理機(jī)上擴(kuò)容，需要以下過(guò)程:

  協(xié)調(diào)資源，部署 60 個(gè)節(jié)點(diǎn)的新集群；

  手動(dòng)配置遷移工具，將當(dāng)前集群的數(shù)據(jù)遷移到新集群；

  驗(yàn)證數(shù)據(jù)無(wú)誤后，通知業(yè)務(wù)方修改 Redis Cluster 連接池拓?fù)洌貑⒎?wù)。

雖然 Redis Cluster 支持在線擴(kuò)容，但是擴(kuò)容過(guò)程中 slots 搬移會(huì)對(duì)線上業(yè)務(wù)造成影響，同時(shí)遷移時(shí)間不可控，所以現(xiàn)階段很少采用這種方式，只有在資源嚴(yán)重不足時(shí)才會(huì)偶爾使用。

在新的 K8s 架構(gòu)下，遷移過(guò)程如下：

  通過(guò) API 接口一鍵創(chuàng)建 60 個(gè)節(jié)點(diǎn)的新集群；

  同樣通過(guò) API 接口一鍵創(chuàng)建集群同步工具，將數(shù)據(jù)遷移到新集群；

  驗(yàn)證數(shù)據(jù)無(wú)誤后，向 Proxy 發(fā)送命令添加新集群信息并完成切換。

整個(gè)過(guò)程對(duì)業(yè)務(wù)端完全無(wú)感知。

集群升級(jí)也很方便：如果業(yè)務(wù)方能接受一定的延遲毛刺，可以在低峰時(shí)通過(guò) StatefulSet 滾動(dòng)升級(jí)的方式來(lái)實(shí)現(xiàn)；如果業(yè)務(wù)對(duì)延遲有要求，可以通過(guò)創(chuàng)建新集群遷移數(shù)據(jù)的方式來(lái)實(shí)現(xiàn)。

6、提高服務(wù)穩(wěn)定性和資源利用率

通過(guò) K8s 自帶的資源隔離能力，實(shí)現(xiàn)和其他不同類型應(yīng)用混部，在提高資源利用率的同時(shí)，也能保證服務(wù)穩(wěn)定性。

六、遇到的問(wèn)題

1、Pod 重啟導(dǎo)致數(shù)據(jù)丟失

K8s 的 pod 碰到問(wèn)題重啟時(shí)，由于重啟速度過(guò)快，會(huì)在 Redis Cluster 集群發(fā)現(xiàn)并切主前將 pod 重啟。如果 pod 上的 Redis 是 slave，不會(huì)造成什么影響。但如果 Redis 是 master，并且沒(méi)有 AOF，重啟后原先內(nèi)存的數(shù)據(jù)都被清空，Redis 會(huì) reload 之前存儲(chǔ)的 RDB 文件，但是 RDB 文件并不是實(shí)時(shí)的數(shù)據(jù)。之后 slave 也會(huì)跟著把自己的數(shù)據(jù)同步成之前的 RDB 文件中的數(shù)據(jù)鏡像，會(huì)造成部分?jǐn)?shù)據(jù)丟失。

StatefulSet 是有狀態(tài)服務(wù)，部署的 pod 名是固定格式(StatefulSet 名 + 編號(hào))。我們?cè)诔跏蓟?Redis Cluster 時(shí)，將相鄰編號(hào)的 pod 設(shè)置為主從關(guān)系。在重啟 pod 時(shí)，通過(guò) pod 名確定它的 slave，在重啟 pod 前向從節(jié)點(diǎn)發(fā)送 cluster failover 命令，強(qiáng)制將活著的從節(jié)點(diǎn)切主。這樣在重啟后，該節(jié)點(diǎn)會(huì)自動(dòng)以從節(jié)點(diǎn)方式加入集群。

LVS 映射時(shí)延

Proxy 的 pod 是通過(guò) LVS 實(shí)現(xiàn)負(fù)載均衡的，LVS 對(duì)后端 IP:Port 的映射生效有一定的時(shí)延，Proxy 節(jié)點(diǎn)突然下線會(huì)導(dǎo)致部分連接丟失。為減少 Proxy 運(yùn)維對(duì)業(yè)務(wù)造成影響，我們?cè)?Proxy 的 deployment 模板中增加了如下選項(xiàng)：

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

對(duì)于正常的 Proxy pod 下線，例如集群縮容、滾動(dòng)更新 Proxy 版本以及其它 K8s 可控的 pod 下線，在 pod 下線前會(huì)發(fā)消息給 LVS 并等待 171 秒，這段時(shí)間足夠 LVS 將這個(gè) pod 的流量逐漸切到其他 pod 上，對(duì)業(yè)務(wù)無(wú)感知。

2、K8s StatefulSet 無(wú)法滿足 Redis Cluster 部署要求

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

1）Redis Cluster 不允許同為主備關(guān)系的節(jié)點(diǎn)部署在同一臺(tái)機(jī)器上。這個(gè)很好理解，如果該機(jī)器宕機(jī)，會(huì)導(dǎo)致這個(gè)數(shù)據(jù)分片不可用。

2）Redis Cluster 不允許集群超過(guò)一半的主節(jié)點(diǎn)失效，因?yàn)槿绻^(guò)一半主節(jié)點(diǎn)失效，就無(wú)法有足夠的節(jié)點(diǎn)投票來(lái)滿足 gossip 協(xié)議的要求。因?yàn)?Redis Cluster 的主備是可能隨時(shí)切換的，我們無(wú)法避免同一個(gè)機(jī)器上的所有節(jié)點(diǎn)都是主節(jié)點(diǎn)這種情況，所以在部署時(shí)不能允許集群中超過(guò) 1 / 4 的節(jié)點(diǎn)部署在同一臺(tái)機(jī)器上。

為了滿足上面的要求，原生 StatefulSet 可以通過(guò) anti-affinity 功能來(lái)保證相同集群在同一臺(tái)機(jī)器上只部署一個(gè)節(jié)點(diǎn)，但是這樣機(jī)器利用率很低。

因此我們開發(fā)了基于 StatefulSet 的 CRD：RedisStatefulSet，會(huì)采用多種策略部署 Redis 節(jié)點(diǎn)。同時(shí)，還在 RedisStatefulSet 中加入了一些 Redis 管理功能。這些我們將會(huì)在其他文章中來(lái)繼續(xù)詳細(xì)探討。

七、總結(jié)

目前集團(tuán)內(nèi)部已經(jīng)有多個(gè)業(yè)務(wù)的數(shù)十個(gè) Redis 集群部署到了 K8s 上并運(yùn)行了半年多。得益于 K8s 的快速部署和故障遷移能力，這些集群的運(yùn)維工作量比物理機(jī)上的 Redis 集群低很多，穩(wěn)定性也得到了充分的驗(yàn)證。

在運(yùn)維過(guò)程中我們也遇到了不少問(wèn)題，文章中提到的很多功能都是根據(jù)實(shí)際需求提煉出來(lái)的。目前還是有很多問(wèn)題需要在后續(xù)逐步解決，以進(jìn)一步提高資源利用率和服務(wù)質(zhì)量。

1、混布 Vs. 獨(dú)立部署

物理機(jī)的 Redis 實(shí)例是獨(dú)立部署的，單臺(tái)物理機(jī)上部署的都是 Redis 實(shí)例，這樣有利于管理，但是資源利用率并不高。Redis 實(shí)例使用了 CPU、內(nèi)存和網(wǎng)絡(luò) IO，但存儲(chǔ)空間基本都是浪費(fèi)的。在 K8s 上部署 Redis 實(shí)例，其所在的機(jī)器上可能也會(huì)部署其他任意類型的服務(wù)，這樣雖然可以提高機(jī)器的利用率，但是對(duì)于 Redis 這樣的可用性和時(shí)延要求都很高的服務(wù)來(lái)說(shuō)，如果因?yàn)闄C(jī)器內(nèi)存不足而被驅(qū)逐，是不能接受的。這就需要運(yùn)維人員監(jiān)控所有部署了 Redis 實(shí)例的機(jī)器內(nèi)存，一旦內(nèi)存不足，就切主和遷移節(jié)點(diǎn)，但這樣又增加運(yùn)維的工作量。

同時(shí)，如果混部的其他服務(wù)是網(wǎng)絡(luò)吞吐很高的應(yīng)用，也可能對(duì) Redis 服務(wù)造成影響。雖然 K8s 的 anti-affinity 功能可以將 Redis 實(shí)例有選擇地部署到?jīng)]有這類應(yīng)用的機(jī)器上，但是在機(jī)器資源緊張時(shí)，還是無(wú)法避免這種情況。

2、Redis Cluster 管理

Redis Cluster 是一個(gè) P2P 無(wú)中心節(jié)點(diǎn)的集群架構(gòu)，依靠 gossip 協(xié)議傳播協(xié)同自動(dòng)化修復(fù)集群的狀態(tài)，節(jié)點(diǎn)上下線和網(wǎng)絡(luò)問(wèn)題都可能導(dǎo)致 Redis Cluster 的部分節(jié)點(diǎn)狀態(tài)出現(xiàn)問(wèn)題，例如會(huì)在集群拓?fù)渲谐霈F(xiàn) failed 或者 handshake 狀態(tài)的節(jié)點(diǎn)，甚至腦裂。對(duì)這種異常狀態(tài)，我們可以在 Redis CRD 上增加更多的功能來(lái)逐步解決，進(jìn)一步提高運(yùn)維效率。

3、審計(jì)與安全

Redis 本身只提供了 Auth 密碼認(rèn)證保護(hù)功能，沒(méi)有權(quán)限管理，安全性較差。通過(guò) Proxy，我們可以通過(guò)密碼區(qū)分客戶端類型，管理員和普通用戶使用不同的密碼登錄，可執(zhí)行的操作權(quán)限也不同，這樣就可以實(shí)現(xiàn)權(quán)限管理和操作審計(jì)等功能。

4、支持多 Redis Cluster

單個(gè) Redis Cluster 由于 gossip 協(xié)議的限制，橫向擴(kuò)展能力有限，集群規(guī)模在 300 個(gè)節(jié)點(diǎn)時(shí)，節(jié)點(diǎn)選主這類拓?fù)渥兏男示兔黠@降低。同時(shí)，由于單個(gè) Redis 實(shí)例的容量不宜過(guò)高，單個(gè) Redis Cluster 也很難支持 TB 以上的數(shù)據(jù)規(guī)模。通過(guò) Proxy，我們可以對(duì) key 做邏輯分片，這樣單個(gè) Proxy 就可以接入多個(gè) Redis Cluster，從客戶端的視角來(lái)看，就相當(dāng)于接入了一個(gè)能夠支持更大數(shù)據(jù)規(guī)模的 Redis 集群。

以上就是關(guān)于“Redis 集群實(shí)例分析”這篇文章的內(nèi)容，相信大家都有了一定的了解，希望丸趣 TV 小編分享的內(nèi)容對(duì)大家有幫助，若想了解更多相關(guān)的知識(shí)內(nèi)容，請(qǐng)關(guān)注丸趣 TV 行業(yè)資訊頻道。