Redis叢集方案
Redis資料量日益增大，而且使用的公司越來越多，不僅用於做快取，同時趨向於儲存這塊，這樣必促使叢集的發展，各個公司也在收集適合自己的叢集方案，目前行業用的比較多的是下面幾種叢集架構，大部分都是採用分片技術，解決單例項記憶體增大帶來的一系列問題。
本篇文章簡單介紹五種方案：
官方cluster方案
twemproxy代理方案
哨兵模式
codis
客戶端分片
官方cluser方案
從redis 3.0版本開始支援redis-cluster叢集，redis-cluster採用無中心結構，每個節點儲存資料和整個叢集狀態，每個節點都和其他節點連線。redis-cluster是一種服務端分片技術。
redis-cluster架構圖
redis-cluster特點：
每個節點都和n-1個節點通訊，這被稱為叢集匯流排（cluster bus）。它們使用特殊的埠號，即對外服務埠號加10000。所以要維護好這個叢集的每個節點資訊，不然會導致整個叢集不可用，其內部採用特殊的二進位制協議優化傳輸速度和頻寬。
redis-cluster把所有的物理節點對映到[0,16383]slot（槽）上，cluster負責維護node--slot--value。
叢集預分好16384個桶，當需要在redis叢集中插入資料時，根據CRC16(KEY) mod 16384的值，決定將一個key放到哪個桶中。
客戶端與redis節點直連，不需要連線叢集所有的節點，連線叢集中任何一個可用節點即可。
redis-trib.rb指令碼（rub語言）為叢集的管理工具，比如自動新增節點，規劃槽位，遷移資料等一系列操作。
節點的fail是通過叢集中超過半數的節點檢測失效時才生效。
整個cluster被看做是一個整體，客戶端可連線任意一個節點進行操作，當客戶端操作的key沒有分配在該節點上時，redis會返回轉向指令，指向正確的節點。
為了增加叢集的可訪問性，官方推薦的方案是將node配置成主從結構，即一個master主節點，掛n個slave從節點。如果主節點失效，redis cluster會根據選舉演算法從slave節點中選擇一個上升為master節點，整個叢集繼續對外提供服務。
twemproxy代理方案
twemproxy代理架構圖：
Redis代理中介軟體twemproxy是一種利用中介軟體做分片的技術。twemproxy處於客戶端和伺服器的中間，將客戶端發來的請求，進行一定的處理後（sharding），再轉發給後端真正的redis伺服器。也就是說，客戶端不直接訪問redis伺服器，而是通過twemproxy代理中介軟體間接訪問。降低了客戶端直連後端伺服器的連線數量，並且支援伺服器叢集水平擴充套件。
twemproxy中介軟體的內部處理是無狀態的，它本身可以很輕鬆地叢集，這樣可以避免單點壓力或故障。
twemproxy又稱nutcracker，起源於推特系統中redis、memcached叢集的輕量級代理。
Github原始碼地址（https://github.com/twitter/twemproxy）
從上面架構圖看到twemproxy是一個單點，很容易對其造成很大的壓力，所以通常會結合keepalived來實現twemproy的高可用。這時，通常只有一臺twemproxy在工作，另外一臺處於備機，當一臺掛掉以後，vip自動漂移，備機接替工作。關於keepalived的用法可自行網上查閱資料。
哨兵模式
Sentinel哨兵
Sentinel（哨兵）是Redis的高可用性解決方案：由一個或多個Sentinel例項組成的Sentinel系統可以監視任意多個主伺服器以及這些主伺服器下的所有從伺服器，並在被監視的主伺服器進入下線狀態時，自動將下線主伺服器屬下的某個從伺服器升級為新的主伺服器。
例如:
在Server1掉線後：
升級Server2為新的主伺服器：
Sentinel的工作方式
每個Sentinel以每秒鐘一次的頻率向它所知的Master、Slave以及其他Sentinel例項傳送一個PING命令。
如果一個例項距離最後一次有效回覆PING命令的時間超過down-after-milliseconds選項所指定的值，則這個例項會被Sentinel標記為主觀下線。
如果一個Master被標記為主觀下線，則正在監視這個Master的所有Sentinel要以每秒一次的頻率確認Master的確進入了主觀下線狀態。
當有足夠數量的Sentinel（大於等於配置檔案指定的值）在指定的時間範圍內確認Master的確進入了主觀下線狀態，則Master會被標記為客觀下線。
在一般情況下，每個Sentinel會以每10秒一次的頻率向它所知的所有Master、Slave傳送INFO命令。
當Master被Sentinel標記為客觀下線時，Sentinel向下線的Master的所有Slave傳送INFO命令的頻率會從10秒一次改為每秒一次。
若沒有足夠數量的Sentinel同意Master已經下線，Master的客觀下線狀態就會被移除。若Master重新向Sentinel的PING命令返回有效值，Master的主觀下線狀態就會被移除。
codis
codis是一個分散式的Redis解決方案，由豌豆莢開源，對於上層的應用來說，連線codis proxy和連線原生的redis server沒什麼明顯的區別，上層應用可以像使用單機的redis一樣使用，codis底層會處理請求的轉發，不停機的資料遷移等工作，所有後邊的事情，對於前面的客戶端來說是透明的，可以簡單的認為後邊連線的是一個記憶體無限大的redis服務。
客戶端分片
分割槽的邏輯在客戶端實現，由客戶端自己選擇請求到哪個節點。方案可參考一致性雜湊，這種方案通常適用於使用者對客戶端的行為有完全控制能力的場景。
總結：沒有最好的方案，只有最合適的方案。
Java架構/分散式：697579751（大牛交流群）