[[262976]]

一、背景

隨著直播元年開啟，越來越多的直播產(chǎn)品如春筍般出現(xiàn)，在拉動營收的過程中，產(chǎn)品竭盡全力思考著各種活動來刺激用戶的消費欲望，而這類活動的基礎(chǔ)形式就是榜單，在2016年我們基于cmem及掃描流水表的方式來實現(xiàn)榜單排名，2017開始，我們對原有系統(tǒng)進行重構(gòu)，使用redis作為我們的榜單基礎(chǔ)存儲，在重構(gòu)的過程中接到調(diào)研redis分布式解決方案的任務(wù)之后，比對業(yè)內(nèi)各種開源產(chǎn)品，***定下Codis，并對其中細節(jié)做了一些研究，期間在與Codis作者交流的過程中，有幸知道增值產(chǎn)品部的simotang已經(jīng)在部門引入codis近2年時間，遂加入到codis的運維工作中，目前在部門內(nèi)部署運維codis集群15套，2T容量，總?cè)赵L問量百億+，支撐了互動視頻產(chǎn)品部基礎(chǔ)存儲，運營活動，榜單類業(yè)務(wù)2年多，共計100多個活動，榜單上千個。同時在這里非常感謝codis作者spinlock在接入codis過程中給予的指導(dǎo)與幫助。見spinlock github 與 codis地址。

二、Redis相關(guān)基礎(chǔ)概覽

2.1 Redis簡介

redis是一個基于內(nèi)存同時具備數(shù)據(jù)持久化能力的高性能，低時延的KV數(shù)據(jù)庫，value的數(shù)據(jù)結(jié)構(gòu)可以是string,hash表，list(列表)，set(集合)，sortedset(有序集合)。

Redis(RemoteDictionary Server)

Redis is anopen source (BSD licensed), in-memory data structure store, used as adatabase, cache and message broker. It supports data structures suchas strings, hashes, lists, sets, sorted sets with rangequeries，Practice: http://try.redis.io/

2.2 Redis的特點

1. 單線程異步架構(gòu)(單線程,收包，發(fā)包，解析，執(zhí)行，多路io復(fù)用接收文件事件)

2. k-v結(jié)構(gòu)，value支持豐富的數(shù)據(jù)結(jié)構(gòu)(string,hash,list,set,sortset)

3. 高性能，低時延，基于內(nèi)存操作，Get/Set10w+，高性能，基于RDB、AOF落地保證數(shù)據(jù)可靠性

4. 豐富的特性，可用于緩存，消息隊列，TTL過期

5. 支持事務(wù)，操作是原子性，要么全部提交，要么全部不提交。

2.3 Redis應(yīng)用場景

2.4 寫在前面：codis與redis的關(guān)系

codis與redis之間關(guān)系就是codis是基于多個redis實例做了一層路由層來進行數(shù)據(jù)的路由，每個redis實例承擔(dān)一定的數(shù)據(jù)分片。

2.5 redis學(xué)習(xí)資料

由于本文重點在于redis分布式解決方案，對于redis相關(guān)的基礎(chǔ)部分，大家可以參考兩本書及相關(guān)源碼分析文章。

1. Redis開發(fā)與運維(付磊)

2. Redis設(shè)計與實踐(黃健宏)(值得多看兩遍)

三、Redis分布式解決方案公司內(nèi)外比較

在比較方案之前，我們先根據(jù)我們的經(jīng)驗輸出了我們期望的解決方案應(yīng)該具備的能力，以此來衡量我們的選擇標(biāo)準(zhǔn)。

 

基于此我們對公司內(nèi)外做了一個如下的比較：

 

【公司內(nèi)組件對比】

 

【公司外組件對比】

基于以上比較，codis作為開源產(chǎn)品，可以很直觀的展示出codis運維成本低，擴容平滑最核心的優(yōu)勢。

對于數(shù)據(jù)安全目前我們基于機器本機48小時滾動備份加上公司劉備備份(每天定時目錄備份的系統(tǒng))的兜底備份，對于監(jiān)控，目前接入monitor單機備份和米格監(jiān)控告警)。

四、codis的架構(gòu)設(shè)計

4.1Codis整體的架構(gòu)設(shè)計

codis官網(wǎng)

 

【圖codis架構(gòu)圖】

如上圖所示，codis整體屬于二層架構(gòu)，proxy+存儲，相對于ckv+無proxy的設(shè)計來說整體設(shè)計會相對簡單，同時對于客戶端連接數(shù)據(jù)逐漸增大的情況下，也不用去做數(shù)據(jù)層的副本擴容，而只需要做proxy層的擴容，從這一點上看，成本會低一些，但是對于連接數(shù)不大的情況下，還需要單獨去部署proxy，從這一點上看，成本會高一些。

 

其中，開源的codisproxy的服務(wù)的注冊發(fā)現(xiàn)是通過zk來實現(xiàn)，目前部門是基于l5來做。

從整體的架構(gòu)設(shè)計圖來看，codis整體的架構(gòu)比較清晰，其中codisproxy是分布式解決方案設(shè)計中最核心的部分，存儲路由，分片遷移均與codisproxy分不開，這塊我們來看一下codisproxy的設(shè)計實現(xiàn)。

4.2Codisproxy的架構(gòu)設(shè)計實現(xiàn)

codisproxy的架構(gòu)實現(xiàn)分成2個部分，分別為4.2.1的路由映射的細節(jié)與4.2.2的proxy請求處理的細節(jié)。

4.2.1 路由映射細節(jié)

如下圖所示：該部分主要涉及到codis的路由細節(jié)，主要涉及到如何將一個key映射到具體的物理結(jié)點。

 

【圖】路由映射細節(jié)

如上圖所示：該部分主要涉及到codis的路由細節(jié)。

| 相關(guān)詞匯說明

slot：分片信息，在redis當(dāng)中僅僅表示一個數(shù)字，代表分片索引。每個分片會歸屬于具體的redis實例。

group:主要是虛擬結(jié)點，由多臺redis機器組成，形成一主多從的模式，是邏輯意義上的結(jié)點。

為了幫助大家對proxy路由映射的細節(jié)有一個更深入的理解，我整理了幾個常見的路由映射的相關(guān)問題來幫忙大家理解。

問題一：proxy是如何把請求映射到具體的redis實例中?

Codis基于crc32的算法%1024得到對應(yīng)的slot，slot就是所謂的邏輯分片，同時codis會將對應(yīng)的邏輯分片映射到對應(yīng)的虛擬結(jié)點上，每個虛擬結(jié)點是由1主多從的物理redis結(jié)點組成。至于為啥會用crc32，這個具體也沒有細究，作者也是借鑒于rediscluster中的實現(xiàn)引入的。通過引入邏輯存儲結(jié)點group，這樣即使底層的主機機器實例變更，也不映射上層的映射數(shù)據(jù)，對上層映射透明，便于分片的管理。

問題二，proxy是如何做到讀寫分離

如上圖所示，key映射到具體的虛擬結(jié)點時，能夠感知到虛擬結(jié)點對應(yīng)的主與備機實例，此時redisproxy層面能夠識別到具體的redis命令得到對應(yīng)的命令是讀與寫，再根據(jù)集群的配置是否支持讀寫分離的特性，如配置的是支持，則隨機路由到主與從機實例，如配置的是不支持，則路由到主機補全。

問題三，proxy目前支持哪些命令，是否支持批量命令，如何保證原子性

命令支持鏈接

 

命令支持部分：Prxoy支持的命令分為三種：不支持命令，半支持命令，支持命令，除了上表所示命令外，其他命令proxy均是支持的，其中不支持命令部分主要是因為這些命令參數(shù)中沒有key,因此無法識別路由信息，不知道具體路由到哪臺實例上，而半支持命令部分通常是會操作多個key,codis基于一種簡單實現(xiàn)，以***個key的路由為準(zhǔn)，因此需要業(yè)務(wù)方自己來保持多個key路由到同一個slot,當(dāng)然業(yè)務(wù)也是可以不保證，具體后果業(yè)務(wù)來承擔(dān)，是一種弱校驗的模式，而公司級產(chǎn)品ckv+對于多key操作是強校驗，如果多key不在同一slot上，則以錯誤的形式返回。

多key操作&原子性部分：Redis本身對于多key的一些操作例如mset等命令是原子性的，而在分布式操作下，多key會分布到多個redis實例當(dāng)中，涉及到分布式事務(wù)，所以在codis當(dāng)中進行了簡化處理，多key操作拆成多個單key命令操作，所以codis當(dāng)中的mset多key操作不具備原子性的語義。

問題四，如何保證多個key在一個slot當(dāng)中

有些場景下，我們希望使用到lua或者一些半支持命令來保證我們操作的原子性，因此我們需要在業(yè)務(wù)層面來去保證多key在一個slot當(dāng)中，codis采用了和rediscluster一樣的模式，基于hashtag，例如我想讓七天的主播榜單都中路由在同一個slot的話，{anchor_rank}day1,{anchor_rank}day2,{anchor_rank}day3，即可支持，對就是采用大括號的模式，codis會識別大括號，只會取大括號中的字符串進行hash操作。

4.2.2Proxy請求處理細節(jié)

如下圖所示：該部分主要涉及到proxy的處理細節(jié)，涉及到如何接受一個請求到響應(yīng)回包的過程。

 

【圖】Proxy請求處理細節(jié)

如上圖所示：該部分主要涉及到proxy的處理細節(jié)。

Codisproxy主要基于go語言這種從語言層面天然支持協(xié)程的語言來實現(xiàn)的。

1)proxy接收客戶端的連接之后，新建一個session,同時啟動session中reader與writer兩個協(xié)程，reader主要用于接收客戶端請求數(shù)據(jù)并解析，對多key的場景下進行命令的拆分，然后將請求通過router進行分發(fā)到具體的redis實例，并將redis處理的數(shù)據(jù)結(jié)果寫到通道到中，writer從通道中接收對應(yīng)的結(jié)果，將寫回給客戶端。

 

2)Router層主要是通過crc命令得到key對應(yīng)的路由信息，從源碼可以看到hashtag的特性，codis其實也是支持的。

 

至此，proxy相關(guān)的路由映射與請求處理細節(jié)已經(jīng)結(jié)束，整體下來是不是很簡單。

五、數(shù)據(jù)可靠性&高可用&容災(zāi)&故障轉(zhuǎn)移&腦裂處理

作為存儲層，數(shù)據(jù)可靠性與服務(wù)高可用是穩(wěn)定性的核心指標(biāo)，直接影響到上層核心服務(wù)的穩(wěn)定性，本節(jié)將主要針對這兩個指標(biāo)來做一下闡述。

5.1 數(shù)據(jù)可靠性

作為codis的實現(xiàn)來講，數(shù)據(jù)高可靠主要是redis本身的能力，通常存儲層的數(shù)據(jù)高可靠，主要是單機數(shù)據(jù)高可靠+遠程數(shù)據(jù)熱備+定期冷備歸檔實現(xiàn)的。

單機數(shù)據(jù)高可靠主要是借助于redis本身的持久化能力，rdb模式(定期dum)與aof模式(流水日志)，這塊可以參考前文所示的2本書來了解，其中aof模式的安全性更高，目前我們線上也是將aof開關(guān)打開，在文末也會詳細描述一下。

遠程數(shù)據(jù)熱備主要是借助于redis自身具備主從同步的特性，全量同步與增量同步的實現(xiàn)，讓redis具體遠程熱備的能力。

定期冷備歸檔由于存儲服務(wù)在運行的過程中可能存在人員誤操作數(shù)據(jù)，機房網(wǎng)絡(luò)故障，硬件問題導(dǎo)致數(shù)據(jù)丟失，因此我們需要一些兜底方案，目前主要是單機滾動備份備份最近48小時的數(shù)據(jù)以及sng的劉備系統(tǒng)來做冷備，以備非預(yù)期問題導(dǎo)致數(shù)據(jù)丟失，能夠快速恢復(fù)。

5.2 高可用&容災(zāi)&故障轉(zhuǎn)移

codis的架構(gòu)本身分成proxy集群+redis集群，proxy集群的高可用，可以基于zk或者l5來做故障轉(zhuǎn)移，而redis集群的高可用是借助于redis開源的哨兵集群來實現(xiàn)，那邊codis作為非redis組件，需要解決的一個問題就是如何集成redis哨兵集群。本節(jié)將該問題分成三部分，介紹redis哨兵集群如何保證redis高可用，codisproxy如何感知redis哨兵集群的故障轉(zhuǎn)移動作，redis集群如何降低“腦裂”的發(fā)生概率。

5.2.1 哨兵集群如何保證redis高可用

Sentinel(哨崗，哨兵)是Redis的高可用解決方案：由一個或多個Sentinel實例組成的Sentinel系統(tǒng)，可以監(jiān)視任意多個主服務(wù)器，以及這些主服務(wù)器屬下的所有的從服務(wù)器，并在被監(jiān)視的主服務(wù)器進入下線狀態(tài)時，自動將下線主服務(wù)器屬下的某個從服務(wù)器升級為新的主服務(wù)器，然后由主服務(wù)器代替已下線的主服務(wù)器繼續(xù)處理命令請求。

通常來說要達到服務(wù)的高可用的效果需要做2個事情：故障探測與故障轉(zhuǎn)移(即選主并做主從切換)。

5.2.2 codis如何感知哨兵集群的故障轉(zhuǎn)移動作

codis的架構(gòu)本身分成proxy集群+redis集群，redis集群的高可用是由哨兵集群來保證的，那么proxy是如何感知redis主機故障，然后切換新主保證服務(wù)高可用的呢?

 

如上圖所示，proxy本身會監(jiān)聽sentinle集群的+switch-master事件，該事件發(fā)出，意味著redis集群主機出現(xiàn)問題，sentinel集群開始進行選舉并切換主機，proxy監(jiān)聽了sentinel的主從切換事件，收到主從切換事件之后，proxy會做一個動作，就是把所有sentinel上的集群所感知的當(dāng)前認為的主機拉取出來，選取過半sentinel認為的主機當(dāng)作目前的集群主機。

講到這里，大家可能會忽略一個問題，就是配置存儲，配置中心的存儲還是舊的主機，一旦proxy重起，那拉取的依舊是故障的主機，其實dashboard和proxy也做了一樣的事情，收到主從切換事件之后，就會將新主持久化到storage中(目前為zk)

5.2.3 腦裂處理

腦裂(split-brain)集群的腦裂通常是發(fā)生在集群中部分節(jié)點之間不可達而引起的。如下述情況發(fā)生時，不同分裂的小集群會自主的選擇出master節(jié)點，造成原本的集群會同時存在多個master節(jié)點。，結(jié)果會導(dǎo)致系統(tǒng)混亂，數(shù)據(jù)損壞。

 

在這個問題上，這里simotang同學(xué)已經(jīng)講解的非常完善了，大規(guī)模codis集群的治理與實踐，這里簡單說一下，由于redis集群不能單純的依賴過半選舉的模式，因為redismaster自身沒有做檢測自身健康狀態(tài)而降級的動作，所以我們需要一種master健康狀態(tài)輔助判斷降級的方式。具體實現(xiàn)為

1)降級雙主出現(xiàn)的概率，讓Quorums判斷更加嚴(yán)格，讓主機下線判斷時間更加嚴(yán)格，我們部署了5臺sentinel機器覆蓋各大運營商IDC，只有4臺主觀認為主機下線的時候才做下線。

2)被隔離的master降級，基于共享資源判斷的方式，redis服務(wù)器上agent會定時持續(xù)檢測zk是否通常，若連接不上，則向redis發(fā)送降級指令，不可讀寫，犧牲可用性，保證一致性。

六、codis水平擴容細節(jié)&遷移異常處理

由于codis是針對redis分布式的解決方案，必然會面臨著redis單點容量不足的情況下水平擴容的問題，本節(jié)主要針對codis水平擴容與遷移異常的細節(jié)做一下說明，大家先帶著兩個問題來看，問題一，遷移過程中，正在遷移的key的讀寫請求怎么處理，問題二，遷移過程中的異常(例如失敗，超時)怎么處理。

6.1 Codis擴容遷移細節(jié)

 

【圖】遷移流程

影響面：

一階段期間的影響：通知到通知成功結(jié)束期間，proxy讀寫請求阻塞，不丟失，延時增高(時間極短，并行通知，僅僅修改狀態(tài)，使proxy中slot狀態(tài)達到一致)

遷移過程：可讀，正在遷移批次的不可寫，遷移完成的批次涉及到兩次網(wǎng)絡(luò)io

如上圖所示，其實redis平滑遷移過程，主要是實現(xiàn)了3個點，遷移準(zhǔn)備，遷移動作，遷移性能保證。

遷移準(zhǔn)備

主要是在遷移動作執(zhí)行前，所有的請求都能夠感知到路由的變化，所以有了一階段的處理流程，此處實現(xiàn)是通過并行發(fā)送給所有的proxy，proxy會對相應(yīng)的slot加寫鎖，所以的請求在隊列中排隊，直到所有的proxy都通知dashboard之后，proxy的鎖才放開，此時請求的延時會有輕微增高，但由于是并行響應(yīng)，影響時間很短，視圖會輕微抖動。

遷移動作

主要由dashboard按批次觸發(fā)直到所有的key都遷移ok，遷移的過程，slot上的key可能存在2種情況，一種在新的redis實例上A，一種在舊的redis實例上B，所以對于有遷移狀態(tài)的slot，所有向這個slot發(fā)送的命令都通過在redis中定制的命令SLOTSMGRT-EXEC-WRAPPER來處理，該命令是基于3.2的分支新增的，該命令主要做這幾個事情，1)判斷key是否存在，如果存在，但不在遷移批次，則直接對key調(diào)用真實方法，如果存在，但在遷移批次，則允許讀操作，不允許寫操作，2)如果key不存大，則key可能已經(jīng)被遷移到新實例，也可能key不存在，則通知proxy前往新的實例進行操作

遷移性能

Codis的遷移其實之前2.x版本的遷移性能并不高，3.x之前性能提升了非常之大，***別的zset結(jié)構(gòu)遷移只需要10多秒，而在原來的模式需要50多秒，具體原因在于

 

遷移性能數(shù)據(jù)

6.2 遷移異常處理

另外，看到這里，不知道大家有沒有什么問題，不過這里我準(zhǔn)備了一些問題，來看看codis是如何來處理的，特別在網(wǎng)絡(luò)環(huán)境復(fù)雜，不穩(wěn)定的情況下怎么操作。

問題一，把大key拆分成小批次進行遷移，如果批次遷移失敗，超時，怎么做?

我們知道分布場景下網(wǎng)絡(luò)調(diào)用有三態(tài)，成功，失敗，超時，對于失敗還好一點，超時的情況，我們能否盲目進行重試，這里顯然不行，通常對于數(shù)據(jù)層面的重試，我們需要保證一個非常重要的原則，冪等性，但是在redis結(jié)構(gòu)中除了zset，set，hash，string結(jié)構(gòu)重試?yán)碚摬粫苡绊?，對于list怎么辦?所以codis用了一種比較暴力的方式，批次遷移成功重試時，會先帶上一個del命令，讓目標(biāo)結(jié)點先將key刪掉，再進行重試。

問題二，帶過期時間key遷移過程中，先在目標(biāo)結(jié)點上設(shè)置過期時間再傳數(shù)據(jù)，還是先傳數(shù)據(jù)在***再設(shè)置過期時間?

先看一下在目標(biāo)結(jié)點上設(shè)置過期時間再傳數(shù)據(jù)的問題：傳輸一半B機器的key過期，后續(xù)key就沒有過期時間。不符合我們的期望

再看一下先傳數(shù)據(jù)在***再設(shè)置過期時間的問題：如果傳輸一半Acrash重啟，而此時key過期，則數(shù)據(jù)落在B機器上成僵尸數(shù)據(jù)，也不符合我們的期望。那codis如何來做呢?

為了保證遷移過程中的分片在遷移異常時能自動銷毀，所以每次分片傳輸?shù)臅r候，都重置一下key過期時間為90秒(大于超時時間30秒)，在key遷移完成之后再重置為真實的過期時間，這樣即使遷移過程中Acrash,key過期或者其他的異常，分片數(shù)據(jù)也只會在目標(biāo)結(jié)點上存活90秒就銷毀。

問題三，遷移過程中Acrash, 此時對應(yīng)分片的數(shù)據(jù)一半在A，一半在B，怎么辦了?

常在河邊走，哪有不挨刀，我們就碰到過codis的一個因expire遷移實現(xiàn)不當(dāng)造成的血案，不過幸好發(fā)生在測試環(huán)境，此時千萬千萬不要拉起A，因為A上可能有舊數(shù)據(jù)，此時會導(dǎo)致已經(jīng)遷移完成的key重新遷移，造成B的數(shù)據(jù)丟失，正確的姿勢是A的備機頂上去，繼續(xù)遷移，因為A的備機雖然是異步復(fù)制，但基本接近于A的全量數(shù)據(jù)，所以問題不太大。不過所有的遷移過程中，都***把數(shù)據(jù)和分片信息備份，以防數(shù)據(jù)丟失。此時也千萬千萬不能反向?qū)的數(shù)據(jù)遷移回A,因為B上可能殘留有部分遷移的數(shù)據(jù)，會覆蓋掉A的全量數(shù)據(jù)。

問題四，為了性能問題，可否A不做備機，不開啟AOF和RDB。

這個也是萬萬不可，因為A如果crash之后，被織云拉起，則相當(dāng)于一個空實例，會清掉備機的數(shù)據(jù)，造成數(shù)據(jù)丟失。

七、Codis相關(guān)數(shù)據(jù)

其中壓測環(huán)境：壓測服務(wù)器(v4-8-100)+proxy(v4-8-100) + redis( B5(4 -32-100) )

 

從上圖中可以看出，當(dāng)單次獲取的數(shù)據(jù)量越來越大時，proxy的性能下降會非?？?，例如ZRANGE_500的直連的性能是proxy的2倍

八、運維手冊及避坑指南

操作注意項：

8.1 主從切換: 每次主從切換之后，都確認一下被切的主或者備機上的conf文件都已經(jīng)rewriteok。

grep "Generatedby CONFIG REWRITE" -C 10 {redis_conf路徑}/*.conf

8.2 遷移數(shù)據(jù)：關(guān)鍵操作前，備份數(shù)據(jù)，若涉及切片信息，備份切片信息

A遷移B時間過長的命令查看：連上Acodisserver，命令行中執(zhí)行slotsmgrt-async-status查看正在遷移的分片信息(尤其是大key)，做到心中有數(shù)。***別的key約20秒左右可以遷移完成

8.3 異常處理：redis宕機后重啟，重啟之后加載key快加載完時，頁面上報error

8.4 客戶端出現(xiàn)大量超時

8.5 fork耗時高

8.6 AOF持久化細節(jié)

常用的同步硬盤的策略是everysec，用于平衡性能和數(shù)據(jù)安全性。對于這種方式，Redis使用另一條線程每秒執(zhí)行fsync同步硬盤。當(dāng)系統(tǒng)硬盤資源繁忙時，會造成Redis主線程阻塞。

8.7 不小心手抖執(zhí)行了flushdb

如果配置appendonlyno，迅速調(diào)大rdb觸發(fā)參數(shù)，然后備份rdb文件，若備份失敗，趕緊跑路。配置了appedonlyyes, 辦法調(diào)大AOF重寫參數(shù)auto-aof-rewrite-percentage和auto-aof-rewrite-minsize，或者直接kill進程，讓Redis不能產(chǎn)生AOF自動重寫。·拒絕手動bgrewriteaof。備份aof文件，同時將備份的aof文件中寫入的flushdb命令干掉，然后還原。若還原不了，則依賴于冷備。

8.8 線上redis想將rdb模式換成aof模式

切不可，直接修改conf，重啟

正確方式：備份rdb文件，configset的方式打開aof，同時configrewrite寫回配置，執(zhí)行bgrewriteof，內(nèi)存數(shù)據(jù)備份至文件

九、參考資料

Redis開發(fā)與運維(付磊)

Redis設(shè)計與實踐(黃健宏)

大規(guī)模codis集群的治理與實踐

【本文為51CTO專欄作者“騰訊技術(shù)工程”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者(微信號：Tencent_TEG)】

戳這里，看該作者更多好文