共計 2559 個字符，預計需要花費 7 分鐘才能閱讀完成。
自動寫代碼機器人，免費開通
丸趣 TV 小編給大家分享一下 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 服務。
客戶端分片
分區的邏輯在客戶端實現，由客戶端自己選擇請求到哪個節點。方案可參考一致性哈希，這種方案通常適用于用戶對客戶端的行為有完全控制能力的場景。
總結：沒有最好的方案，只有最合適的方案。
看完了這篇文章，相信你對 redis 中有什么集群方案有了一定的了解，想了解更多相關知識，歡迎關注丸趣 TV 行業資訊頻道，感謝各位的閱讀！
向 AI 問一下細節丸趣 TV 網 – 提供最優質的資源集合！
