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

創(chuàng)新互聯成立以來不斷整合自身及行業(yè)資源、不斷突破觀念以使企業(yè)策略得到完善和成熟，建立了一套“以技術為基點，以客戶需求中心、市場為導向”的快速反應體系。對公司的主營項目，如中高端企業(yè)網站企劃 / 設計、行業(yè) / 企業(yè)門戶設計推廣、行業(yè)門戶平臺運營、APP應用開發(fā)、成都手機網站制作、微信網站制作、軟件開發(fā)、重慶服務器托管等實行標準化操作，讓客戶可以直觀的預知到從創(chuàng)新互聯可以獲得的服務效果。

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

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

官方cluster方案

twemproxy代理方案

哨兵模式

codis

客戶端分片

官方cluser方案

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

redis-cluster架構圖

redis-cluster特點：

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

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

集群預分好16384個桶，當需要在redis集群中插入數據時，根據CRC16(KEY) mod 16384的值，決定將一個key放到哪個桶中。

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

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

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

整個cluster被看做是一個整體，客戶端可連接任意一個節(jié)點進行操作，當客戶端操作的key沒有分配在該節(jié)點上時，redis會返回轉向指令，指向正確的節(jié)點。

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

twemproxy代理方案

twemproxy代理架構圖：

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

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

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

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

從上面架構圖看到twemproxy是一個單點，很容易對其造成很大的壓力，所以通常會結合keepalived來實現twemproy的高可用。這時，通常只有一臺twemproxy在工作，另外一臺處于備機，當一臺掛掉以后，vip自動漂移，備機接替工作。關于keepalived的用法可自行網上查閱資料。

哨兵模式

Sentinel哨兵

Sentinel（哨兵）是Redis的高可用性解決方案：由一個或多個Sentinel實例組成的Sentinel系統(tǒng)可以監(jiān)視任意多個主服務器以及這些主服務器下的所有從服務器，并在被監(jiān)視的主服務器進入下線狀態(tài)時，自動將下線主服務器屬下的某個從服務器升級為新的主服務器。

例如:

在Server1掉線后：

升級Server2為新的主服務器：

Sentinel的工作方式

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

如果一個實例距離最后一次有效回復PING命令的時間超過down-after-milliseconds選項所指定的值，則這個實例會被Sentinel標記為主觀下線。

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

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

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

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

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

codis

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

客戶端分片

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

總結：沒有最好的方案，只有最合適的方案。

看完了這篇文章，相信你對redis中有什么集群方案有了一定的了解，想了解更多相關知識，歡迎關注創(chuàng)新互聯行業(yè)資訊頻道，感謝各位的閱讀！

另外有需要云服務器可以了解下創(chuàng)新互聯scvps.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡單易用、服務可用性高、性價比高”等特點與優(yōu)勢，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。

新聞名稱：redis中有什么集群方案-創(chuàng)新互聯
網站地址：http://aaarwkj.com/article6/dpgsig.html

成都網站建設公司_創(chuàng)新互聯，為您提供全網營銷推廣、用戶體驗、軟件開發(fā)、小程序開發(fā)、手機網站建設、企業(yè)建站

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯