在日常開發(fā)過程中redis是我們比較常用的KV緩存中間件括荡，很多系統(tǒng)只是部署了單節(jié)點或者只是簡單在應(yīng)用層做了resharding，這就導(dǎo)致redis上的數(shù)據(jù)缺少高可用造垛，一旦某個節(jié)點出現(xiàn)問題恢恼，那么數(shù)據(jù)就會丟失而且是無法恢復(fù)的永久丟失，所以今天我們介紹下目前主流的幾種方案想幻，具體的搭建步驟也給了我不得鏈接，大家可以按照步驟去部署迎捺。
redis主從方案
redis主從模式是最簡單的一種集群方案配置起來也比較簡單举畸，它的特點主要有：
- 一個master可以擁有多個slave
- 多個slave鏈接同一個master，也可以鏈接其它slave
- 主從復(fù)制不會阻塞master,在同步數(shù)據(jù)時凳枝，master可以繼續(xù)處理client請求.
- slave 配置為slave-read-only on需要升級為主節(jié)點或者寫入配置文件中, 而不能在默認slave情況下直接設(shè)置master與slave斷開后會檢測心跳, 從新建立連接.
- 可以直接copy DUMP文件從新重啟master抄沮，在Master為空以后，slave同步數(shù)據(jù)會抹掉全部數(shù)據(jù).
這種簡單的主從讀寫分離方案的缺點也比較多岖瑰，類似Mysql的主從方案叛买，往Master節(jié)點寫數(shù)據(jù)，同時Master節(jié)點會異步寫入slave節(jié)點中蹋订。這種方案目前使用的越來越少率挣，不過對于個體開發(fā)并且對緩存依賴度不高的系統(tǒng)還是可以使用的，畢竟搭建和維護簡單露戒。
redis cluster方案
Redis Cluster是一種服務(wù)器Sharding技術(shù)椒功，3.0版本開始正式提供。
Redis Cluster中智什，Sharding采用slot(槽)的概念动漾，一共分成16384個槽，這有點兒類pre sharding思路荠锭。對于每個進入Redis的鍵值對旱眯，根據(jù)key進行散列，分配到這16384個slot中的某一個中。使用的hash算法也比較簡單删豺，就是CRC16后16384取模共虑。
Redis集群中的每個node(節(jié)點)負責(zé)分?jǐn)傔@16384個slot中的一部分，也就是說呀页，每個slot都對應(yīng)一個node負責(zé)處理妈拌。當(dāng)動態(tài)添加或減少node節(jié)點時，需要將16384個槽做個再分配赔桌，槽中的鍵值也要遷移供炎。
Redis集群，要保證16384個槽對應(yīng)的node都正常工作疾党，如果某個node發(fā)生故障，那它負責(zé)的slots也就失效惨奕，整個集群將不能工作雪位。
為了增加集群的可訪問性，官方推薦的方案是將node配置成主從結(jié)構(gòu)梨撞，即一個master主節(jié)點雹洗，掛n個slave從節(jié)點。這時卧波，如果主節(jié)點失效时肿，Redis Cluster會根據(jù)選舉算法從slave節(jié)點中選擇一個上升為主節(jié)點，整個集群繼續(xù)對外提供服務(wù)港粱，Redis Cluster本身提供了故障轉(zhuǎn)移容錯的能力螃成。
Redis Cluster的新節(jié)點識別能力、故障判斷及故障轉(zhuǎn)移能力是通過集群中的每個node都在和其它nodes進行通信查坪，這被稱為集群總線(cluster bus)寸宏。它們使用特殊的端口號，即對外服務(wù)端口號加10000偿曙。例如如果某個node的端口號是6379氮凝，那么它與其它nodes通信的端口號是16379。nodes之間的通信采用特殊的二進制協(xié)議望忆。
對客戶端來說罩阵，整個cluster被看做是一個整體，客戶端可以連接任意一個node進行操作启摄，就像操作單一Redis實例一樣稿壁，當(dāng)客戶端操作的key沒有分配到該node上時，Redis會返回轉(zhuǎn)向指令鞋仍，指向正確的node常摧。
從這種redis cluster的架構(gòu)圖中可以很容易的看出首先將數(shù)據(jù)根據(jù)hash規(guī)則分配到6個slot中（這里只是舉例子分成了6個槽），然后根據(jù)CRC算法和取模算法將6個slot分別存儲到3個不同的Master節(jié)點中，每個master節(jié)點又配套部署了一個slave節(jié)點落午，當(dāng)一個master出現(xiàn)問題后谎懦，slave節(jié)點可以頂上。這種cluster的方案對比第一種簡單的主從方案的優(yōu)點在于提高了讀寫的并發(fā)溃斋，分散了IO界拦，在保障高可用的前提下提高了性能。
具體的redis cluster的搭建方案可以參考官方的搭建方案梗劫，鏈接中是中文版享甸。
redis cluster官方搭建方案
codis集群方案
Codis是一個豌豆莢團隊開源的使用Go語言編寫的Redis Proxy使用方法和普通的redis沒有任何區(qū)別，設(shè)置好下屬的多個redis實例后就可以了梳侨，使用時在本需要連接redis的地方改為連接codis蛉威，它會以一個代理的身份接收請求 并使用一致性hash算法，將請求轉(zhuǎn)接到具體redis走哺，將結(jié)果再返回codis蚯嫌，和之前比較流行的twitter開源的Twemproxy功能類似，但是相比官方的redis cluster和twitter的Twemproxy還是有一些獨到的優(yōu)勢丙躏，Codis官方功能對比圖如下：
| Codis | Twemproxy | Redis Cluster | |
|---|---|---|---|
| resharding without restarting cluster | Yes | No | Yes |
| pipeline | Yes | Yes | No |
| hash tags for multi-key operations | Yes | Yes | Yes |
| multi-key operations while resharding | Yes | - | No(details) |
| Redis clients supporting | Any clients | Any clients | Clients have to support cluster protocol |
從表中我們可以看出Codis一個比較大的優(yōu)點是可以不停機動態(tài)新增或刪除數(shù)據(jù)節(jié)點择示，舊節(jié)點的數(shù)據(jù)也可以自動恢復(fù)到新節(jié)點。并且提供圖形化的dashboard晒旅，方便集群管理栅盲。
Codis Github
下面我們看下如果使用Coids作為緩存集群方案的架構(gòu)圖，簡單畫了這么個架構(gòu)圖废恋，這個架構(gòu)是codis保證HA的前提下的最小級谈秫，從這張架構(gòu)圖可以看到我們最少需要8臺機器，其中一臺機器是codis的dashboard用于通過web界面可視化的配置codis group和proxy拴签，也可以查看各個節(jié)點的狀態(tài)孝常；還有兩臺是用于codis的proxy代理節(jié)點，兩個節(jié)點之間通過pipeline主從互備蚓哩；還需要至少配置一臺zk用于保存slot狀態(tài)信息构灸，也可以通過etcd存儲這些狀態(tài)信息，方便client請求的路由岸梨，也可以配置多臺保證高可用喜颁；最后就是要配置數(shù)據(jù)節(jié)點來存儲數(shù)據(jù)了，在codis中需要將數(shù)據(jù)節(jié)點都放在codis group中進行管理曹阔，每個group至少保留一個節(jié)點半开，該架構(gòu)圖中，為了保證HA赃份，我們每個group都配置了一個master一個slave節(jié)點寂拆，這里配置了兩個group奢米，如果一個group中的master掛了，那么同一個group中的slave節(jié)點通過選舉算法選出新的master節(jié)點纠永，并通知到proxy鬓长，如果為了較好的高可用可以增加group的個數(shù)和每個group中slave節(jié)點的個數(shù)。
codis方案推出的時間比較長尝江，而且國內(nèi)很多互聯(lián)網(wǎng)公司都已經(jīng)使用了該集群方案控硼，所以該方案還是比較適合大型互聯(lián)網(wǎng)系統(tǒng)使用的岳枷，畢竟成功案例比較多窃页，但是codis因為要實現(xiàn)slot切片徙鱼，所以修改了redis-server的源碼，對于后續(xù)的更新升級也會存在一定的隱患惭聂。窗声，但是codis的穩(wěn)定性和高可用確實是目前做的最好的，只要有足夠多的機器能夠做到非常好的高可用緩存系統(tǒng)彼妻。
Codis搭建步驟可以參考官方的 Guide
總結(jié)
從各個集群方案的對比中我們也發(fā)現(xiàn)Codis是目前用的比較多的一種方案嫌佑，Codis在高可用方面做的比較好，不需要重啟節(jié)點和增加刪除節(jié)點后自動Resharding侨歉，但是因為Codis是對redis-server做了改動，如果出現(xiàn)問題或者redis升級小團隊可能應(yīng)付不了揩魂，所以對于小規(guī)模應(yīng)用最好還是使用官方的cluster方案幽邓，在redis3.0后官方社區(qū)也在逐步完善cluster方案，小團隊可以隨著官方版本的升級享受功能和穩(wěn)定性的提升火脉，也便于日后的維護牵舵。
