近千節(jié)點(diǎn)的Redis Cluster高可用集群案例:優(yōu)酷藍(lán)鯨優(yōu)化實(shí)戰(zhàn)

導(dǎo)讀：Redis Cluster 作者建議的最大集群規(guī)模 1,000 節(jié)點(diǎn)丈屹，目前優(yōu)酷在藍(lán)鯨項(xiàng)目中管理了超過(guò) 700 臺(tái)節(jié)點(diǎn)萍聊，積累了 Redis Cluster 大量寶貴經(jīng)驗(yàn)钞翔，本文從 Redis Cluster 的工作原理出發(fā)芬失，提出了管理 Redis 超大集群幾點(diǎn)行之有效的優(yōu)化方法暂吉。

吳建超揖赴，優(yōu)酷土豆廣告基礎(chǔ)平臺(tái)開發(fā)工程師诡延，對(duì)互聯(lián)網(wǎng)基礎(chǔ)產(chǎn)品及大數(shù)據(jù)產(chǎn)品有興趣鉴象。

在優(yōu)酷忙菠，我們使用 Redis Cluster 構(gòu)建了一套內(nèi)存存儲(chǔ)系統(tǒng)，項(xiàng)目代號(hào)為藍(lán)鯨纺弊。藍(lán)鯨的設(shè)計(jì)目標(biāo)是高效讀寫牛欢，所有數(shù)據(jù)都在內(nèi)存中。藍(lán)鯨的主要應(yīng)用場(chǎng)景是 cookie 和大數(shù)據(jù)團(tuán)隊(duì)計(jì)算的數(shù)據(jù)淆游，都具有較強(qiáng)的時(shí)效性傍睹，因此所有的數(shù)據(jù)都有過(guò)期時(shí)間。更準(zhǔn)確的說(shuō)藍(lán)鯨是一個(gè)全內(nèi)存的臨時(shí)存儲(chǔ)系統(tǒng)犹菱。

到目前為止集群規(guī)模逐漸增長(zhǎng)到 700+ 節(jié)點(diǎn)拾稳，即將達(dá)到作者建議的最大集群規(guī)模 1,000 節(jié)點(diǎn)。我們發(fā)現(xiàn)隨著集群規(guī)模的擴(kuò)大腊脱，帶寬壓力不斷突出访得，并且響應(yīng)時(shí)間 RT 方面也會(huì)略微升高。與一致性哈希構(gòu)建的 Redis 集群不一樣陕凹，Redis Cluster 不能做成超大規(guī)模的集群悍抑，它比較適合作為中等規(guī)模集群的解決方案。

運(yùn)維期間杜耙，吞吐量與 RT 一直作為衡量集群穩(wěn)定性的重要指標(biāo)搜骡，這里在本文中，我們碰到的影響集群吞吐量與 RT 的一些問(wèn)題與探索記錄下來(lái)泥技，希望對(duì)大家有所幫助浆兰。

Redis Cluster 工作原理

Redis 采用單進(jìn)程模型磕仅，除去 bgsave 與 aof rewrite 會(huì)另外新建進(jìn)程外珊豹，所有的請(qǐng)求與操作都在主進(jìn)程內(nèi)完成。其中比較重量級(jí)的請(qǐng)求與操作類型有：

客戶端請(qǐng)求

集群通訊

從節(jié)同步

AOF 文件

其它定時(shí)任務(wù)

Redis 服務(wù)端采用 Reactor 設(shè)計(jì)模式榕订，它是一種基于事件的編程模型店茶，主要思想是將請(qǐng)求的處理流程劃分成有序的事件序列，比如對(duì)于網(wǎng)絡(luò)請(qǐng)求通常劃分為：Accept new connections劫恒、Read input to buffer贩幻、Process request轿腺、 Response 等幾個(gè)事件。并在一個(gè)無(wú)限循環(huán)的 EventLoop 中不斷的處理這些事件丛楚。更多關(guān)于Reactor族壳，請(qǐng)參考https://en.wikipedia.org/wiki/Reactor。

比較特別的是趣些，Redis 中還存在一種時(shí)間事件仿荆，它其實(shí)是定時(shí)任務(wù)，與請(qǐng)求事件一樣坏平，它同樣在 EventLoop 中處理拢操。Redis 主線程的主要處理流程如下圖：

Redis main process playload overview

(http://image.cnthrowable.com/upload/throwable_blog/itbroblog/blog/1468841487158_38.png)

理解了 Redis 的單進(jìn)程模型與主要負(fù)載情況，很容易明白舶替，想要增加 Redis 吞吐量令境，只需要盡量降低其它任務(wù)的負(fù)載量就行了，所以提高 Redis 集群吞吐量的方式主要有：

提高 Redis 集群吞吐的方法

1. 適當(dāng)調(diào)大 cluster-node-timeout 參數(shù)

我們發(fā)現(xiàn)當(dāng)集群規(guī)模達(dá)到一定程度時(shí)顾瞪，集群間消息通訊開銷的帶寬是極其可觀的舔庶。

集群通信機(jī)制

Redis 集群采用無(wú)中心的方式，為了維護(hù)集群狀態(tài)統(tǒng)一玲昧，節(jié)點(diǎn)之間需要互相交換消息栖茉。Redis采用交換消息的方式被稱為 Gossip ，基本思想是節(jié)點(diǎn)之間互相交換信息最終所有節(jié)點(diǎn)達(dá)到一致孵延，更多關(guān)于 Gossip 可參考https://en.wikipedia.org/wiki/Gossip_protocol吕漂。

Gossip in Redis Cluster

(http://image.cnthrowable.com/upload/throwable_blog/itbroblog/blog/1468841537279_410.png)

總結(jié)集群通信機(jī)制的一些要點(diǎn)：

Who：集群中每個(gè)節(jié)點(diǎn)

When：定時(shí)發(fā)送，默認(rèn)每隔一秒

What：一個(gè)長(zhǎng)度為 16,384 的 Bitmap 與集群中其它節(jié)點(diǎn)狀態(tài)的十分之一

如何理解集群中節(jié)點(diǎn)狀態(tài)的十分之一尘应？假如集群中有 700 個(gè)節(jié)點(diǎn)惶凝，十分之一就是 70 個(gè)節(jié)點(diǎn)狀態(tài)，節(jié)點(diǎn)狀態(tài)具體數(shù)據(jù)結(jié)構(gòu)見下邊代碼：

我們將注意力放在數(shù)據(jù)包大小與流量上犬钢，每個(gè)節(jié)點(diǎn)狀態(tài)大小為 104 byte苍鲜，所以對(duì)于 700 個(gè)節(jié)點(diǎn)的集群，這部分消息的大小為 70 * 104 = 7280玷犹，大約為 7KB混滔。另外每個(gè)Gossip消息還需要攜帶一個(gè)長(zhǎng)度為 16,384 的 Bitmap，大小為 2KB歹颓，所以每個(gè) Gossip 消息大小大約為 9KB坯屿。

隨著集群規(guī)模的不斷擴(kuò)大，每臺(tái)主機(jī)的流量不斷增長(zhǎng)巍扛，我們懷疑集群間通信的流量已經(jīng)大于前端請(qǐng)求產(chǎn)生的流量领跛，所以做了以下實(shí)驗(yàn)以明確集群流量狀況。

實(shí)驗(yàn)過(guò)程

實(shí)驗(yàn)環(huán)境為：節(jié)點(diǎn) 704撤奸，物理主機(jī) 40 臺(tái)吠昭，每臺(tái)物理主機(jī)有 16 個(gè)節(jié)點(diǎn)喊括，集群采用一主一從模式，集群中節(jié)點(diǎn) cluster-node-timeout 設(shè)置為 30 秒矢棚。

實(shí)驗(yàn)的大概思路為郑什，分別截取一分鐘時(shí)間內(nèi)一個(gè)節(jié)點(diǎn)，在集群通信端口上蒲肋，進(jìn)入方向與出去方向的流量蹦误，并統(tǒng)計(jì)出消息條數(shù)，并最終計(jì)算出臺(tái)主機(jī)因?yàn)榧洪g通訊產(chǎn)生的帶寬開銷肉津。實(shí)驗(yàn)具體過(guò)程如下：

通過(guò)實(shí)驗(yàn)?zāi)芸吹竭M(jìn)入方向與出去方向在 60s 內(nèi)收到的數(shù)據(jù)包數(shù)量為 2,700 多個(gè)强胰。因?yàn)?Redis 規(guī)定每個(gè)節(jié)點(diǎn)每一秒只向一個(gè)節(jié)點(diǎn)發(fā)送數(shù)據(jù)包，所以正常情況每個(gè)節(jié)點(diǎn)平均 60s 會(huì)收到 60 個(gè)數(shù)據(jù)包妹沙，為什么會(huì)有這么大的差距偶洋？

原來(lái)考慮到 Redis 發(fā)送對(duì)象節(jié)點(diǎn)的選取是隨機(jī)的，所以存在兩個(gè)節(jié)點(diǎn)很久都沒(méi)有交換消息的情況距糖，為了保證集群狀態(tài)能在較短時(shí)間內(nèi)達(dá)到一致性玄窝，Redis 規(guī)定當(dāng)兩個(gè)節(jié)點(diǎn)超過(guò) cluster-node-timeout 的一半時(shí)間沒(méi)有交換消息時(shí)，下次心跳交換消息悍引。

解決了這個(gè)疑惑恩脂，接下來(lái)看帶寬情況。先看 Redis Cluster 集群通信端口進(jìn)入方向每臺(tái)主機(jī)的每秒帶寬為：

再看 Redis Cluster 集群通信端口出去方向每臺(tái)主機(jī)的每秒帶寬為：

所以每臺(tái)主機(jī)進(jìn)入方向的帶寬為：

為什么需要加和

我們以節(jié)點(diǎn) A 主動(dòng)與節(jié)點(diǎn) B 發(fā)生消息交換為例進(jìn)行說(shuō)明趣斤，交換過(guò)程如下圖：

Redis Cluster msg exchange

(http://image.cnthrowable.com/upload/throwable_blog/itbroblog/blog/1468917245456_981.png)

首先 A 隨機(jī)一個(gè)端口向節(jié)點(diǎn) B 的集群通訊端 17,380 發(fā)送 PING 消息俩块，之后節(jié)點(diǎn) B 通過(guò) 17,380 端口向節(jié)點(diǎn) A 發(fā)送 PONG 消息，PONG 消息的內(nèi)容與 PING 消息的內(nèi)容相似浓领，每個(gè)消息的大小也一樣（9KB）玉凯。同理當(dāng)節(jié)點(diǎn) B 主動(dòng)與節(jié)點(diǎn) A 發(fā)生消息交換時(shí)也是同樣的過(guò)程。

可以看出對(duì)于節(jié)點(diǎn) A 進(jìn)入方向的帶寬不僅包含集群通訊端口的還包含隨機(jī)端口的帶寬联贩。而對(duì)于節(jié)點(diǎn) A 進(jìn)入方向隨機(jī)端口的帶寬漫仆，正是其它節(jié)點(diǎn)出去方向的帶寬。所以每臺(tái)主機(jī)進(jìn)入方向的帶寬為上邊公式計(jì)算的加和泪幌。同理出去方帶寬與進(jìn)入方帶寬一樣為 107.5MBit / s盲厌。

cluster-node-timeout 對(duì)帶寬的影響

集群中每臺(tái)主機(jī)的帶寬狀況如下圖：

集群帶寬圖 (http://image.cnthrowable.com/upload/throwable_blog/itbroblog/blog/1468919903506_309.png)

每臺(tái)主機(jī)的進(jìn)出口帶寬都大概在 150MBit / s 左右，其中集群通信帶寬占 107.5MBit / s祸泪，所以前端請(qǐng)求的帶寬占用大概為 45MBit / s吗浩。再來(lái)看當(dāng)把 cluster-node-timeout 從 20s 調(diào)整到 30s 時(shí)，主機(jī)的帶寬變化情況：

帶寬變化 (http://image.cnthrowable.com/upload/throwable_blog/itbroblog/blog/1468920308772_304.jpg)

從圖中浴滴，可以看到帶寬下降 50MBit / s拓萌，效果非常明顯岁钓。

經(jīng)過(guò)以上實(shí)驗(yàn)我們能得出兩個(gè)結(jié)論：

集群間通信占用大量帶寬資源

調(diào)整 cluster-node-timeout 參數(shù)能有效降低帶寬

Redis Cluster 判定節(jié)點(diǎn)為 fail 的機(jī)制

但是并不是 cluster-node-timeout 越大越好升略。當(dāng) cluster-node-timeou 增大的時(shí)候集群判斷節(jié)點(diǎn) fail 的時(shí)間會(huì)增加微王，從而 failover 的時(shí)間窗口會(huì)增加。集群判定節(jié)點(diǎn)為fail所需時(shí)間的計(jì)算公式如下：

當(dāng)節(jié)點(diǎn)向失敗節(jié)點(diǎn)發(fā)出 PING 消息品嚣，并且在 cluster-node-timeout 時(shí)間內(nèi)還沒(méi)有收到失敗節(jié)點(diǎn)的 PONG 消息炕倘，此時(shí)判定它為 pfail 。pfail 即部分失敗翰撑，它是一種中間狀態(tài)罩旋，該狀態(tài)隨著集群心跳不斷傳播。再經(jīng)過(guò)一半 cluster-node-timeout 時(shí)間后眶诈，所有節(jié)點(diǎn)都與失敗的節(jié)點(diǎn)發(fā)生過(guò)心跳并且把它標(biāo)記為 pfail 涨醋。當(dāng)然也可能不需要這么長(zhǎng)時(shí)間，因?yàn)槠渌?jié)點(diǎn)之間的心跳同樣會(huì)傳遞 pfail 狀態(tài)逝撬，這里姑且以最大時(shí)間計(jì)算浴骂。

Redis Cluster 規(guī)定當(dāng)集群中超過(guò)一半以上節(jié)點(diǎn)認(rèn)為一個(gè)節(jié)點(diǎn)為 pfail 狀態(tài)時(shí)，會(huì)把它標(biāo)記為 fail 狀態(tài)宪潮，并廣播給其他所有節(jié)點(diǎn)溯警。對(duì)于每個(gè)節(jié)點(diǎn)而言平均一秒鐘收到一個(gè)心跳包，每次心跳都會(huì)攜帶隨機(jī)的十分之一的節(jié)點(diǎn)個(gè)數(shù)狡相。所以現(xiàn)在問(wèn)題抽像為經(jīng)過(guò)多長(zhǎng)時(shí)間一個(gè)節(jié)點(diǎn)會(huì)積累到一半的 pfail 狀態(tài)數(shù)梯轻。這是一個(gè)概率問(wèn)題，因?yàn)閭€(gè)人并不擅長(zhǎng)概率計(jì)算尽棕，這里直接取了一個(gè)較大概率能滿足條件的數(shù)值 10喳挑。

所以上述公式不是達(dá)到這么長(zhǎng)時(shí)間一定會(huì)判定節(jié)點(diǎn)為 fail，而是經(jīng)過(guò)這么長(zhǎng)時(shí)間集群有很大概率會(huì)判定節(jié)點(diǎn) fail 滔悉。

Redis Cluster 默認(rèn) cluster-node-timeout 為 15s蟀悦，我們將它設(shè)置成了 30s。也就是說(shuō) 700 節(jié)點(diǎn)的集群氧敢，集群間帶寬開銷為 104.5MBit / s日戈，判定節(jié)點(diǎn)失敗時(shí)間窗口大概為 55s，實(shí)際上大多數(shù)情況都小于 55s孙乖，因?yàn)樯线叺挠?jì)算都是按照高位時(shí)間估算的浙炼。

總而言之，對(duì)于大的 Redis 集群 cluster-node-timeout 參數(shù)的需要謹(jǐn)慎設(shè)定唯袄。

提高 Redis 集群吞吐的方法

2.控制主節(jié)點(diǎn)寫命令傳播

Redis 中主節(jié)點(diǎn)的每個(gè)寫命令傳播到以下三個(gè)地方：

本地 AOF 文件弯屈，以持久化持?jǐn)?shù)據(jù)

主節(jié)點(diǎn)的所有從節(jié)點(diǎn)，以保持主從數(shù)據(jù)同步

本節(jié)點(diǎn)的 repl_backlog 緩存恋拷，主要為了支持部分同步功能资厉，詳見官網(wǎng) Replcation 文檔 Partial resynchronization 部分：http://redis.io/topics/replication

其中 repl_backlog 部分傳播在 replicationFeedSlaves 函數(shù)中完成。

減少?gòu)墓?jié)點(diǎn)的數(shù)量

高可用的集群不應(yīng)該出現(xiàn)單點(diǎn)蔬顾，所以 Redis 集群一般都會(huì)是主從模式宴偿。Redis 的主從同步機(jī)制是所有的主節(jié)點(diǎn)的寫請(qǐng)求湘捎，會(huì)同步到所有的從節(jié)點(diǎn)。如果沒(méi)有從節(jié)點(diǎn)窄刘，對(duì)于主節(jié)點(diǎn)來(lái)說(shuō)窥妇，它只需要處理該請(qǐng)求即可。但對(duì)于有 N 個(gè)從節(jié)點(diǎn)的主節(jié)點(diǎn)來(lái)說(shuō)娩践，它需要額外的將請(qǐng)求傳播給 N 個(gè)從節(jié)點(diǎn)活翩。請(qǐng)注意這里是對(duì)于每個(gè)寫請(qǐng)求都會(huì)這樣處理。顯而易見從節(jié)點(diǎn)的數(shù)量對(duì)主節(jié)點(diǎn)的吞吐量的影響是比較大的翻伺，我們采用的是一主一從模式材泄。

因?yàn)閺墓?jié)點(diǎn)不需要同步數(shù)據(jù)，生產(chǎn)環(huán)境中觀察主節(jié)點(diǎn)的 CPU 占用率要比從節(jié)點(diǎn)機(jī)器要高吨岭，這對(duì)這條結(jié)論起到了佐證的作用脸爱。

關(guān)閉 AOF 功能

如果開啟 AOF 功能，每個(gè)寫請(qǐng)求都會(huì) Append 到本地 AOF 文件中未妹，雖然 Linux 中寫文件操作會(huì)利用到操作系統(tǒng)緩存機(jī)制簿废，但是如果關(guān)閉 AOF 功能主線程中省去了寫 AOF 文件的操作，顯然會(huì)對(duì)吞吐量的增加有幫助络它。

AOF 是 Redis 的一種持久化方式族檬，如果關(guān)閉了 AOF 功能怎么保證數(shù)據(jù)的安全性。我們的做法是定時(shí)在從節(jié)點(diǎn) BGSAVE化戳。當(dāng)然具體采用何種策略需要結(jié)合具體情況來(lái)決定单料。

去掉頻繁的 Cluster nodes 命令

在運(yùn)維過(guò)程中發(fā)現(xiàn)前端請(qǐng)求的平均 RT 增加不少，大概 50% 左右点楼。通過(guò)一番調(diào)研扫尖，發(fā)現(xiàn)是頻繁的 cluster nodes 命令導(dǎo)致。

當(dāng)時(shí)集群規(guī)模為 500+ 節(jié)點(diǎn)掠廓，cluster nodes 命令返回的結(jié)果大小有 103KB换怖。cluster nodes 命令的頻率為：每隔 20s 向集群所有節(jié)點(diǎn)發(fā)送。

提高 Redis 集群吞吐的方法

3.調(diào)優(yōu) hz 參數(shù)

Redis 會(huì)定時(shí)做一些任務(wù)蟀瞧，任務(wù)頻率由 hz 參數(shù)規(guī)定沉颂，定時(shí)任務(wù)主要包含：

主動(dòng)清除過(guò)期數(shù)據(jù)

對(duì)數(shù)據(jù)庫(kù)進(jìn)行漸式Rehash

處理客戶端超時(shí)

更新請(qǐng)求統(tǒng)計(jì)信息

發(fā)送集群心跳包

發(fā)送主從心跳

以下是作者對(duì)于 hz 參數(shù)的介紹：

我們沒(méi)有修改 hz 參數(shù)的經(jīng)驗(yàn)，由于其復(fù)雜性悦污，并且在 hz 默認(rèn)值 10 的情況下铸屉，理論上不會(huì)對(duì) Redis 吞吐量產(chǎn)生太大影響，建議沒(méi)有經(jīng)驗(yàn)的情況下不要修改該參數(shù)切端。

參考資料

關(guān)于 Redis Cluster 可以參考官方的兩篇文檔：

Redis cluster tutorial:http://www.redis.io/topics/cluster-tutorial

Redis Cluster specification:http://www.redis.io/topics/cluster-spec

相關(guān)閱讀

用最少的機(jī)器支撐萬(wàn)億級(jí)訪問(wèn)彻坛，微博6年Redis優(yōu)化歷程

首發(fā)丨360開源的類Redis存儲(chǔ)系統(tǒng):Pika

Redis實(shí)戰(zhàn)：如何構(gòu)建類微博的億級(jí)社交平臺(tái)

Codis作者黃東旭細(xì)說(shuō)分布式Redis架構(gòu)設(shè)計(jì)和踩過(guò)的那些坑

想了解更多 Redis 及 NoSQL 內(nèi)容，請(qǐng)關(guān)注「ArchNotes」微信公眾號(hào)以閱讀后續(xù)文章。轉(zhuǎn)載請(qǐng)注明來(lái)自高可用架構(gòu)及包含以下二維碼昌屉。