在優(yōu)酷，我們使用 Redis Cluster 構(gòu)建了一套內(nèi)存存儲(chǔ)系統(tǒng)，項(xiàng)目代號(hào)為藍(lán)鯨。藍(lán)鯨的設(shè)計(jì)目標(biāo)是高效讀寫(xiě)，所有數(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ì)大家有所幫助。
1 - 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 的單進(jìn)程模型與主要負(fù)載情況，很容易明白，想要增加 Redis 吞吐量，只需要盡量降低其它任務(wù)的負(fù)載量就行了，所以提高 Redis 集群吞吐量的方式主要有：
A) - 提高 Redis 集群吞吐的方法
- 適當(dāng)調(diào)大
cluster-node-timeout參數(shù)
我們發(fā)現(xiàn)當(dāng)集群規(guī)模達(dá)到一定程度時(shí)，集群間消息通訊開(kāi)銷的帶寬是極其可觀的。
集群通信機(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 。
總結(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)見(jiàn)下邊代碼：
我們將注意力放在數(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)生的帶寬開(kāi)銷。實(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ī)的每秒帶寬為：
經(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)的集群，集群間帶寬開(kāi)銷為 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 集群吞吐的方法
- 控制主節(jié)點(diǎn)寫(xiě)命令傳播
Redis 中主節(jié)點(diǎn)的每個(gè)寫(xiě)命令傳播到以下三個(gè)地方：
本地 AOF 文件，以持久化持?jǐn)?shù)據(jù)
主節(jié)點(diǎn)的所有從節(jié)點(diǎn)，以保持主從數(shù)據(jù)同步
本節(jié)點(diǎn)的 repl_backlog 緩存，主要為了支持部分同步功能，詳見(jiàn)官網(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)的寫(xiě)請(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è)寫(xiě)請(qǐng)求都會(huì)這樣處理。顯而易見(jiàn)從節(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 功能
如果開(kāi)啟 AOF 功能，每個(gè)寫(xiě)請(qǐng)求都會(huì) Append 到本地 AOF 文件中，雖然 Linux 中寫(xiě)文件操作會(huì)利用到操作系統(tǒng)緩存機(jī)制，但是如果關(guān)閉 AOF 功能主線程中省去了寫(xiě) 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 集群吞吐的方法
- 調(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
