redis中有什么集群方案

小編給大家分享一下redis中有什么集群方案，希望大家閱讀完這篇文章后大所收獲，下面讓我們一起去探討吧！

Redis數(shù)據(jù)量日益增大，而且使用的公司越來越多，不僅用于做緩存，同時(shí)趨向于存儲這塊，這樣必促使集群的發(fā)展，各個(gè)公司也在收集適合自己的集群方案，目前行業(yè)用的比較多的是下面幾種集群架構(gòu)，大部分都是采用分片技術(shù)，解決單實(shí)例內(nèi)存增大帶來的一系列問題。

本篇文章簡單介紹五種方案：

官方cluster方案

twemproxy代理方案

哨兵模式

codis

客戶端分片

官方cluser方案

從redis 3.0版本開始支持redis-cluster集群，redis-cluster采用無中心結(jié)構(gòu)，每個(gè)節(jié)點(diǎn)保存數(shù)據(jù)和整個(gè)集群狀態(tài)，每個(gè)節(jié)點(diǎn)都和其他節(jié)點(diǎn)連接。redis-cluster是一種服務(wù)端分片技術(shù)。

redis-cluster架構(gòu)圖

redis-cluster特點(diǎn)：

每個(gè)節(jié)點(diǎn)都和n-1個(gè)節(jié)點(diǎn)通信，這被稱為集群總線（cluster bus）。它們使用特殊的端口號，即對外服務(wù)端口號加10000。所以要維護(hù)好這個(gè)集群的每個(gè)節(jié)點(diǎn)信息，不然會導(dǎo)致整個(gè)集群不可用，其內(nèi)部采用特殊的二進(jìn)制協(xié)議優(yōu)化傳輸速度和帶寬。

redis-cluster把所有的物理節(jié)點(diǎn)映射到[0,16383]slot（槽）上，cluster負(fù)責(zé)維護(hù)node--slot--value。

集群預(yù)分好16384個(gè)桶，當(dāng)需要在redis集群中插入數(shù)據(jù)時(shí)，根據(jù)CRC16(KEY) mod 16384的值，決定將一個(gè)key放到哪個(gè)桶中。

客戶端與redis節(jié)點(diǎn)直連，不需要連接集群所有的節(jié)點(diǎn)，連接集群中任何一個(gè)可用節(jié)點(diǎn)即可。

redis-trib.rb腳本（rub語言）為集群的管理工具，比如自動(dòng)添加節(jié)點(diǎn)，規(guī)劃槽位，遷移數(shù)據(jù)等一系列操作。

節(jié)點(diǎn)的fail是通過集群中超過半數(shù)的節(jié)點(diǎn)檢測失效時(shí)才生效。

整個(gè)cluster被看做是一個(gè)整體，客戶端可連接任意一個(gè)節(jié)點(diǎn)進(jìn)行操作，當(dāng)客戶端操作的key沒有分配在該節(jié)點(diǎn)上時(shí)，redis會返回轉(zhuǎn)向指令，指向正確的節(jié)點(diǎn)。

為了增加集群的可訪問性，官方推薦的方案是將node配置成主從結(jié)構(gòu)，即一個(gè)master主節(jié)點(diǎn)，掛n個(gè)slave從節(jié)點(diǎn)。如果主節(jié)點(diǎn)失效，redis cluster會根據(jù)選舉算法從slave節(jié)點(diǎn)中選擇一個(gè)上升為master節(jié)點(diǎn)，整個(gè)集群繼續(xù)對外提供服務(wù)。

twemproxy代理方案

twemproxy代理架構(gòu)圖：

Redis代理中間件twemproxy是一種利用中間件做分片的技術(shù)。twemproxy處于客戶端和服務(wù)器的中間，將客戶端發(fā)來的請求，進(jìn)行一定的處理后（sharding），再轉(zhuǎn)發(fā)給后端真正的redis服務(wù)器。也就是說，客戶端不直接訪問redis服務(wù)器，而是通過twemproxy代理中間件間接訪問。降低了客戶端直連后端服務(wù)器的連接數(shù)量，并且支持服務(wù)器集群水平擴(kuò)展。

twemproxy中間件的內(nèi)部處理是無狀態(tài)的，它本身可以很輕松地集群，這樣可以避免單點(diǎn)壓力或故障。

twemproxy又稱nutcracker，起源于推特系統(tǒng)中redis、memcached集群的輕量級代理。

Github源碼地址（https://github.com/twitter/twemproxy）

從上面架構(gòu)圖看到twemproxy是一個(gè)單點(diǎn)，很容易對其造成很大的壓力，所以通常會結(jié)合keepalived來實(shí)現(xiàn)twemproy的高可用。這時(shí)，通常只有一臺twemproxy在工作，另外一臺處于備機(jī)，當(dāng)一臺掛掉以后，vip自動(dòng)漂移，備機(jī)接替工作。關(guān)于keepalived的用法可自行網(wǎng)上查閱資料。

哨兵模式

Sentinel哨兵

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ù)器升級為新的主服務(wù)器。

例如:

在Server1掉線后：

升級Server2為新的主服務(wù)器：

Sentinel的工作方式

每個(gè)Sentinel以每秒鐘一次的頻率向它所知的Master、Slave以及其他Sentinel實(shí)例發(fā)送一個(gè)PING命令。

如果一個(gè)實(shí)例距離最后一次有效回復(fù)PING命令的時(shí)間超過down-after-milliseconds選項(xiàng)所指定的值，則這個(gè)實(shí)例會被Sentinel標(biāo)記為主觀下線。

如果一個(gè)Master被標(biāo)記為主觀下線，則正在監(jiān)視這個(gè)Master的所有Sentinel要以每秒一次的頻率確認(rèn)Master的確進(jìn)入了主觀下線狀態(tài)。

當(dāng)有足夠數(shù)量的Sentinel（大于等于配置文件指定的值）在指定的時(shí)間范圍內(nèi)確認(rèn)Master的確進(jìn)入了主觀下線狀態(tài)，則Master會被標(biāo)記為客觀下線。

在一般情況下，每個(gè)Sentinel會以每10秒一次的頻率向它所知的所有Master、Slave發(fā)送INFO命令。

當(dāng)Master被Sentinel標(biāo)記為客觀下線時(shí)，Sentinel向下線的Master的所有Slave發(fā)送INFO命令的頻率會從10秒一次改為每秒一次。

若沒有足夠數(shù)量的Sentinel同意Master已經(jīng)下線，Master的客觀下線狀態(tài)就會被移除。若Master重新向Sentinel的PING命令返回有效值，Master的主觀下線狀態(tài)就會被移除。

codis

codis是一個(gè)分布式的Redis解決方案，由豌豆莢開源，對于上層的應(yīng)用來說，連接codis proxy和連接原生的redis server沒什么明顯的區(qū)別，上層應(yīng)用可以像使用單機(jī)的redis一樣使用，codis底層會處理請求的轉(zhuǎn)發(fā)，不停機(jī)的數(shù)據(jù)遷移等工作，所有后邊的事情，對于前面的客戶端來說是透明的，可以簡單的認(rèn)為后邊連接的是一個(gè)內(nèi)存無限大的redis服務(wù)。

客戶端分片

分區(qū)的邏輯在客戶端實(shí)現(xiàn)，由客戶端自己選擇請求到哪個(gè)節(jié)點(diǎn)。方案可參考一致性哈希，這種方案通常適用于用戶對客戶端的行為有完全控制能力的場景。

總結(jié)：沒有最好的方案，只有最合適的方案。

看完了這篇文章，相信你對redis中有什么集群方案有了一定的了解，想了解更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！