本文來(lái)自知乎官方技術(shù)團(tuán)隊(duì)的“知乎技術(shù)專欄”，感謝原作者陳鵬的無(wú)私分享。

1、引言

知乎存儲(chǔ)平臺(tái)團(tuán)隊(duì)基于開(kāi)源Redis 組件打造的知乎 Redis 平臺(tái)，經(jīng)過(guò)不斷的研發(fā)迭代，目前已經(jīng)形成了一整套完整自動(dòng)化運(yùn)維服務(wù)體系，提供很多強(qiáng)大的功能。本文作者陳鵬是該系統(tǒng)的負(fù)責(zé)人，本次文章深入介紹了該系統(tǒng)的方方面面，值得互聯(lián)網(wǎng)后端程序員仔細(xì)研究。

（本文同步發(fā)布于：http://www.52im.net/thread-1968-1-1.html）

2、關(guān)于作者

陳鵬：現(xiàn)任知乎存儲(chǔ)平臺(tái)組 Redis 平臺(tái)技術(shù)負(fù)責(zé)人，2014 年加入知乎技術(shù)平臺(tái)組從事基礎(chǔ)架構(gòu)相關(guān)系統(tǒng)的開(kāi)發(fā)與運(yùn)維，從無(wú)到有建立了知乎 Redis 平臺(tái)，承載了知乎高速增長(zhǎng)的業(yè)務(wù)流量。

3、技術(shù)背景

知乎作為知名中文知識(shí)內(nèi)容平臺(tái)，每日處理的訪問(wèn)量巨大 ，如何更好的承載這樣巨大的訪問(wèn)量，同時(shí)提供穩(wěn)定低時(shí)延的服務(wù)保證，是知乎技術(shù)平臺(tái)同學(xué)需要面對(duì)的一大挑戰(zhàn)。

知乎存儲(chǔ)平臺(tái)團(tuán)隊(duì)基于開(kāi)源 Redis 組件打造的 Redis 平臺(tái)管理系統(tǒng)，經(jīng)過(guò)不斷的研發(fā)迭代，目前已經(jīng)形成了一整套完整自動(dòng)化運(yùn)維服務(wù)體系，提供一鍵部署集群，一鍵自動(dòng)擴(kuò)縮容, Redis 超細(xì)粒度監(jiān)控，旁路流量分析等輔助功能。

目前，Redis 在知乎的應(yīng)用規(guī)模如下：

1）機(jī)器內(nèi)存總量約 70TB，實(shí)際使用內(nèi)存約 40TB；

2）平均每秒處理約 1500 萬(wàn)次請(qǐng)求，峰值每秒約 2000 萬(wàn)次請(qǐng)求；

3）每天處理約 1 萬(wàn)億余次請(qǐng)求；

4）單集群每秒處理最高每秒約 400 萬(wàn)次請(qǐng)求；

5）集群實(shí)例與單機(jī)實(shí)例總共約 800 個(gè)；

6）實(shí)際運(yùn)行約 16000 個(gè) Redis 實(shí)例；

7）Redis 使用官方 3.0.7 版本，少部分實(shí)例采用 4.0.11 版本。

4、知乎的Redis應(yīng)用類型

根據(jù)業(yè)務(wù)的需求，我們將Redis實(shí)例區(qū)分為單機(jī)（Standalone）和集群（Cluster）兩種類型，單機(jī)實(shí)例通常用于容量與性能要求不高的小型存儲(chǔ)，而集群則用來(lái)應(yīng)對(duì)對(duì)性能和容量要求較高的場(chǎng)景。

而在集群（Cluster）實(shí)例類型中，當(dāng)實(shí)例需要的容量超過(guò) 20G 或要求的吞吐量超過(guò) 20萬(wàn)請(qǐng)求每秒時(shí)，我們會(huì)使用集群（Cluster）實(shí)例來(lái)承擔(dān)流量。集群是通過(guò)中間件（客戶端或中間代理等）將流量分散到多個(gè) Redis 實(shí)例上的解決方案。知乎的 Redis 集群方案經(jīng)歷了兩個(gè)階段：客戶端分片（2015年前使用的方案）與 Twemproxy 代理（2015年至今使用的方案）。

下面將分別來(lái)介紹這兩個(gè)類型的Redis實(shí)例在知乎的應(yīng)用實(shí)踐情況。

5、知乎的Redis實(shí)例應(yīng)用類型1：?jiǎn)螜C(jī)（Standalone）

對(duì)于單機(jī)實(shí)例，我們采用原生主從（Master-Slave）模式實(shí)現(xiàn)高可用，常規(guī)模式下對(duì)外僅暴露 Master 節(jié)點(diǎn)。由于使用原生 Redis，所以單機(jī)實(shí)例支持所有 Redis 指令。

對(duì)于單機(jī)實(shí)例，我們使用 Redis 自帶的哨兵（Sentinel）集群對(duì)實(shí)例進(jìn)行狀態(tài)監(jiān)控與 Failover。Sentinel 是 Redis 自帶的高可用組件，將 Redis 注冊(cè)到由多個(gè) Sentinel 組成的 Sentinel 集群后，Sentinel 會(huì)對(duì) Redis 實(shí)例進(jìn)行健康檢查，當(dāng) Redis 發(fā)生故障后，Sentinel 會(huì)通過(guò) Gossip 協(xié)議進(jìn)行故障檢測(cè)，確認(rèn)宕機(jī)后會(huì)通過(guò)一個(gè)簡(jiǎn)化的 Raft 協(xié)議來(lái)提升 Slave 成為新的 Master。

通常情況我們僅使用 1 個(gè) Slave 節(jié)點(diǎn)進(jìn)行冷備，如果有讀寫分離請(qǐng)求，可以建立多個(gè) Read only slave 來(lái)進(jìn)行讀寫分離。

如上圖所示，通過(guò)向 Sentinel 集群注冊(cè) Master 節(jié)點(diǎn)實(shí)現(xiàn)實(shí)例的高可用，當(dāng)提交 Master 實(shí)例的連接信息后，Sentinel 會(huì)主動(dòng)探測(cè)所有的 Slave 實(shí)例并建立連接，定期檢查健康狀態(tài)。客戶端通過(guò)多種資源發(fā)現(xiàn)策略如簡(jiǎn)單的 DNS 發(fā)現(xiàn) Master 節(jié)點(diǎn)，將來(lái)有計(jì)劃遷移到如 Consul 或 etcd 等資源發(fā)現(xiàn)組件 。

當(dāng) Master 節(jié)點(diǎn)發(fā)生宕機(jī)時(shí)，Sentinel 集群會(huì)提升 Slave 節(jié)點(diǎn)為新的 Master，同時(shí)在自身的 pubsub channel +switch-master 廣播切換的消息，具體消息格式為：

switch-master <master name> <oldip> <oldport> <newip> <newport>

watcher 監(jiān)聽(tīng)到消息后，會(huì)去主動(dòng)更新資源發(fā)現(xiàn)策略，將客戶端連接指向新的 Master 節(jié)點(diǎn)，完成 Failover，具體 Failover 切換過(guò)程詳見(jiàn) Redis 官方文檔（Redis Sentinel Documentation - Redis）。

實(shí)際使用中需要注意以下幾點(diǎn)：

1）只讀 Slave 節(jié)點(diǎn)可以按照需求設(shè)置 slave-priority 參數(shù)為 0，防止故障切換時(shí)選擇了只讀節(jié)點(diǎn)而不是熱備 Slave 節(jié)點(diǎn)；

2）Sentinel 進(jìn)行故障切換后會(huì)執(zhí)行 CONFIG REWRITE 命令將 SLAVEOF 配置落地，如果 Redis 配置中禁用了 CONFIG 命令，切換時(shí)會(huì)發(fā)生錯(cuò)誤，可以通過(guò)修改 Sentinel 代碼來(lái)替換 CONFIG 命令；

3）Sentinel Group 監(jiān)控的節(jié)點(diǎn)不宜過(guò)多，實(shí)測(cè)超過(guò) 500 個(gè)切換過(guò)程偶爾會(huì)進(jìn)入 TILT 模式，導(dǎo)致 Sentinel 工作不正常，推薦部署多個(gè) Sentinel 集群并保證每個(gè)集群監(jiān)控的實(shí)例數(shù)量小于 300 個(gè)；

4）Master 節(jié)點(diǎn)應(yīng)與 Slave 節(jié)點(diǎn)跨機(jī)器部署，有能力的使用方可以跨機(jī)架部署，不推薦跨機(jī)房部署 Redis 主從實(shí)例；

5）Sentinel 切換功能主要依賴 down-after-milliseconds 和 failover-timeout 兩個(gè)參數(shù)，down-after-milliseconds 決定了 Sentinel 判斷 Redis 節(jié)點(diǎn)宕機(jī)的超時(shí)，知乎使用 30000 作為閾值。而 failover-timeout 則決定了兩次切換之間的最短等待時(shí)間，如果對(duì)于切換成功率要求較高，可以適當(dāng)縮短 failover-timeout 到秒級(jí)保證切換成功，具體詳見(jiàn) Redis 官方文檔；

6）單機(jī)網(wǎng)絡(luò)故障等同于機(jī)器宕機(jī)，但如果機(jī)房全網(wǎng)發(fā)生大規(guī)模故障會(huì)造成主從多次切換，此時(shí)資源發(fā)現(xiàn)服務(wù)可能更新不夠及時(shí)，需要人工介入。

6、知乎的Redis實(shí)例應(yīng)用類型2：集群之客戶端分片方案（2015以前使用）

早期知乎使用 redis-shard 進(jìn)行客戶端分片，redis-shard 庫(kù)內(nèi)部實(shí)現(xiàn)了 CRC32、MD5、SHA1 三種哈希算法 ，支持絕大部分 Redis 命令。使用者只需把 redis-shard 當(dāng)成原生客戶端使用即可，無(wú)需關(guān)注底層分片。

基于客戶端的分片模式具有如下優(yōu)點(diǎn)：

1）基于客戶端分片的方案是集群方案中最快的，沒(méi)有中間件，僅需要客戶端進(jìn)行一次哈希計(jì)算，不需要經(jīng)過(guò)代理，沒(méi)有官方集群方案的 MOVED/ASK 轉(zhuǎn)向；

2）不需要多余的 Proxy 機(jī)器，不用考慮 Proxy 部署與維護(hù)；

3）可以自定義更適合生產(chǎn)環(huán)境的哈希算法。

但是也存在如下問(wèn)題：

1）需要每種語(yǔ)言都實(shí)現(xiàn)一遍客戶端邏輯，早期知乎全站使用 Python 進(jìn)行開(kāi)發(fā)，但是后來(lái)業(yè)務(wù)線增多，使用的語(yǔ)言增加至 Python，Golang，Lua，C/C++，JVM 系（Java，Scala，Kotlin）等，維護(hù)成本過(guò)高；

2）無(wú)法正常使用 MSET、MGET 等多種同時(shí)操作多個(gè) Key 的命令，需要使用 Hash tag 來(lái)保證多個(gè) Key 在同一個(gè)分片上；

3）升級(jí)麻煩，升級(jí)客戶端需要所有業(yè)務(wù)升級(jí)更新重啟，業(yè)務(wù)規(guī)模變大后無(wú)法推動(dòng)；

4）擴(kuò)容困難，存儲(chǔ)需要停機(jī)使用腳本 Scan 所有的 Key 進(jìn)行遷移，緩存只能通過(guò)傳統(tǒng)的翻倍取模方式進(jìn)行擴(kuò)容；

5）由于每個(gè)客戶端都要與所有的分片建立池化連接，客戶端基數(shù)過(guò)大時(shí)會(huì)造成 Redis 端連接數(shù)過(guò)多，Redis 分片過(guò)多時(shí)會(huì)造成 Python 客戶端負(fù)載升高。

具體特點(diǎn)詳見(jiàn)：https://github.com/zhihu/redis-shard

早期知乎大部分業(yè)務(wù)由 Python 構(gòu)建，Redis 使用的容量波動(dòng)較小， redis-shard 很好地應(yīng)對(duì)了這個(gè)時(shí)期的業(yè)務(wù)需求，在當(dāng)時(shí)是一個(gè)較為不錯(cuò)解決方案。

7、知乎的Redis實(shí)例應(yīng)用類型2：集群之Twemproxy 集群方案（2015之今在用）

2015 年開(kāi)始，業(yè)務(wù)上漲迅猛，Redis 需求暴增，原有的 redis-shard 模式已經(jīng)無(wú)法滿足日益增長(zhǎng)的擴(kuò)容需求，我們開(kāi)始調(diào)研多種集群方案，最終選擇了簡(jiǎn)單高效的 Twemproxy 作為我們的集群方案。

由 Twitter 開(kāi)源的 Twemproxy 具有如下優(yōu)點(diǎn)：

1）性能很好且足夠穩(wěn)定，自建內(nèi)存池實(shí)現(xiàn) Buffer 復(fù)用，代碼質(zhì)量很高；

2）支持 fnv1a_64、murmur、md5 等多種哈希算法；

3）支持一致性哈希（ketama），取模哈希（modula）和隨機(jī)（random）三種分布式算法。

具體特點(diǎn)詳見(jiàn)：https://github.com/twitter/twemproxy

但是缺點(diǎn)也很明顯：

1）單核模型造成性能瓶頸；

2）傳統(tǒng)擴(kuò)容模式僅支持停機(jī)擴(kuò)容。

對(duì)此，我們將集群實(shí)例分成兩種模式，即緩存（Cache）和存儲(chǔ)（Storage）：

如果使用方可以接收通過(guò)損失一部分少量數(shù)據(jù)來(lái)保證可用性，或使用方可以從其余存儲(chǔ)恢復(fù)實(shí)例中的數(shù)據(jù)，這種實(shí)例即為緩存，其余情況均為存儲(chǔ)。

我們對(duì)緩存和存儲(chǔ)采用了不同的策略，請(qǐng)繼續(xù)往下讀。

7.1 存儲(chǔ)

對(duì)于存儲(chǔ)我們使用 fnv1a_64 算法結(jié)合 modula 模式即取模哈希對(duì) Key 進(jìn)行分片，底層 Redis 使用單機(jī)模式結(jié)合 Sentinel 集群實(shí)現(xiàn)高可用，默認(rèn)使用 1 個(gè) Master 節(jié)點(diǎn)和 1 個(gè) Slave 節(jié)點(diǎn)提供服務(wù)，如果業(yè)務(wù)有更高的可用性要求，可以拓展 Slave 節(jié)點(diǎn)。

當(dāng)集群中 Master 節(jié)點(diǎn)宕機(jī)，按照單機(jī)模式下的高可用流程進(jìn)行切換，Twemproxy 在連接斷開(kāi)后會(huì)進(jìn)行重連，對(duì)于存儲(chǔ)模式下的集群，我們不會(huì)設(shè)置 auto_eject_hosts, 不會(huì)剔除節(jié)點(diǎn)。

同時(shí)，對(duì)于存儲(chǔ)實(shí)例，我們默認(rèn)使用 noeviction 策略，在內(nèi)存使用超過(guò)規(guī)定的額度時(shí)直接返回 OOM 錯(cuò)誤，不會(huì)主動(dòng)進(jìn)行 Key 的刪除，保證數(shù)據(jù)的完整性。

由于 Twemproxy 僅進(jìn)行高性能的命令轉(zhuǎn)發(fā)，不進(jìn)行讀寫分離，所以默認(rèn)沒(méi)有讀寫分離功能，而在實(shí)際使用過(guò)程中，我們也沒(méi)有遇到集群讀寫分離的需求，如果要進(jìn)行讀寫分離，可以使用資源發(fā)現(xiàn)策略在 Slave 節(jié)點(diǎn)上架設(shè) Twemproxy 集群，由客戶端進(jìn)行讀寫分離的路由。

7.2 緩存

考慮到對(duì)于后端（MySQL/HBase/RPC 等）的壓力，知乎絕大部分業(yè)務(wù)都沒(méi)有針對(duì)緩存進(jìn)行降級(jí)，這種情況下對(duì)緩存的可用性要求較數(shù)據(jù)的一致性要求更高，但是如果按照存儲(chǔ)的主從模式實(shí)現(xiàn)高可用，1 個(gè) Slave 節(jié)點(diǎn)的部署策略在線上環(huán)境只能容忍 1 臺(tái)物理節(jié)點(diǎn)宕機(jī)，N 臺(tái)物理節(jié)點(diǎn)宕機(jī)高可用就需要至少 N 個(gè) Slave 節(jié)點(diǎn)，這無(wú)疑是種資源的浪費(fèi)。

所以我們采用了 Twemproxy 一致性哈希（Consistent Hashing）策略來(lái)配合 auto_eject_hosts 自動(dòng)彈出策略組建 Redis 緩存集群。

對(duì)于緩存我們?nèi)匀皇褂檬褂?fnv1a_64 算法進(jìn)行哈希計(jì)算，但是分布算法我們使用了 ketama 即一致性哈希進(jìn)行 Key 分布。緩存節(jié)點(diǎn)沒(méi)有主從，每個(gè)分片僅有 1 個(gè) Master 節(jié)點(diǎn)承載流量。

Twemproxy 配置 auto_eject_hosts 會(huì)在實(shí)例連接失敗超過(guò) server_failure_limit 次的情況下剔除節(jié)點(diǎn)，并在 server_retry_timeout 超時(shí)之后進(jìn)行重試，剔除后配合 ketama 一致性哈希算法重新計(jì)算哈希環(huán)，恢復(fù)正常使用，這樣即使一次宕機(jī)多個(gè)物理節(jié)點(diǎn)仍然能保持服務(wù)。

在實(shí)際的生產(chǎn)環(huán)境中需要注意以下幾點(diǎn)：

1）剔除節(jié)點(diǎn)后，會(huì)造成短時(shí)間的命中率下降，后端存儲(chǔ)如 MySQL、HBase 等需要做好流量監(jiān)測(cè)；

2）線上環(huán)境緩存后端分片不宜過(guò)大，建議維持在 20G 以內(nèi)，同時(shí)分片調(diào)度應(yīng)盡可能分散，這樣即使宕機(jī)一部分節(jié)點(diǎn)，對(duì)后端造成的額外的壓力也不會(huì)太多；

3）機(jī)器宕機(jī)重啟后，緩存實(shí)例需要清空數(shù)據(jù)之后啟動(dòng)，否則原有的緩存數(shù)據(jù)和新建立的緩存數(shù)據(jù)會(huì)沖突導(dǎo)致臟緩存。直接不啟動(dòng)緩存也是一種方法，但是在分片宕機(jī)期間會(huì)導(dǎo)致周期性 server_failure_limit 次數(shù)的連接失敗；

4）server_retry_timeout 和 server_failure_limit 需要仔細(xì)敲定確認(rèn)，知乎使用 10min 和 3 次作為配置，即連接失敗 3 次后剔除節(jié)點(diǎn)，10 分鐘后重新進(jìn)行連接。

7.3 Twemproxy 部署

在方案早期我們使用數(shù)量固定的物理機(jī)部署 Twemproxy，通過(guò)物理機(jī)上的 Agent 啟動(dòng)實(shí)例，Agent 在運(yùn)行期間會(huì)對(duì) Twemproxy 進(jìn)行健康檢查與故障恢復(fù)，由于 Twemproxy 僅提供全量的使用計(jì)數(shù)，所以 Agent 運(yùn)行時(shí)還會(huì)進(jìn)行定時(shí)的差值計(jì)算來(lái)計(jì)算 Twemproxy 的 requests_per_second 等指標(biāo)。

后來(lái)為了更好地故障檢測(cè)和資源調(diào)度，我們引入了 Kubernetes，將 Twemproxy 和 Agent 放入同一個(gè) Pod 的兩個(gè)容器內(nèi)，底層 Docker 網(wǎng)段的配置使每個(gè) Pod 都能獲得獨(dú)立的 IP，方便管理。

最開(kāi)始，本著簡(jiǎn)單易用的原則，我們使用 DNS A Record 來(lái)進(jìn)行客戶端的資源發(fā)現(xiàn)，每個(gè) Twemproxy 采用相同的端口號(hào)，一個(gè) DNS A Record 后面掛接多個(gè) IP 地址對(duì)應(yīng)多個(gè) Twemproxy 實(shí)例。

初期，這種方案簡(jiǎn)單易用，但是到了后期流量日益上漲，單集群 Twemproxy 實(shí)例個(gè)數(shù)很快就超過(guò)了 20 個(gè)。由于 DNS 采用的 UDP 協(xié)議有 512 字節(jié)的包大小限制，單個(gè) A Record 只能掛接 20 個(gè)左右的 IP 地址，超過(guò)這個(gè)數(shù)字就會(huì)轉(zhuǎn)換為 TCP 協(xié)議，客戶端不做處理就會(huì)報(bào)錯(cuò)，導(dǎo)致客戶端啟動(dòng)失敗。

當(dāng)時(shí)由于情況緊急，只能建立多個(gè) Twemproxy Group，提供多個(gè) DNS A Record 給客戶端，客戶端進(jìn)行輪詢或者隨機(jī)選擇，該方案可用，但是不夠優(yōu)雅。

7.4 如何解決 Twemproxy 單 CPU 計(jì)算能力的限制

之后我們修改了 Twemproxy 源碼， 加入 SO_REUSEPORT 支持。

Twemproxy with SO_REUSEPORT on Kubernetes：

同一個(gè)容器內(nèi)由 Starter 啟動(dòng)多個(gè) Twemproxy 實(shí)例并綁定到同一個(gè)端口，由操作系統(tǒng)進(jìn)行負(fù)載均衡，對(duì)外仍然暴露一個(gè)端口，但是內(nèi)部已經(jīng)由系統(tǒng)均攤到了多個(gè) Twemproxy 上。

同時(shí) Starter 會(huì)定時(shí)去每個(gè) Twemproxy 的 stats 端口獲取 Twemproxy 運(yùn)行狀態(tài)進(jìn)行聚合，此外 Starter 還承載了信號(hào)轉(zhuǎn)發(fā)的職責(zé)。

原有的 Agent 不需要用來(lái)啟動(dòng) Twemproxy 實(shí)例，所以 Monitor 調(diào)用 Starter 獲取聚合后的 stats 信息進(jìn)行差值計(jì)算，最終對(duì)外界暴露出實(shí)時(shí)的運(yùn)行狀態(tài)信息。

7.5 為什么沒(méi)有使用官方 Redis 集群方案

我們?cè)?2015 年調(diào)研過(guò)多種集群方案，綜合評(píng)估多種方案后，最終選擇了看起來(lái)較為陳舊的 Twemproxy 而不是官方 Redis 集群方案與 Codis，具體原因如下：

1）MIGRATE 造成的阻塞問(wèn)題：

Redis 官方集群方案使用 CRC16 算法計(jì)算哈希值并將 Key 分散到 16384 個(gè) Slot 中，由使用方自行分配 Slot 對(duì)應(yīng)到每個(gè)分片中，擴(kuò)容時(shí)由使用方自行選擇 Slot 并對(duì)其進(jìn)行遍歷，對(duì) Slot 中每一個(gè) Key 執(zhí)行 MIGRATE 命令進(jìn)行遷移。

調(diào)研后發(fā)現(xiàn)，MIGRATE 命令實(shí)現(xiàn)分為三個(gè)階段：

a）DUMP 階段：由源實(shí)例遍歷對(duì)應(yīng) Key 的內(nèi)存空間，將 Key 對(duì)應(yīng)的 Redis Object 序列化，序列化協(xié)議跟 Redis RDB 過(guò)程一致；

b）RESTORE 階段：由源實(shí)例建立 TCP 連接到對(duì)端實(shí)例，并將 DUMP 出來(lái)的內(nèi)容使用 RESTORE 命令到對(duì)端進(jìn)行重建，新版本的 Redis 會(huì)緩存對(duì)端實(shí)例的連接；

c）DEL 階段（可選）：如果發(fā)生遷移失敗，可能會(huì)造成同名的 Key 同時(shí)存在于兩個(gè)節(jié)點(diǎn)，此時(shí) MIGRATE 的 REPLACE 參數(shù)決定是是否覆蓋對(duì)端的同名 Key，如果覆蓋，對(duì)端的 Key 會(huì)進(jìn)行一次刪除操作，4.0 版本之后刪除可以異步進(jìn)行，不會(huì)阻塞主進(jìn)程。

經(jīng)過(guò)調(diào)研，我們認(rèn)為這種模式并不適合知乎的生產(chǎn)環(huán)境。Redis 為了保證遷移的一致性， MIGRATE 所有操作都是同步操作，執(zhí)行 MIGRATE 時(shí)，兩端的 Redis 均會(huì)進(jìn)入時(shí)長(zhǎng)不等的 BLOCK 狀態(tài)。

對(duì)于小 Key，該時(shí)間可以忽略不計(jì)，但如果一旦 Key 的內(nèi)存使用過(guò)大，一個(gè) MIGRATE 命令輕則導(dǎo)致 P95 尖刺，重則直接觸發(fā)集群內(nèi)的 Failover，造成不必要的切換

同時(shí)，遷移過(guò)程中訪問(wèn)到處于遷移中間狀態(tài)的 Slot 的 Key 時(shí)，根據(jù)進(jìn)度可能會(huì)產(chǎn)生 ASK 轉(zhuǎn)向，此時(shí)需要客戶端發(fā)送 ASKING 命令到 Slot 所在的另一個(gè)分片重新請(qǐng)求，請(qǐng)求時(shí)延則會(huì)變?yōu)樵瓉?lái)的兩倍。

同樣，方案初期時(shí)的 Codis 采用的是相同的 MIGRATE 方案，但是使用 Proxy 控制 Redis 進(jìn)行遷移操作而非第三方腳本（如 redis-trib.rb），基于同步的類似 MIGRATE 的命令，實(shí)際跟 Redis 官方集群方案存在同樣的問(wèn)題。

對(duì)于這種 Huge Key 問(wèn)題決定權(quán)完全在于業(yè)務(wù)方，有時(shí)業(yè)務(wù)需要不得不產(chǎn)生 Huge Key 時(shí)會(huì)十分尷尬，如關(guān)注列表。一旦業(yè)務(wù)使用不當(dāng)出現(xiàn)超過(guò) 1MB 以上的大 Key 便會(huì)導(dǎo)致數(shù)十毫秒的延遲，遠(yuǎn)高于平時(shí) Redis 亞毫秒級(jí)的延遲。有時(shí)，在 slot 遷移過(guò)程中業(yè)務(wù)不慎同時(shí)寫入了多個(gè)巨大的 Key 到 slot 遷移的源節(jié)點(diǎn)和目標(biāo)節(jié)點(diǎn)，除非寫腳本刪除這些 Key ，否則遷移會(huì)進(jìn)入進(jìn)退兩難的地步。

對(duì)此，Redis 作者在 Redis 4.2 的 roadmap 中提到了 Non blocking MIGRATE 但是截至目前，Redis 5.0 即將正式發(fā)布，仍未看到有關(guān)改動(dòng)，社區(qū)中已經(jīng)有相關(guān)的 Pull Request ，該功能可能會(huì)在 5.2 或者 6.0 之后并入 master 分支，對(duì)此我們將持續(xù)觀望。

2）緩存模式下高可用方案不夠靈活：

還有，官方集群方案的高可用策略僅有主從一種，高可用級(jí)別跟 Slave 的數(shù)量成正相關(guān)，如果只有一個(gè) Slave，則只能允許一臺(tái)物理機(jī)器宕機(jī)， Redis 4.2 roadmap 提到了 cache-only mode，提供類似于 Twemproxy 的自動(dòng)剔除后重分片策略，但是截至目前仍未實(shí)現(xiàn)。

3）內(nèi)置 Sentinel 造成額外流量負(fù)載：

另外，官方 Redis 集群方案將 Sentinel 功能內(nèi)置到 Redis 內(nèi)，這導(dǎo)致在節(jié)點(diǎn)數(shù)較多（大于 100）時(shí)在 Gossip 階段會(huì)產(chǎn)生大量的 PING/INFO/CLUSTER INFO 流量，根據(jù) issue 中提到的情況，200 個(gè)使用 3.2.8 版本節(jié)點(diǎn)搭建的 Redis 集群，在沒(méi)有任何客戶端請(qǐng)求的情況下，每個(gè)節(jié)點(diǎn)仍然會(huì)產(chǎn)生 40Mb/s 的流量，雖然到后期 Redis 官方嘗試對(duì)其進(jìn)行壓縮修復(fù)，但按照 Redis 集群機(jī)制，節(jié)點(diǎn)較多的情況下無(wú)論如何都會(huì)產(chǎn)生這部分流量，對(duì)于使用大內(nèi)存機(jī)器但是使用千兆網(wǎng)卡的用戶這是一個(gè)值得注意的地方。

4）slot 存儲(chǔ)開(kāi)銷：

最后，每個(gè) Key 對(duì)應(yīng)的 Slot 的存儲(chǔ)開(kāi)銷，在規(guī)模較大的時(shí)候會(huì)占用較多內(nèi)存，4.x 版本以前甚至?xí)_(dá)到實(shí)際使用內(nèi)存的數(shù)倍，雖然 4.x 版本使用 rax 結(jié)構(gòu)進(jìn)行存儲(chǔ)，但是仍然占據(jù)了大量?jī)?nèi)存，從非官方集群方案遷移到官方集群方案時(shí)，需要注意這部分多出來(lái)的內(nèi)存。

總之，官方 Redis 集群方案與 Codis 方案對(duì)于絕大多數(shù)場(chǎng)景來(lái)說(shuō)都是非常優(yōu)秀的解決方案，但是我們仔細(xì)調(diào)研發(fā)現(xiàn)并不是很適合集群數(shù)量較多且使用方式多樣化的我們，場(chǎng)景不同側(cè)重點(diǎn)也會(huì)不一樣，但在此仍然要感謝開(kāi)發(fā)這些組件的開(kāi)發(fā)者們，感謝你們對(duì) Redis 社區(qū)的貢獻(xiàn)。

8、知乎Redis實(shí)例的擴(kuò)容實(shí)踐

8.1 靜態(tài)擴(kuò)容

對(duì)于單機(jī)實(shí)例，如果通過(guò)調(diào)度器觀察到對(duì)應(yīng)的機(jī)器仍然有空閑的內(nèi)存，我們僅需直接調(diào)整實(shí)例的 maxmemory 配置與報(bào)警即可。同樣，對(duì)于集群實(shí)例，我們通過(guò)調(diào)度器觀察每個(gè)節(jié)點(diǎn)所在的機(jī)器，如果所有節(jié)點(diǎn)所在機(jī)器均有空閑內(nèi)存，我們會(huì)像擴(kuò)容單機(jī)實(shí)例一樣直接更新 maxmemory 與報(bào)警。

8.2 動(dòng)態(tài)擴(kuò)容

但是當(dāng)機(jī)器空閑內(nèi)存不夠，或單機(jī)實(shí)例與集群的后端實(shí)例過(guò)大時(shí)，無(wú)法直接擴(kuò)容，需要進(jìn)行動(dòng)態(tài)擴(kuò)容：

1）對(duì)于單機(jī)實(shí)例，如果單實(shí)例超過(guò) 30GB 且沒(méi)有如 sinterstore 之類的多 Key 操作我們會(huì)將其擴(kuò)容為集群實(shí)例；

2）對(duì)于集群實(shí)例，我們會(huì)進(jìn)行橫向的重分片，我們稱之為 Resharding 過(guò)程。

Resharding 過(guò)程：

原生 Twemproxy 集群方案并不支持?jǐn)U容，我們開(kāi)發(fā)了數(shù)據(jù)遷移工具來(lái)進(jìn)行 Twemproxy 的擴(kuò)容，遷移工具本質(zhì)上是一個(gè)上下游之間的代理，將數(shù)據(jù)從上游按照新的分片方式搬運(yùn)到下游。

原生 Redis 主從同步使用 SYNC/PSYNC 命令建立主從連接，收到 SYNC 命令的 Master 會(huì) fork 出一個(gè)進(jìn)程遍歷內(nèi)存空間生成 RDB 文件并發(fā)送給 Slave，期間所有發(fā)送至 Master 的寫命令在執(zhí)行的同時(shí)都會(huì)被緩存到內(nèi)存的緩沖區(qū)內(nèi)，當(dāng) RDB 發(fā)送完成后，Master 會(huì)將緩沖區(qū)內(nèi)的命令及之后的寫命令轉(zhuǎn)發(fā)給 Slave 節(jié)點(diǎn)。

我們開(kāi)發(fā)的遷移代理會(huì)向上游發(fā)送 SYNC 命令模擬上游實(shí)例的 Slave，代理收到 RDB 后進(jìn)行解析，由于 RDB 中每個(gè) Key 的格式與 RESTORE 命令的格式相同，所以我們使用生成 RESTORE 命令按照下游的 Key 重新計(jì)算哈希并使用 Pipeline 批量發(fā)送給下游。

等待 RDB 轉(zhuǎn)發(fā)完成后，我們按照新的后端生成新的 Twemproxy 配置，并按照新的 Twemproxy 配置建立 Canary 實(shí)例，從上游的 Redis 后端中取 Key 進(jìn)行測(cè)試，測(cè)試 Resharding 過(guò)程是否正確，測(cè)試過(guò)程中的 Key 按照大小，類型，TTL 進(jìn)行比較。

測(cè)試通過(guò)后，對(duì)于集群實(shí)例，我們使用生成好的配置替代原有 Twemproxy 配置并 restart/reload Twemproxy 代理，我們修改了 Twemproxy 代碼，加入了 config reload 功能，但是實(shí)際使用中發(fā)現(xiàn)直接重啟實(shí)例更加可控。而對(duì)于單機(jī)實(shí)例，由于單機(jī)實(shí)例和集群實(shí)例對(duì)于命令的支持不同，通常需要和業(yè)務(wù)方確定后手動(dòng)重啟切換。

由于 Twemproxy 部署于 Kubernetes ，我們可以實(shí)現(xiàn)細(xì)粒度的灰度，如果客戶端接入了讀寫分離，我們可以先將讀流量接入新集群，最終接入全部流量。

這樣相對(duì)于 Redis 官方集群方案，除在上游進(jìn)行 BGSAVE 時(shí)的 fork 復(fù)制頁(yè)表時(shí)造成的尖刺以及重啟時(shí)造成的連接閃斷，其余對(duì)于 Redis 上游造成的影響微乎其微。

這樣擴(kuò)容存在的問(wèn)題：

1）對(duì)上游發(fā)送 SYNC 后，上游 fork 時(shí)會(huì)造成尖刺：

- 對(duì)于存儲(chǔ)實(shí)例，我們使用 Slave 進(jìn)行數(shù)據(jù)同步，不會(huì)影響到接收請(qǐng)求的 Master 節(jié)點(diǎn)；

- 對(duì)于緩存實(shí)例，由于沒(méi)有 Slave 實(shí)例，該尖刺無(wú)法避免，如果對(duì)于尖刺過(guò)于敏感，我們可以跳過(guò) RDB 階段，直接通過(guò) PSYNC 使用最新的 SET 消息建立下游的緩存。

2）切換過(guò)程中有可能寫到下游，而讀在上游：

- 對(duì)于接入了讀寫分離的客戶端，我們會(huì)先切換讀流量到下游實(shí)例，再切換寫流量。

3）一致性問(wèn)題，兩條具有先后順序的寫同一個(gè) Key 命令在切換代理后端時(shí)會(huì)通過(guò) 1）寫上游同步到下游 2）直接寫到下游兩種方式寫到下游，此時(shí)，可能存在應(yīng)先執(zhí)行的命令卻通過(guò) 1）執(zhí)行落后于通過(guò) 2）執(zhí)行，導(dǎo)致命令先后順序倒置：

- 這個(gè)問(wèn)題在切換過(guò)程中無(wú)法避免，好在絕大部分應(yīng)用沒(méi)有這種問(wèn)題，如果無(wú)法接受，只能通過(guò)上游停寫排空 Resharding 代理保證先后順序；

- 官方 Redis 集群方案和 Codis 會(huì)通過(guò) blocking 的 migrate 命令來(lái)保證一致性，不存在這種問(wèn)題。

實(shí)際使用過(guò)程中，如果上游分片安排合理，可實(shí)現(xiàn)數(shù)千萬(wàn)次每秒的遷移速度，1TB 的實(shí)例 Resharding 只需要半小時(shí)左右。另外，對(duì)于實(shí)際生產(chǎn)環(huán)境來(lái)說(shuō)，提前做好預(yù)期規(guī)劃比遇到問(wèn)題緊急擴(kuò)容要快且安全得多。

9、旁路分析實(shí)踐

由于生產(chǎn)環(huán)境調(diào)試需要，有時(shí)會(huì)需要監(jiān)控線上 Redis 實(shí)例的訪問(wèn)情況，Redis 提供了多種監(jiān)控手段，如 MONITOR 命令。

但由于 Redis 單線程的限制，導(dǎo)致自帶的 MONITOR 命令在負(fù)載過(guò)高的情況下會(huì)再次跑高 CPU，對(duì)于生產(chǎn)環(huán)境來(lái)說(shuō)過(guò)于危險(xiǎn)，而其余方式如 Keyspace Notify 只有寫事件，沒(méi)有讀事件，無(wú)法做到細(xì)致的觀察。

對(duì)此我們開(kāi)發(fā)了基于 libpcap 的旁路分析工具，系統(tǒng)層面復(fù)制流量，對(duì)應(yīng)用層流量進(jìn)行協(xié)議分析，實(shí)現(xiàn)旁路 MONITOR，實(shí)測(cè)對(duì)于運(yùn)行中的實(shí)例影響微乎其微。

同時(shí)對(duì)于沒(méi)有 MONITOR 命令的 Twemproxy，旁路分析工具仍能進(jìn)行分析，由于生產(chǎn)環(huán)境中絕大部分業(yè)務(wù)都使用 Kubernetes 部署于 Docker 內(nèi) ，每個(gè)容器都有對(duì)應(yīng)的獨(dú)立 IP，所以可以使用旁路分析工具反向解析找出客戶端所在的應(yīng)用，分析業(yè)務(wù)方的使用模式，防止不正常的使用。

10、將來(lái)的工作

由于 Redis 5.0 發(fā)布在即，4.0 版本趨于穩(wěn)定，我們將逐步升級(jí)實(shí)例到 4.0 版本，由此帶來(lái)的如 MEMORY 命令、Redis Module 、新的 LFU 算法等特性無(wú)論對(duì)運(yùn)維方還是業(yè)務(wù)方都有極大的幫助。

11、寫在最后

知乎架構(gòu)平臺(tái)團(tuán)隊(duì)是支撐整個(gè)知乎業(yè)務(wù)的基礎(chǔ)技術(shù)團(tuán)隊(duì)，開(kāi)發(fā)和維護(hù)著知乎幾乎全量的核心基礎(chǔ)組件，包括容器、Redis、MySQL、Kafka、LB、HBase 等核心基礎(chǔ)設(shè)施，團(tuán)隊(duì)小而精，每個(gè)同學(xué)都獨(dú)當(dāng)一面負(fù)責(zé)上面提到的某個(gè)核心系統(tǒng)。

隨著知乎業(yè)務(wù)規(guī)模的快速增長(zhǎng)，以及業(yè)務(wù)復(fù)雜度的持續(xù)增加，我們團(tuán)隊(duì)面臨的技術(shù)挑戰(zhàn)也越來(lái)越大，歡迎對(duì)技術(shù)感興趣、渴望技術(shù)挑戰(zhàn)的小伙伴加入我們，一起建設(shè)穩(wěn)定高效的知乎云平臺(tái)。

12、參考資料

[1] Redis Official site

[2] Twemproxy Github Page twitter/twemproxy

[3] Codis Github Page CodisLabs/codis

[4] SO_REUSEPORT Man Page socket(7) - Linux manual page

[5] Kubernetes Production-Grade Container Orchestration

附錄：有關(guān)架構(gòu)設(shè)計(jì)方面的文章匯總

《淺談IM系統(tǒng)的架構(gòu)設(shè)計(jì)》

《簡(jiǎn)述移動(dòng)端IM開(kāi)發(fā)的那些坑：架構(gòu)設(shè)計(jì)、通信協(xié)議和客戶端》

《一套海量在線用戶的移動(dòng)端IM架構(gòu)設(shè)計(jì)實(shí)踐分享(含詳細(xì)圖文)》

《一套原創(chuàng)分布式即時(shí)通訊(IM)系統(tǒng)理論架構(gòu)方案》

《從零到卓越：京東客服即時(shí)通訊系統(tǒng)的技術(shù)架構(gòu)演進(jìn)歷程》

《蘑菇街即時(shí)通訊/IM服務(wù)器開(kāi)發(fā)之架構(gòu)選擇》

《騰訊QQ1.4億在線用戶的技術(shù)挑戰(zhàn)和架構(gòu)演進(jìn)之路PPT》

《微信后臺(tái)基于時(shí)間序的海量數(shù)據(jù)冷熱分級(jí)架構(gòu)設(shè)計(jì)實(shí)踐》

《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)(演講全文)》

《如何解讀《微信技術(shù)總監(jiān)談架構(gòu)：微信之道——大道至簡(jiǎn)》》

《快速裂變：見(jiàn)證微信強(qiáng)大后臺(tái)架構(gòu)從0到1的演進(jìn)歷程（一）》

《17年的實(shí)踐：騰訊海量產(chǎn)品的技術(shù)方法論》

《移動(dòng)端IM中大規(guī)模群消息的推送如何保證效率、實(shí)時(shí)性？》

《現(xiàn)代IM系統(tǒng)中聊天消息的同步和存儲(chǔ)方案探討》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(二)：如何設(shè)計(jì)大量圖片文件的服務(wù)端存儲(chǔ)架構(gòu)？》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(三)：快速理解服務(wù)端數(shù)據(jù)庫(kù)讀寫分離原理及實(shí)踐建議》

《IM開(kāi)發(fā)基礎(chǔ)知識(shí)補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》

《WhatsApp技術(shù)實(shí)踐分享：32人工程團(tuán)隊(duì)創(chuàng)造的技術(shù)神話》

《微信朋友圈千億訪問(wèn)量背后的技術(shù)挑戰(zhàn)和實(shí)踐總結(jié)》

《王者榮耀2億用戶量的背后：產(chǎn)品定位、技術(shù)架構(gòu)、網(wǎng)絡(luò)方案等》

《IM系統(tǒng)的MQ消息中間件選型：Kafka還是RabbitMQ？》

《騰訊資深架構(gòu)師干貨總結(jié)：一文讀懂大型分布式系統(tǒng)設(shè)計(jì)的方方面面》

《以微博類應(yīng)用場(chǎng)景為例，總結(jié)海量社交系統(tǒng)的架構(gòu)設(shè)計(jì)步驟》

《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》

《子彈短信光鮮的背后：網(wǎng)易云信首席架構(gòu)師分享億級(jí)IM平臺(tái)的技術(shù)實(shí)踐》

《知乎技術(shù)分享：從單機(jī)到2000萬(wàn)QPS并發(fā)的Redis高性能緩存實(shí)踐之路》

>> 更多同類文章 ……

（本文同步發(fā)布于：http://www.52im.net/thread-1968-1-1.html）