深入浅出百亿请求高可用Redis(codis)分布式集群揭秘
摘要：作為noSql中的kv數(shù)據(jù)庫的王者，redis以其高性能，低時(shí)延，豐富的數(shù)據(jù)結(jié)構(gòu)備受開發(fā)者青睞，但是由于redis在水平伸縮性上受限，如何做到能夠水平擴(kuò)容，同時(shí)對(duì)業(yè)務(wù)無侵入性是很多使用redis的開發(fā)人員都會(huì)面臨的問題，而redis分布式解決方案的一個(gè)開源產(chǎn)品【codis】較好的彌補(bǔ)了這一弱勢(shì)，本文主要講解codis是如何做到對(duì)業(yè)務(wù)無感知，平滑遷移，遷移性能高，遷移異常處理，高可用以及常見的redis的避坑指南，雖然codis目前隨著公司的nosql產(chǎn)品越來越成熟，生命周期也即將結(jié)束，不過鑒于還有很多同學(xué)對(duì)codis的原理比較感興趣，于是將以前的分享的內(nèi)容重新整理，當(dāng)然codis在公司外應(yīng)用目前依舊還是相對(duì)比較廣泛。
目錄
一、背景?
二、Redis相關(guān)基礎(chǔ)概覽?
? ? ??2.1Redis簡介?
? ? ??2.2Redis的特點(diǎn)?
? ? ??2.3Redis應(yīng)用場(chǎng)景?
三、Redis分布式解決方案公司內(nèi)外比較?
四、Codis的架構(gòu)設(shè)計(jì)?
? ? ??4.1 Codis整體的架構(gòu)設(shè)計(jì)?
? ? ? 4.２Codisproxy的架構(gòu)設(shè)計(jì)實(shí)現(xiàn)?
五、數(shù)據(jù)可靠性 &高可用&容災(zāi)&故障轉(zhuǎn)移&腦裂處理?
? ? ??5.1?數(shù)據(jù)可靠性
? ? ??5.2?高可用&容災(zāi)&故障轉(zhuǎn)移?
六、codis水平擴(kuò)容細(xì)節(jié)&遷移異常處理?
? ? ??6.1 Codis擴(kuò)容遷移細(xì)節(jié)
? ? ??6.2?遷移異常處理?
七、Codis相關(guān)數(shù)據(jù)?
八、運(yùn)維手冊(cè)及避坑指南?
九、參考資料?
隨著直播元年開啟，越來越多的直播產(chǎn)品如春筍般出現(xiàn)，在拉動(dòng)營收的過程中，產(chǎn)品竭盡全力思考著各種活動(dòng)來刺激用戶的消費(fèi)欲望，而這類活動(dòng)的基礎(chǔ)形式就是榜單，在2016年我們基于cmem及掃描流水表的方式來實(shí)現(xiàn)榜單排名，2017開始，我們對(duì)原有系統(tǒng)進(jìn)行重構(gòu)，使用redis作為我們的榜單基礎(chǔ)存儲(chǔ)，在重構(gòu)的過程中接到調(diào)研redis分布式解決方案的任務(wù)之后，比對(duì)業(yè)內(nèi)各種開源產(chǎn)品，最后定下Codis，并對(duì)其中細(xì)節(jié)做了一些研究，期間在與Codis作者交流的過程中，有幸知道增值產(chǎn)品部的simotang已經(jīng)在部門引入codis近2年時(shí)間，遂加入到codis的運(yùn)維工作中，目前在部門內(nèi)部署運(yùn)維codis集群15套,2T容量,總?cè)赵L問量百億+.支撐了互動(dòng)視頻產(chǎn)品部基礎(chǔ)存儲(chǔ)，運(yùn)營活動(dòng)，榜單類業(yè)務(wù)2年多,共計(jì)100多個(gè)活動(dòng)，榜單上千個(gè)。同時(shí)在這里非常感謝codis作者spinlock在接入codis過程中給予的指導(dǎo)與幫助。見spinlock github?與?codis地址
2.1 Redis簡介
redis是一個(gè)基于內(nèi)存同時(shí)具備數(shù)據(jù)持久化能力的高性能，低時(shí)延的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的特點(diǎn)
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. 高性能，低時(shí)延，基于內(nèi)存操作，Get/Set10w+，高性能，基于RDB、AOF落地保證數(shù)據(jù)可靠性
4. 豐富的特性，可用于緩存，消息隊(duì)列，TTL過期
5.?支持事務(wù)，操作是原子性，要么全部提交，要么全部不提交。
2.3 Redis應(yīng)用場(chǎng)景
string | 計(jì)數(shù)器，用戶信息(id)映射，唯一性（例如用戶資格判斷），bitmap |
hash | 常見場(chǎng)景：存儲(chǔ)對(duì)象的屬性信息（用戶資料） |
list | 常見場(chǎng)景：評(píng)論存儲(chǔ)，消息隊(duì)列 |
set | 常見場(chǎng)景：資格判斷（例如用戶獎(jiǎng)勵(lì)領(lǐng)取判斷），數(shù)據(jù)去重等 |
sorted set | 常見場(chǎng)景：排行榜，延時(shí)隊(duì)列 |
其他 | 分布式鎖設(shè)計(jì)??推薦2篇文章： 基于Redis的分布式鎖到底安全嗎（上） http://zhangtielei.com/posts/blog-redlock-reasoning.html 基于Redis的分布式鎖到底安全嗎（下） http://zhangtielei.com/posts/blog-redlock-reasoning-part2.html |
2.4?寫在前面：codis與redis的關(guān)系
codis與redis之間關(guān)系就是codis是基于多個(gè)redis實(shí)例做了一層路由層來進(jìn)行數(shù)據(jù)的路由，每個(gè)redis實(shí)例承擔(dān)一定的數(shù)據(jù)分片
2.5 redis學(xué)習(xí)資料
由于本文重點(diǎn)在于redis分布式解決方案，對(duì)于redis相關(guān)的基礎(chǔ)部分，大家可以參考兩本書及相關(guān)源碼分析文章
1. Redis開發(fā)與運(yùn)維(付磊)
2. Redis設(shè)計(jì)與實(shí)踐(黃健宏)（值得多看兩遍）
在比較方案之前，我們先根據(jù)我們的經(jīng)驗(yàn)輸出了我們期望的解決方案應(yīng)該具備的能力，以此來衡量我們的選擇標(biāo)準(zhǔn)
基于此我們對(duì)公司內(nèi)外做了一個(gè)如下的比較
【公司內(nèi)組件對(duì)比】 |
?【公司外組件對(duì)比】 |
基于以上比較，codis作為開源產(chǎn)品，可以很直觀的展示出codis運(yùn)維成本低，擴(kuò)容平滑最核心的優(yōu)勢(shì).
對(duì)于數(shù)據(jù)安全目前我們基于機(jī)器本機(jī)48小時(shí)滾動(dòng)備份加上公司劉備備份（每天定時(shí)目錄備份的系統(tǒng)）的兜底備份，對(duì)于監(jiān)控，目前接入monitor單機(jī)備份和米格監(jiān)控告警）
4.1Codis整體的架構(gòu)設(shè)計(jì)
codis官網(wǎng)
【圖codis架構(gòu)圖】 |
如上圖所示，codis整體屬于二層架構(gòu)，proxy+存儲(chǔ)，相對(duì)于ckv+無proxy的設(shè)計(jì)來說整體設(shè)計(jì)會(huì)相對(duì)簡單，同時(shí)對(duì)于客戶端連接數(shù)據(jù)逐漸增大的情況下，也不用去做數(shù)據(jù)層的副本擴(kuò)容，而只需要做proxy層的擴(kuò)容，從這一點(diǎn)上看，成本會(huì)低一些，但是對(duì)于連接數(shù)不大的情況下，還需要單獨(dú)去部署proxy，從這一點(diǎn)上看，成本會(huì)高一些。
其中，開源的codisproxy的服務(wù)的注冊(cè)發(fā)現(xiàn)是通過zk來實(shí)現(xiàn)，目前部門是基于l5來做.
從整體的架構(gòu)設(shè)計(jì)圖來看，codis整體的架構(gòu)比較清晰，其中codisproxy是分布式解決方案設(shè)計(jì)中最核心的部分，存儲(chǔ)路由，分片遷移均與codisproxy分不開，這塊我們來看一下codisproxy的設(shè)計(jì)實(shí)現(xiàn)。
4.２Codisproxy的架構(gòu)設(shè)計(jì)實(shí)現(xiàn)
codisproxy的架構(gòu)實(shí)現(xiàn)分成2個(gè)部分，分別為4.2.1的路由映射的細(xì)節(jié)與4.2.2的proxy請(qǐng)求處理的細(xì)節(jié)
4.2.1 路由映射細(xì)節(jié)
如下圖所示：該部分主要涉及到codis的路由細(xì)節(jié)，主要涉及到如何將一個(gè)key映射到具體的物理結(jié)點(diǎn)
【圖】路由映射細(xì)節(jié) |
如上圖所示：該部分主要涉及到codis的路由細(xì)節(jié)
| 相關(guān)詞匯說明
slot：分片信息，在redis當(dāng)中僅僅表示一個(gè)數(shù)字，代表分片索引。每個(gè)分片會(huì)歸屬于具體的redis實(shí)例
group:主要是虛擬結(jié)點(diǎn)，由多臺(tái)redis機(jī)器組成，形成一主多從的模式，是邏輯意義上的結(jié)點(diǎn)
為了幫助大家對(duì)proxy路由映射的細(xì)節(jié)有一個(gè)更深入的理解，我整理了幾個(gè)常見的路由映射的相關(guān)問題來幫忙大家理解
問題一：proxy是如何把請(qǐng)求映射到具體的redis實(shí)例中？
Codis基于crc32的算法%1024得到對(duì)應(yīng)的slot，slot就是所謂的邏輯分片，同時(shí)codis會(huì)將對(duì)應(yīng)的邏輯分片映射到對(duì)應(yīng)的虛擬結(jié)點(diǎn)上，每個(gè)虛擬結(jié)點(diǎn)是由1主多從的物理redis結(jié)點(diǎn)組成。至于為啥會(huì)用crc32，這個(gè)具體也沒有細(xì)究，作者也是借鑒于rediscluster中的實(shí)現(xiàn)引入的。通過引入邏輯存儲(chǔ)結(jié)點(diǎn)group，這樣即使底層的主機(jī)機(jī)器實(shí)例變更，也不映射上層的映射數(shù)據(jù)，對(duì)上層映射透明，便于分片的管理。
問題二，proxy是如何做到讀寫分離
如上圖所示，key映射到具體的虛擬結(jié)點(diǎn)時(shí)，能夠感知到虛擬結(jié)點(diǎn)對(duì)應(yīng)的主與備機(jī)實(shí)例，此時(shí)redisproxy層面能夠識(shí)別到具體的redis命令得到對(duì)應(yīng)的命令是讀與寫，再根據(jù)集群的配置是否支持讀寫分離的特性，如配置的是支持，則隨機(jī)路由到主與從機(jī)實(shí)例，如配置的是不支持，則路由到主機(jī)補(bǔ)全
問題三，proxy目前支持哪些命令，是否支持批量命令，如何保證原子性
命令支持鏈接
不支持命令 | 半支持命令 |
命令支持部分：Prxoy支持的命令分為三種：不支持命令，半支持命令，支持命令，除了上表所示命令外，其他命令proxy均是支持的，其中不支持命令部分主要是因?yàn)檫@些命令參數(shù)中沒有key,因此無法識(shí)別路由信息，不知道具體路由到哪臺(tái)實(shí)例上，而半支持命令部分通常是會(huì)操作多個(gè)key,codis基于一種簡單實(shí)現(xiàn)，以第一個(gè)key的路由為準(zhǔn)，因此需要業(yè)務(wù)方自己來保持多個(gè)key路由到同一個(gè)slot,當(dāng)然業(yè)務(wù)也是可以不保證，具體后果業(yè)務(wù)來承擔(dān)，是一種弱校驗(yàn)的模式，而公司級(jí)產(chǎn)品ckv+對(duì)于多key操作是強(qiáng)校驗(yàn)，如果多key不在同一slot上，則以錯(cuò)誤的形式返回。
多key操作&原子性部分：Redis本身對(duì)于多key的一些操作例如mset等命令是原子性的，而在分布式操作下，多key會(huì)分布到多個(gè)redis實(shí)例當(dāng)中，涉及到分布式事務(wù)，所以在codis當(dāng)中進(jìn)行了簡化處理，多key操作拆成多個(gè)單key命令操作，所以codis當(dāng)中的mset多key操作不具備原子性的語義。
? 問題四，如何保證多個(gè)key在一個(gè)slot當(dāng)中
有些場(chǎng)景下，我們希望使用到lua或者一些半支持命令來保證我們操作的原子性，因此我們需要在業(yè)務(wù)層面來去保證多key在一個(gè)slot當(dāng)中，codis采用了和rediscluster一樣的模式，基于hashtag，例如我想讓七天的主播榜單都中路由在同一個(gè)slot的話，{anchor_rank}day1,{anchor_rank}day2,{anchor_rank}day3，即可支持，對(duì)就是采用大括號(hào)的模式，codis會(huì)識(shí)別大括號(hào)，只會(huì)取大括號(hào)中的字符串進(jìn)行hash操作。
4.2.2Proxy請(qǐng)求處理細(xì)節(jié)
如下圖所示：該部分主要涉及到proxy的處理細(xì)節(jié)，涉及到如何接受一個(gè)請(qǐng)求到響應(yīng)回包的過程
【圖】Proxy請(qǐng)求處理細(xì)節(jié) |
如上圖所示：該部分主要涉及到proxy的處理細(xì)節(jié)
Codisproxy主要基于go語言這種從語言層面天然支持協(xié)程的語言來實(shí)現(xiàn)的
1）proxy接收客戶端的連接之后，新建一個(gè)session,同時(shí)啟動(dòng)session中reader與writer兩個(gè)協(xié)程，reader主要用于接收客戶端請(qǐng)求數(shù)據(jù)并解析，對(duì)多key的場(chǎng)景下進(jìn)行命令的拆分，然后將請(qǐng)求通過router進(jìn)行分發(fā)到具體的redis實(shí)例，并將redis處理的數(shù)據(jù)結(jié)果寫到通道到中，writer從通道中接收對(duì)應(yīng)的結(jié)果，將寫回給客戶端。
loop reader | loop writer |
2）Router層主要是通過crc命令得到key對(duì)應(yīng)的路由信息，從源碼可以看到hashtag的特性，codis其實(shí)也是支持的。
hash源碼 |
至此，proxy相關(guān)的路由映射與請(qǐng)求處理細(xì)節(jié)已經(jīng)結(jié)束，整體下來是不是很簡單
作為存儲(chǔ)層，數(shù)據(jù)可靠性與服務(wù)高可用是穩(wěn)定性的核心指標(biāo)，直接影響到上層核心服務(wù)的穩(wěn)定性，本節(jié)將主要針對(duì)這兩個(gè)指標(biāo)來做一下闡述。
5.1 數(shù)據(jù)可靠性
作為codis的實(shí)現(xiàn)來講，數(shù)據(jù)高可靠主要是redis本身的能力，通常存儲(chǔ)層的數(shù)據(jù)高可靠，主要是單機(jī)數(shù)據(jù)高可靠+遠(yuǎn)程數(shù)據(jù)熱備+定期冷備歸檔實(shí)現(xiàn)的
單機(jī)數(shù)據(jù)高可靠主要是借助于redis本身的持久化能力，rdb模式（定期dum）與aof模式（流水日志），這塊可以參考前文所示的2本書來了解，其中aof模式的安全性更高，目前我們線上也是將aof開關(guān)打開，在文末也會(huì)詳細(xì)描述一下。
遠(yuǎn)程數(shù)據(jù)熱備主要是借助于redis自身具備主從同步的特性，全量同步與增量同步的實(shí)現(xiàn)，讓redis具體遠(yuǎn)程熱備的能力
定期冷備歸檔由于存儲(chǔ)服務(wù)在運(yùn)行的過程中可能存在人員誤操作數(shù)據(jù)，機(jī)房網(wǎng)絡(luò)故障，硬件問題導(dǎo)致數(shù)據(jù)丟失，因此我們需要一些兜底方案，目前主要是單機(jī)滾動(dòng)備份備份最近48小時(shí)的數(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開源的哨兵集群來實(shí)現(xiàn)，那邊codis作為非redis組件，需要解決的一個(gè)問題就是如何集成redis哨兵集群。本節(jié)將該問題分成三部分，介紹redis哨兵集群如何保證redis高可用，codisproxy如何感知redis哨兵集群的故障轉(zhuǎn)移動(dòng)作，redis集群如何降低“腦裂”的發(fā)生概率。
5.2.1 哨兵集群如何保證redis高可用
Sentinel（哨崗，哨兵）是Redis的高可用解決方案：由一個(gè)或多個(gè)Sentinel實(shí)例組成的Sentinel系統(tǒng)，可以監(jiān)視任意多個(gè)主服務(wù)器，以及這些主服務(wù)器屬下的所有的從服務(wù)器，并在被監(jiān)視的主服務(wù)器進(jìn)入下線狀態(tài)時(shí)，自動(dòng)將下線主服務(wù)器屬下的某個(gè)從服務(wù)器升級(jí)為新的主服務(wù)器，然后由主服務(wù)器代替已下線的主服務(wù)器繼續(xù)處理命令請(qǐng)求。
通常來說要達(dá)到服務(wù)的高可用的效果需要做2個(gè)事情：故障探測(cè)與故障轉(zhuǎn)移（即選主并做主從切換）
故障 探測(cè) | Sentinel集群故障轉(zhuǎn)移 1）選出一臺(tái)Sentinel-leader，來進(jìn)行故障轉(zhuǎn)移操作（raft協(xié)議，過半選舉） if (winner && (max_votes < voters_quorum || max_votes < master->quorum)) 2）領(lǐng)頭sentinel在已下線的從服務(wù)器里面，挑選一個(gè)從服務(wù)器，并將其轉(zhuǎn)換為主服務(wù)器 3）讓已下線主服務(wù)器屬下的所有從服務(wù)器改為復(fù)制新的主服務(wù)器 4）將已下線主服務(wù)器設(shè)置為新的主服務(wù)器的從服務(wù)器，當(dāng)這個(gè)舊的主服務(wù)器重新上線時(shí)，它就會(huì)成為新的主服務(wù)器的從服務(wù)器 注：從服務(wù)器中挑選新的主服務(wù)器的步驟 1）選舉列表中剔除所有下線或者斷線狀態(tài)的從服務(wù)器 剔除所有最近五秒內(nèi)沒有回復(fù)過領(lǐng)頭Sentinel的info命令的從服務(wù)器 剔除所有與已下線服務(wù)器超過down-after-millisenconds * 10（ms)的從服務(wù)器 2）根據(jù)從服務(wù)器優(yōu)先級(jí)（取最高），復(fù)制偏移量（取最大），運(yùn)行ID（取最小）1)每1秒，向主服務(wù)器，從服務(wù)器，其他sentinel實(shí)例發(fā)送ping命令 有效回復(fù)：+PONG, -Loading,+MASTERDOWN三種回復(fù)一種 無效回復(fù)：除以上三種回復(fù)之外的回復(fù)，或者在指定時(shí)限內(nèi)沒有返回的回復(fù) Sentinel.conf -> Sentinel down-master-millsenconds master 50000 (當(dāng)連續(xù)50秒，sentinel都接收到無效請(qǐng)求或者無回復(fù)時(shí)，就會(huì)將master標(biāo)記為主觀下線) 2)主觀下線之后，向其他sentinel發(fā)送詢問命令，如果達(dá)到配置中指定的數(shù)量時(shí)，則標(biāo)記master為客觀下線 Sentinel monitor master xx.xx.xx.xx 2 |
故障 轉(zhuǎn)移 | Sentinel集群故障轉(zhuǎn)移 1）選出一臺(tái)Sentinel-leader，來進(jìn)行故障轉(zhuǎn)移操作（raft協(xié)議，過半選舉） if (winner && (max_votes < voters_quorum || max_votes < master->quorum)) 2）領(lǐng)頭sentinel在已下線的從服務(wù)器里面，挑選一個(gè)從服務(wù)器，并將其轉(zhuǎn)換為主服務(wù)器 3）讓已下線主服務(wù)器屬下的所有從服務(wù)器改為復(fù)制新的主服務(wù)器 4）將已下線主服務(wù)器設(shè)置為新的主服務(wù)器的從服務(wù)器，當(dāng)這個(gè)舊的主服務(wù)器重新上線時(shí)，它就會(huì)成為新的主服務(wù)器的從服務(wù)器 注：從服務(wù)器中挑選新的主服務(wù)器的步驟 1）選舉列表中剔除所有下線或者斷線狀態(tài)的從服務(wù)器 剔除所有最近五秒內(nèi)沒有回復(fù)過領(lǐng)頭Sentinel的info命令的從服務(wù)器 剔除所有與已下線服務(wù)器超過down-after-millisenconds * 10（ms)的從服務(wù)器 2）根據(jù)從服務(wù)器優(yōu)先級(jí)（取最高），復(fù)制偏移量（取最大），運(yùn)行ID（取最小） |
5.2.2 codis如何感知哨兵集群的故障轉(zhuǎn)移動(dòng)作
codis的架構(gòu)本身分成proxy集群+redis集群，redis集群的高可用是由哨兵集群來保證的，那么proxy是如何感知redis主機(jī)故障，然后切換新主保證服務(wù)高可用的呢？
如上圖所示，proxy本身會(huì)監(jiān)聽sentinle集群的+switch-master事件，該事件發(fā)出，意味著redis集群主機(jī)出現(xiàn)問題，sentinel集群開始進(jìn)行選舉并切換主機(jī)，proxy監(jiān)聽了sentinel的主從切換事件，收到主從切換事件之后，proxy會(huì)做一個(gè)動(dòng)作，就是把所有sentinel上的集群所感知的當(dāng)前認(rèn)為的主機(jī)拉取出來，選取過半sentinel認(rèn)為的主機(jī)當(dāng)作目前的集群主機(jī)。
講到這里，大家可能會(huì)忽略一個(gè)問題，就是配置存儲(chǔ)，配置中心的存儲(chǔ)還是舊的主機(jī)，一旦proxy重起，那拉取的依舊是故障的主機(jī)，其實(shí)dashboard和proxy也做了一樣的事情，收到主從切換事件之后，就會(huì)將新主持久化到storage中（目前為zk)
5.2.3 腦裂處理
腦裂（split-brain）集群的腦裂通常是發(fā)生在集群中部分節(jié)點(diǎn)之間不可達(dá)而引起的。如下述情況發(fā)生時(shí)，不同分裂的小集群會(huì)自主的選擇出master節(jié)點(diǎn)，造成原本的集群會(huì)同時(shí)存在多個(gè)master節(jié)點(diǎn)。，結(jié)果會(huì)導(dǎo)致系統(tǒng)混亂，數(shù)據(jù)損壞。
在這個(gè)問題上，這里simotang同學(xué)已經(jīng)講解的非常完善了，大規(guī)模codis集群的治理與實(shí)踐，這里簡單說一下，由于redis集群不能單純的依賴過半選舉的模式，因?yàn)閞edismaster自身沒有做檢測(cè)自身健康狀態(tài)而降級(jí)的動(dòng)作，所以我們需要一種master健康狀態(tài)輔助判斷降級(jí)的方式。具體實(shí)現(xiàn)為
1）降級(jí)雙主出現(xiàn)的概率，讓Quorums判斷更加嚴(yán)格，讓主機(jī)下線判斷時(shí)間更加嚴(yán)格，我們部署了5臺(tái)sentinel機(jī)器覆蓋各大運(yùn)營商IDC，只有4臺(tái)主觀認(rèn)為主機(jī)下線的時(shí)候才做下線。
2）被隔離的master降級(jí)，基于共享資源判斷的方式，redis服務(wù)器上agent會(huì)定時(shí)持續(xù)檢測(cè)zk是否通常，若連接不上，則向redis發(fā)送降級(jí)指令，不可讀寫，犧牲可用性，保證一致性。
由于codis是針對(duì)redis分布式的解決方案，必然會(huì)面臨著redis單點(diǎn)容量不足的情況下水平擴(kuò)容的問題，本節(jié)主要針對(duì)codis水平擴(kuò)容與遷移異常的細(xì)節(jié)做一下說明，大家先帶著兩個(gè)問題來看，問題一，遷移過程中，正在遷移的key的讀寫請(qǐng)求怎么處理，問題二，遷移過程中的異常（例如失敗，超時(shí)）怎么處理。
6.1 Codis擴(kuò)容遷移細(xì)節(jié)
【圖】遷移流程 |
影響面： 一階段期間的影響：通知到通知成功結(jié)束期間，proxy讀寫請(qǐng)求阻塞，不丟失，延時(shí)增高（時(shí)間極短，并行通知，僅僅修改狀態(tài)，使proxy中slot狀態(tài)達(dá)到一致） 遷移過程：可讀，正在遷移批次的不可寫，遷移完成的批次涉及到兩次網(wǎng)絡(luò)io |
如上圖所示，其實(shí)redis平滑遷移過程，主要是實(shí)現(xiàn)了3個(gè)點(diǎn)，遷移準(zhǔn)備，遷移動(dòng)作，遷移性能保證。
遷移準(zhǔn)備
主要是在遷移動(dòng)作執(zhí)行前，所有的請(qǐng)求都能夠感知到路由的變化，所以有了一階段的處理流程，此處實(shí)現(xiàn)是通過并行發(fā)送給所有的proxy，proxy會(huì)對(duì)相應(yīng)的slot加寫鎖，所以的請(qǐng)求在隊(duì)列中排隊(duì)，直到所有的proxy都通知dashboard之后，proxy的鎖才放開，此時(shí)請(qǐng)求的延時(shí)會(huì)有輕微增高，但由于是并行響應(yīng)，影響時(shí)間很短，視圖會(huì)輕微抖動(dòng)。
遷移動(dòng)作
主要由dashboard按批次觸發(fā)直到所有的key都遷移ok，遷移的過程，slot上的key可能存在2種情況，一種在新的redis實(shí)例上A，一種在舊的redis實(shí)例上B，所以對(duì)于有遷移狀態(tài)的slot，所有向這個(gè)slot發(fā)送的命令都通過在redis中定制的命令SLOTSMGRT-EXEC-WRAPPER來處理，該命令是基于3.2的分支新增的，該命令主要做這幾個(gè)事情，1）判斷key是否存在，如果存在，但不在遷移批次，則直接對(duì)key調(diào)用真實(shí)方法，如果存在，但在遷移批次，則允許讀操作，不允許寫操作，2）如果key不存大，則key可能已經(jīng)被遷移到新實(shí)例，也可能key不存在，則通知proxy前往新的實(shí)例進(jìn)行操作
遷移性能
Codis的遷移其實(shí)之前2.x版本的遷移性能并不高，3.x之前性能提升了非常之大，千萬級(jí)別的zset結(jié)構(gòu)遷移只需要10多秒，而在原來的模式需要50多秒，具體原因在于
遷移性能數(shù)據(jù)
6.2 遷移異常處理
另外，看到這里，不知道大家有沒有什么問題，不過這里我準(zhǔn)備了一些問題，來看看codis是如何來處理的，特別在網(wǎng)絡(luò)環(huán)境復(fù)雜，不穩(wěn)定的情況下怎么操作
問題一，把大key拆分成小批次進(jìn)行遷移，如果批次遷移失敗，超時(shí)，怎么做？
我們知道分布場(chǎng)景下網(wǎng)絡(luò)調(diào)用有三態(tài)，成功，失敗，超時(shí)，對(duì)于失敗還好一點(diǎn)，超時(shí)的情況，我們能否盲目進(jìn)行重試，這里顯然不行，通常對(duì)于數(shù)據(jù)層面的重試，我們需要保證一個(gè)非常重要的原則，冪等性，但是在redis結(jié)構(gòu)中除了zset，set，hash，string結(jié)構(gòu)重試?yán)碚摬粫?huì)受影響，對(duì)于list怎么辦？所以codis用了一種比較暴力的方式，批次遷移成功重試時(shí)，會(huì)先帶上一個(gè)del命令，讓目標(biāo)結(jié)點(diǎn)先將key刪掉，再進(jìn)行重試。
問題二，帶過期時(shí)間key遷移過程中，先在目標(biāo)結(jié)點(diǎn)上設(shè)置過期時(shí)間再傳數(shù)據(jù)，還是先傳數(shù)據(jù)在最后再設(shè)置過期時(shí)間？
先看一下在目標(biāo)結(jié)點(diǎn)上設(shè)置過期時(shí)間再傳數(shù)據(jù)的問題：傳輸一半B機(jī)器的key過期，后續(xù)key就沒有過期時(shí)間。不符合我們的期望
再看一下先傳數(shù)據(jù)在最后再設(shè)置過期時(shí)間的問題：如果傳輸一半Acrash重啟，而此時(shí)key過期，則數(shù)據(jù)落在B機(jī)器上成僵尸數(shù)據(jù)，也不符合我們的期望。那codis如何來做呢？
為了保證遷移過程中的分片在遷移異常時(shí)能自動(dòng)銷毀，所以每次分片傳輸?shù)臅r(shí)候，都重置一下key過期時(shí)間為90秒（大于超時(shí)時(shí)間30秒），在key遷移完成之后再重置為真實(shí)的過期時(shí)間，這樣即使遷移過程中Acrash,key過期或者其他的異常，分片數(shù)據(jù)也只會(huì)在目標(biāo)結(jié)點(diǎn)上存活90秒就銷毀。
問題三，遷移過程中Acrash,?此時(shí)對(duì)應(yīng)分片的數(shù)據(jù)一半在A，一半在B，怎么辦了？
常在河邊走，哪有不挨刀，我們就碰到過codis的一個(gè)因expire遷移實(shí)現(xiàn)不當(dāng)造成的血案，不過幸好發(fā)生在測(cè)試環(huán)境，此時(shí)千萬千萬不要拉起A，因?yàn)锳上可能有舊數(shù)據(jù)，此時(shí)會(huì)導(dǎo)致已經(jīng)遷移完成的key重新遷移，造成B的數(shù)據(jù)丟失，正確的姿勢(shì)是A的備機(jī)頂上去，繼續(xù)遷移，因?yàn)锳的備機(jī)雖然是異步復(fù)制，但基本接近于A的全量數(shù)據(jù)，所以問題不太大。不過所有的遷移過程中，都最好把數(shù)據(jù)和分片信息備份，以防數(shù)據(jù)丟失。此時(shí)也千萬千萬不能反向?qū)的數(shù)據(jù)遷移回A,因?yàn)锽上可能殘留有部分遷移的數(shù)據(jù)，會(huì)覆蓋掉A的全量數(shù)據(jù)。
問題四，為了性能問題，可否A不做備機(jī)，不開啟AOF和RDB
這個(gè)也是萬萬不可，因?yàn)锳如果crash之后，被織云拉起，則相當(dāng)于一個(gè)空實(shí)例，會(huì)清掉備機(jī)的數(shù)據(jù)，造成數(shù)據(jù)丟失。
其中壓測(cè)環(huán)境：壓測(cè)服務(wù)器（v4-8-100）+proxy(v4-8-100)?+??redis(?B5(4?-32-100)?)
從上圖中可以看出，當(dāng)單次獲取的數(shù)據(jù)量越來越大時(shí)，proxy的性能下降會(huì)非常快，例如ZRANGE_500的直連的性能是proxy的2倍
操作注意項(xiàng)：
8.1 主從切換:?每次主從切換之后，都確認(rèn)一下被切的主或者備機(jī)上的conf文件都已經(jīng)rewriteok。
grep "Generatedby CONFIG REWRITE" -C 10 {redis_conf路徑}/*.conf
8.2 遷移數(shù)據(jù)：關(guān)鍵操作前，備份數(shù)據(jù)，若涉及切片信息，備份切片信息
A遷移B時(shí)間過長的命令查看：連上Acodisserver，命令行中執(zhí)行slotsmgrt-async-status查看正在遷移的分片信息（尤其是大key），做到心中有數(shù)。千萬級(jí)別的key約20秒左右可以遷移完成
8.3 異常處理：redis宕機(jī)后重啟，重啟之后加載key快加載完時(shí)，頁面上報(bào)error
原因 | 可能是宕機(jī)后，redis命令寫入aof，只寫了命令的部分或者事務(wù)提交之后只寫入了事務(wù)的部分命令導(dǎo)致啟動(dòng)失敗，此時(shí)日志會(huì)aof的異常 |
修復(fù) | 第一步 備份aof文件 第二步 執(zhí)行VIP_CodisAdmin/bin中的redis-check-aof --fix appendonly.aof 第三步 重啟 |
8.4 客戶端出現(xiàn)大量超時(shí)
1）網(wǎng)絡(luò)原因，聯(lián)系“連線NOC智能助手”，確認(rèn)鏈路網(wǎng)絡(luò)是否出現(xiàn)擁塞 2）觀察視圖，查看監(jiān)聽隊(duì)列是否溢出 全連接隊(duì)列的大小取決于：min(backlog, somaxconn)?，backlog是在socket創(chuàng)建的時(shí)候傳入的，somaxconn是一個(gè)os級(jí)別的系統(tǒng)參數(shù)，基于命令ss -lnt，觀察監(jiān)聽隊(duì)列目前的長度是否與預(yù)期一致， 調(diào)整參數(shù)：vim /etc/sysctl.conf?net.core.somaxconn=1024???sysctl?-p 3）慢查詢，slowlogget，確認(rèn)是否有耗時(shí)操作執(zhí)行，現(xiàn)網(wǎng)默認(rèn)是10ms slowlog-log-slower-than和slowlog-max-len 其中注意：慢查詢不包含請(qǐng)求排隊(duì)時(shí)間，只包含請(qǐng)求執(zhí)行時(shí)間，所以有可能是redis本身排隊(duì)導(dǎo)致的問題，但通過慢查詢可能查不出來 |
8.5 fork耗時(shí)高
原因 | 1）當(dāng)Redis做RDB或AOF重寫時(shí)，一個(gè)必不可少的操作就是執(zhí)行fork操作創(chuàng)建子進(jìn)程，雖然fork創(chuàng)建的子進(jìn)程不需要拷貝父進(jìn)程的物理內(nèi)存空間，但是會(huì)復(fù)制父進(jìn)程的空間內(nèi)存頁表，可以在info stats統(tǒng)計(jì)中查latest_fork_usec指標(biāo)獲取最近一次fork操作耗時(shí)，單位（微秒）。 |
改善 | 1）優(yōu)先使用物理機(jī)或者高效支持fork操作的虛擬化技術(shù)。 2）控制redis單實(shí)例的內(nèi)存大小。fork耗時(shí)跟內(nèi)存量成正比，線上建議每個(gè)Redis實(shí)例內(nèi)存控制在10GB以內(nèi)。 3）適度放寬AOF rewrite觸發(fā)時(shí)機(jī)，目前線上配置：auto-aof-rewrite-percentage增長100 % |
子進(jìn)程開銷 監(jiān)控與優(yōu)化 | cpu 不要和其他CPU密集型服務(wù)部署在一起，造成CPU過度競(jìng)爭(zhēng) 如果部署多個(gè)Redis實(shí)例，盡量保證同一時(shí)刻只有一個(gè)子進(jìn)程執(zhí)行重寫工作 1G內(nèi)存fork時(shí)間約20ms |
內(nèi)存 背景：子進(jìn)程通過fork操作產(chǎn)生，占用內(nèi)存大小等同于父進(jìn)程，理論上需要兩倍的內(nèi)存來完成持久化操作，但Linux有寫時(shí)復(fù)制機(jī)制（copy-on-write）。父子進(jìn)程會(huì)共享相同的物理內(nèi)存頁，當(dāng)父進(jìn)程處理寫請(qǐng)求時(shí)會(huì)把要修改的頁創(chuàng)建副本，而子進(jìn)程在fork操作過程中共享整個(gè)父進(jìn)程內(nèi)存快照。 Fork耗費(fèi)的內(nèi)存相關(guān)日志：AOF rewrite:?53?MB?of?memory?used?by?copy-on-write，RDB: 5?MB?of?memory?used?by?copy-on-write 關(guān)閉巨頁，開啟之后，復(fù)制頁單位從原來4KB變?yōu)?MB，增加fork的負(fù)擔(dān),會(huì)拖慢寫操作的執(zhí)行時(shí)間，導(dǎo)致大量寫操作慢查詢 “sudo echo never>/sys/kernel/mm/transparent_hugepage/enabled 硬盤 不要和其他高硬盤負(fù)載的服務(wù)部署在一起。如：存儲(chǔ)服務(wù)、消息隊(duì)列 |
8.6? AOF持久化細(xì)節(jié)
常用的同步硬盤的策略是everysec，用于平衡性能和數(shù)據(jù)安全性。對(duì)于這種方式，Redis使用另一條線程每秒執(zhí)行fsync同步硬盤。當(dāng)系統(tǒng)硬盤資源繁忙時(shí)，會(huì)造成Redis主線程阻塞。
1）主線程負(fù)責(zé)寫入AOF緩沖區(qū)(源碼：flushAppendOnlyFile) 2）AOF線程負(fù)責(zé)每秒執(zhí)行一次同步磁盤操作，并記錄最近一次同步時(shí)間。 3）主線程負(fù)責(zé)對(duì)比上次AOF同步時(shí)間： 如果距上次同步成功時(shí)間在2秒內(nèi)，主線程直接返回。 如果距上次同步成功時(shí)間超過2秒，主線程將調(diào)用write(2)阻塞，直到同步操作完成 | |
備注：打開AOF持久化功能后，Redis處理完每個(gè)事件后會(huì)調(diào)用write(2)將變化寫入kernel的buffer，如果此時(shí)write(2)被阻塞，Redis就不能處理下一個(gè)事件。Linux規(guī)定執(zhí)行write(2)時(shí)，如果對(duì)同一個(gè)文件正在執(zhí)行fdatasync(2)將kernel buffer寫入物理磁盤, write(2)會(huì)被Block住，整個(gè)Redis被Block住。 通過對(duì)AOF阻塞流程可以發(fā)現(xiàn)兩個(gè)問題： 1）everysec配置最多可能丟失2秒數(shù)據(jù)，不是1秒。 2）如果系統(tǒng)fsync緩慢，將會(huì)導(dǎo)致Redis主線程阻塞影響效率。 Redis提供了一個(gè)自救的方式，當(dāng)發(fā)現(xiàn)文件有在執(zhí)行fdatasync(2)時(shí)，就先不調(diào)用write(2)，只存在cache里，免得被Block。但如果已經(jīng)超過兩秒都還是這個(gè)樣子，則會(huì)硬著頭皮執(zhí)行write(2)，即使redis會(huì)被Block住。 Asynchronous AOF fsync is taking too long (disk is busy). Writing the AOF buffer，without waiting for fsync to complete, this may slow down 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進(jìn)程，讓Redis不能產(chǎn)生AOF自動(dòng)重寫。·拒絕手動(dòng)bgrewriteaof。備份aof文件，同時(shí)將備份的aof文件中寫入的flushdb命令干掉，然后還原。若還原不了，則依賴于冷備。
8.8 線上redis想將rdb模式換成aof模式
切不可，直接修改conf，重啟
正確方式：備份rdb文件，configset的方式打開aof，同時(shí)configrewrite寫回配置，執(zhí)行bgrewriteof，內(nèi)存數(shù)據(jù)備份至文件
Redis開發(fā)與運(yùn)維(付磊)
Redis設(shè)計(jì)與實(shí)踐(黃健宏)
大規(guī)模codis集群的治理與實(shí)踐
總結(jié)
以上是生活随笔為你收集整理的深入浅出百亿请求高可用Redis(codis)分布式集群揭秘的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 腾讯机智在GTC 2019
- 下一篇： 腾讯再次开源三项技术，提升企业运维效率