背景介紹

我們先來(lái)看一下為什么要做集群，如果我們要部署一個(gè)單節(jié)點(diǎn)Redis，很明顯會(huì)遇到單點(diǎn)故障的問(wèn)題。

首先能想到解決單點(diǎn)故障的方法，就是做主從，但是當(dāng)有海量存儲(chǔ)需求時(shí)，單一的主從結(jié)構(gòu)就會(huì)出問(wèn)題，說(shuō)問(wèn)題之前要先了解一下主從之間是如何復(fù)制的。

我們把Redis分為三個(gè)部分，分別是客戶端、主節(jié)點(diǎn)以及從節(jié)點(diǎn)，如果從節(jié)點(diǎn)要同步主節(jié)點(diǎn)的數(shù)據(jù)，它首先會(huì)發(fā)Sync指令給主節(jié)點(diǎn)，主節(jié)點(diǎn)收到指令之后會(huì)執(zhí)行BGSAVE命令生成RDB文件，這個(gè)RDB文件指的是快照文件，它是Redis兩種備份方式的其中一種，另一種叫AOF，它的原理是將所有的寫(xiě)入指令存入文件，mysql的binlog原理是一樣的。

如果主節(jié)點(diǎn)在生成RDB的過(guò)程當(dāng)中，客戶端發(fā)來(lái)了寫(xiě)入指令，這個(gè)時(shí)候主節(jié)點(diǎn)會(huì)把指令全部寫(xiě)入緩沖區(qū)，等RDB生成完了，會(huì)把RDB文件發(fā)送給從節(jié)點(diǎn)，最后再把緩沖區(qū)的指令發(fā)送給從節(jié)點(diǎn)。這樣就完成了整個(gè)的復(fù)制。

我們剛才說(shuō)單純地做主從是有缺陷的，這個(gè)缺陷就是如果我們要存儲(chǔ)海量的數(shù)據(jù)，那么BGSAVE指令生成的RDB文件會(huì)非常巨大，這個(gè)文件傳送給從節(jié)點(diǎn)也會(huì)非常慢，如果緩沖區(qū)命令很多的話，從節(jié)點(diǎn)同步數(shù)據(jù)時(shí)也會(huì)執(zhí)行很久，所以，要解決單點(diǎn)問(wèn)題和海量存儲(chǔ)問(wèn)題，還是要考慮做集群。

Redis常見(jiàn)集群方案

Redis集群方案目前主流的有三種，分別是Twemproxy、Codis和Redis Cluster。

Twemproxy，是推特開(kāi)源的，它最大的缺點(diǎn)就是無(wú)法平滑的擴(kuò)縮容，而Codis解決了Twemproxy擴(kuò)縮容的問(wèn)題，而且兼容了Twemproxy，它是由豌豆莢開(kāi)源的，和Twemproxy都是代理模式。其實(shí)Codis能發(fā)展起來(lái)的一個(gè)主要原因是它是在Redis官方集群方案漏洞百出的時(shí)候率先成熟穩(wěn)定的。以現(xiàn)在的Redis官方集群方案，這兩個(gè)好像沒(méi)有太大差別了，不過(guò)我也沒(méi)有去做性能測(cè)試，不清楚哪個(gè)最好。

Redis Cluster是由官方出品的，用去中心化的方式實(shí)現(xiàn)，不屬于代理模式，今天主要講codis，redis cluster后面也會(huì)過(guò)一下。下面，來(lái)看一下Codis的實(shí)現(xiàn)原理。

Codis原理

我們換一種方式去講，就按照Codis的架構(gòu)演進(jìn)一下，這樣理解會(huì)比較清晰一點(diǎn)，假如現(xiàn)在只有一個(gè)Redis Server，怎么讓它變得高可用？

開(kāi)篇的時(shí)候也有講，首先，能想到的就是做主從，這樣就算主宕機(jī)了，從節(jié)點(diǎn)也能馬上接替主節(jié)點(diǎn)的位置。

我們現(xiàn)在已經(jīng)做成主從結(jié)構(gòu)了，那到底是誰(shuí)來(lái)負(fù)責(zé)主從之間的切換？

就是它，Sentinel，中文名叫哨兵，它呢，在Redis里面主要負(fù)責(zé)監(jiān)控主從節(jié)點(diǎn)，如果主節(jié)點(diǎn)掛了，就會(huì)把從拉起來(lái)。但是哨兵本身也存在單點(diǎn)問(wèn)題，所以它也需要做集群。

那么問(wèn)題來(lái)了，哨兵是如何做主從切換呢？來(lái)看下哨兵的運(yùn)行機(jī)制。

假如有三個(gè)哨兵和一主兩從的節(jié)點(diǎn)，下面是一主多從，哨兵之間會(huì)互相監(jiān)測(cè)運(yùn)行狀態(tài)，并且會(huì)交換一下節(jié)點(diǎn)監(jiān)測(cè)的狀態(tài)，同時(shí)哨兵也會(huì)監(jiān)測(cè)主從節(jié)點(diǎn)的狀態(tài)。

如果檢測(cè)到某一個(gè)節(jié)點(diǎn)沒(méi)有正常回復(fù)，并且距離上次正常回復(fù)的時(shí)間超過(guò)了某個(gè)閾值，那么就認(rèn)為該節(jié)點(diǎn)為主觀下線。

這個(gè)時(shí)候其他哨兵也會(huì)來(lái)監(jiān)測(cè)該節(jié)點(diǎn)是不是真的主觀下線，如果有足夠多數(shù)量的哨兵都認(rèn)為它確實(shí)主觀下線了，那么它就會(huì)被標(biāo)記為客觀下線，這個(gè)時(shí)候哨兵會(huì)找下線節(jié)點(diǎn)的從節(jié)點(diǎn)，然后與其他哨兵協(xié)商出一個(gè)從節(jié)點(diǎn)做主節(jié)點(diǎn)，并將剩余的從節(jié)點(diǎn)指向新的主節(jié)點(diǎn)。

關(guān)于主從節(jié)點(diǎn)的切換有兩個(gè)環(huán)節(jié)，第一個(gè)是哨兵要選舉出領(lǐng)頭人來(lái)負(fù)責(zé)下線機(jī)器的故障轉(zhuǎn)移，第二是從Slave中選出主節(jié)點(diǎn)，領(lǐng)頭人的選舉規(guī)則是誰(shuí)發(fā)現(xiàn)客觀下線誰(shuí)就可以馬上要求其他哨兵認(rèn)自己做老大，其他哨兵會(huì)無(wú)條件接受第一個(gè)發(fā)過(guò)來(lái)的人，并告知老大，如果超過(guò)一半人都同意了，那他老大的位置就坐實(shí)了。

關(guān)于從節(jié)點(diǎn)選舉，一共有四個(gè)因素影響選舉的結(jié)果，分別是斷開(kāi)連接時(shí)長(zhǎng)、優(yōu)先級(jí)排序、復(fù)制數(shù)量、進(jìn)程id，如果連接斷開(kāi)的比較久，超過(guò)了某個(gè)閾值，就直接失去了選舉權(quán)，如果擁有選舉權(quán)，那就看誰(shuí)的優(yōu)先級(jí)高，這個(gè)在配置文件里可以設(shè)置，數(shù)值越小優(yōu)先級(jí)越高，如果優(yōu)先級(jí)相同，就看誰(shuí)從master中復(fù)制的數(shù)據(jù)最多，選最多的那個(gè)，如果復(fù)制數(shù)量也相同，就選擇進(jìn)程id最小的那個(gè)。

現(xiàn)在繼續(xù)回過(guò)來(lái)，剛才講痛點(diǎn)的時(shí)候說(shuō)了，如果有存儲(chǔ)海量數(shù)據(jù)的需求，同步會(huì)非常緩慢，所以我們應(yīng)該把一個(gè)主從結(jié)構(gòu)變成多個(gè)，把存儲(chǔ)的key分?jǐn)偟礁鱾€(gè)主從結(jié)構(gòu)中來(lái)分擔(dān)壓力。

就像這樣，代理通過(guò)一種算法把要操作的key經(jīng)過(guò)計(jì)算后分配到各個(gè)組中，這個(gè)過(guò)程叫做分片，我們來(lái)看一下分片的實(shí)現(xiàn)原理。

分片算法

在Codis里面，它把所有的key分為1024個(gè)槽，每一個(gè)槽位都對(duì)應(yīng)了一個(gè)分組，具體槽位的分配，可以進(jìn)行自定義，現(xiàn)在如果有一個(gè)key進(jìn)來(lái)，首先要根據(jù)CRC32算法，針對(duì)key算出32位的哈希值，然后除以1024取余，然后就能算出這個(gè)KEY屬于哪個(gè)槽，然后根據(jù)槽與分組的映射關(guān)系，就能去對(duì)應(yīng)的分組當(dāng)中處理數(shù)據(jù)了。

CRC全稱是循環(huán)冗余校驗(yàn)，主要在數(shù)據(jù)存儲(chǔ)和通信領(lǐng)域保證數(shù)據(jù)正確性的校驗(yàn)手段，我去看了這個(gè)算法的原理，還沒(méi)理解透徹，這里就先不講了，省得誤導(dǎo)大家。

我們繼續(xù)回過(guò)來(lái)，剛才所講的槽位和分組的映射關(guān)系就保存在codis proxy當(dāng)中，但是codis proxy它本身也存在單點(diǎn)問(wèn)題，所以需要對(duì)proxy做一個(gè)集群。

部署好集群之后，有一個(gè)問(wèn)題，就是槽位的映射關(guān)系是保存在proxy里面的，不同proxy之間怎么同步映射關(guān)系？

在Codis中使用的是Zookeeper來(lái)保存映射關(guān)系，由proxy上來(lái)同步配置信息，其實(shí)它支持的不止zookeeper，還有etcd和本地文件。在zookeeper中保存的數(shù)據(jù)格式就是這個(gè)樣子。除了這個(gè)還會(huì)存儲(chǔ)一些其他的信息，比如分組信息、代理信息等，感興趣可以自己去了解一下。

現(xiàn)在還有一個(gè)問(wèn)題，就是codis proxy如果出現(xiàn)異常怎么處理，這個(gè)可能要利用一下k8s中pod的特性，在k8s里面可以設(shè)置pod冗余的數(shù)量，k8s會(huì)嚴(yán)格保證啟動(dòng)的數(shù)量與設(shè)置一致，所以只需要一個(gè)進(jìn)程監(jiān)測(cè)Proxy的異常，并且把它干掉就可以了，k8s會(huì)自動(dòng)拉起來(lái)一個(gè)新的proxy。

codis給這個(gè)進(jìn)程起名叫codis-ha，codis-ha實(shí)時(shí)監(jiān)測(cè)proxy的運(yùn)行狀態(tài)，如果有異常就會(huì)干掉，它包含了哨兵的功能，所以豌豆莢直接把哨兵去掉了。

但是codis-ha在Codis整個(gè)架構(gòu)中是沒(méi)有辦法直接操作代理和服務(wù)，因?yàn)樗械拇砗头?wù)的操作都要經(jīng)過(guò)dashboard處理。所以部署的時(shí)候會(huì)利用k8s的親和性將codis-ha與dashboard部署在同一個(gè)節(jié)點(diǎn)上。

除了這些，codis自己開(kāi)發(fā)了集群管理界面，集群管理可以通過(guò)界面化的方式更方便的管理集群，這個(gè)模塊叫codis-fe，我們可以看一下這個(gè)界面。

最后就是redis客戶端了，這個(gè)沒(méi)什么好講的，客戶端是直接通過(guò)代理來(lái)訪問(wèn)后端服務(wù)的。

Redis Cluster原理

下面來(lái)看一下redis cluster的原理，它和codis不太一樣，Codis它是通過(guò)代理分片的，但是Redis Cluster是去中心化的沒(méi)有代理，所以只能通過(guò)客戶端分片，它分片的槽數(shù)跟Codis不太一樣，Codis是1024個(gè)，而Redis cluster有16384個(gè)，槽跟節(jié)點(diǎn)的映射關(guān)系保存在每個(gè)節(jié)點(diǎn)上，每個(gè)節(jié)點(diǎn)每秒鐘會(huì)ping十次其他幾個(gè)最久沒(méi)通信的節(jié)點(diǎn)，其他節(jié)點(diǎn)也是一樣的原理互相PING ，PING的時(shí)候一個(gè)是判斷其他節(jié)點(diǎn)有沒(méi)有問(wèn)題，另一個(gè)是順便交換一下當(dāng)前集群的節(jié)點(diǎn)信息、包括槽與節(jié)點(diǎn)映射的關(guān)系等。客戶端操作key的時(shí)候先通過(guò)分片算法算出所屬的槽，然后隨機(jī)找一個(gè)服務(wù)端請(qǐng)求。

但是可能這個(gè)槽并不歸隨機(jī)找的這個(gè)節(jié)點(diǎn)管，節(jié)點(diǎn)如果發(fā)現(xiàn)不歸自己管，就會(huì)返回一個(gè)MOVED ERROR通知，引導(dǎo)客戶端去正確的節(jié)點(diǎn)訪問(wèn)，這個(gè)時(shí)候客戶端就會(huì)去正確的節(jié)點(diǎn)操作數(shù)據(jù)。

這是RedisCluster大概的原理，下面看一下Codis跟RedisCluster簡(jiǎn)要的區(qū)別。