集群化的方案
Redis的Sentinel解決了主從復(fù)制故障不能自動(dòng)遷移的問題儿咱，但是主節(jié)點(diǎn)的寫性能和存儲(chǔ)能力依然是受到了Redis單機(jī)容量有限的限制庭砍，所以使用Redis集群去解決這個(gè)問題，將Redis的數(shù)據(jù)根據(jù)一定的規(guī)則分配到多臺(tái)機(jī)器混埠。
Redis集群方案
Redis Cluster 集群模式通常具有：高可用怠缸、可擴(kuò)展性、分布式钳宪、容錯(cuò)等特性揭北。Redis分布式方案一般有兩種：
客戶端分區(qū)方案
客戶端就已經(jīng)決定數(shù)據(jù)會(huì)被存儲(chǔ)到哪個(gè) redis 節(jié)點(diǎn)或者從哪個(gè) redis 節(jié)點(diǎn) 讀取數(shù)據(jù)。其主要思想是采用 哈希算法 將 Redis 數(shù)據(jù)的 key 進(jìn)行散列吏颖，通過 hash 函數(shù)搔体，特定的 key會(huì) 映射 到特定的 Redis 節(jié)點(diǎn)上。
客戶端分區(qū)方案 的代表為 Redis Sharding半醉，Redis Sharding 是 Redis Cluster 出來之前疚俱，業(yè)界普遍使用的 Redis 多實(shí)例集群方法。Java 的 Redis 客戶端驅(qū)動(dòng)庫(kù) Jedis缩多，支持 Redis Sharding 功能呆奕，即 ShardedJedis 以及 結(jié)合緩存池 的 ShardedJedisPool。
優(yōu)點(diǎn)
不使用第三方中間件衬吆，分區(qū)邏輯可控梁钾，配置簡(jiǎn)單，節(jié)點(diǎn)之間無關(guān)聯(lián)逊抡，容易線性擴(kuò)展姆泻，靈活性強(qiáng)。
缺點(diǎn)
客戶端 無法 動(dòng)態(tài)增刪 服務(wù)節(jié)點(diǎn)冒嫡，客戶端需要自行維護(hù) 分發(fā)邏輯拇勃，客戶端之間無連接共享，會(huì)造成連接浪費(fèi)孝凌。
代理分區(qū)方案
客戶端發(fā)送請(qǐng)求到一個(gè)代理組件潜秋，代理解析客戶端的數(shù)據(jù)，并將請(qǐng)求轉(zhuǎn)發(fā)至正確的節(jié)點(diǎn)胎许，最后將結(jié)果回復(fù)給客戶端峻呛。
優(yōu)點(diǎn)：簡(jiǎn)化 客戶端 的分布式邏輯，客戶端 透明接入辜窑，切換成本低钩述，代理的 轉(zhuǎn)發(fā) 和 存儲(chǔ) 分離。
缺點(diǎn)：多了一層 代理層穆碎，加重了 架構(gòu)部署復(fù)雜度 和 性能損耗牙勘。
代理分區(qū) 主流實(shí)現(xiàn)的有方案有 Twemproxy 和 Codis。
Twemproxy
Twemproxy 也叫 nutcraker，是twitter 開源的一個(gè) redis 和 memcache 的 中間代理服務(wù)器 程序方面。Twemproxy 作為 代理放钦，可接受來自多個(gè)程序的訪問，按照 路由規(guī)則恭金，轉(zhuǎn)發(fā)給后臺(tái)的各個(gè) Redis 服務(wù)器操禀，再原路返回。Twemproxy 存在 單點(diǎn)故障 問題横腿，需要結(jié)合 Lvs 和 Keepalived 做 高可用方案颓屑。
優(yōu)點(diǎn)：應(yīng)用范圍廣，穩(wěn)定性較高耿焊，中間代理層 高可用揪惦。
缺點(diǎn)：無法平滑地 水平擴(kuò)容/縮容，無 可視化管理界面罗侯，運(yùn)維不友好器腋，出現(xiàn)故障，不能 自動(dòng)轉(zhuǎn)移钩杰。
Codis
Codis 是一個(gè) 分布式 Redis 解決方案纫塌，對(duì)于上層應(yīng)用來說，連接 Codis-Proxy 和直接連接 原生的 Redis-Server 沒有的區(qū)別榜苫。Codis 底層會(huì) 處理請(qǐng)求的轉(zhuǎn)發(fā)护戳，不停機(jī)的進(jìn)行 數(shù)據(jù)遷移 等工作翎冲。Codis 采用了無狀態(tài)的 代理層垂睬，對(duì)于 客戶端 來說，一切都是透明的抗悍。
優(yōu)點(diǎn)
實(shí)現(xiàn)了上層 Proxy 和底層 Redis 的 高可用驹饺，數(shù)據(jù)分片和自動(dòng)平衡，提供 命令行接口 和 RESTful API缴渊，提供 監(jiān)控 和 管理 界面赏壹，可以動(dòng)態(tài) 添加 和 刪除 Redis 節(jié)點(diǎn)。
缺點(diǎn)
部署架構(gòu) 和 配置復(fù)雜衔沼，不支持 跨機(jī)房 和 多租戶蝌借，不支持 鑒權(quán)管理。
Cluster集群方案
Cluster模式是Redis3.0開始推出指蚁，由多個(gè)節(jié)點(diǎn)群組成的分布式服務(wù)集群菩佑，Redis的數(shù)據(jù)分布在這些節(jié)點(diǎn)中。集群不需要Sentinel哨兵也可以完成故障自動(dòng)遷移凝化。 使用集群時(shí)需要將redis配置文件中的cluster-enable配置打開稍坯。
采??中?結(jié)構(gòu)，每個(gè)節(jié)點(diǎn)保存數(shù)據(jù)和整個(gè)集群狀態(tài), 各個(gè)節(jié)點(diǎn)會(huì)互相通信搓劫，采?gossip協(xié)議交換節(jié)點(diǎn)元數(shù)據(jù)信息瞧哟，每個(gè)節(jié)點(diǎn)都和其他所有節(jié)點(diǎn)連接混巧。一個(gè)集群?少需要6個(gè)節(jié)點(diǎn)才可以保證?可?，即3主3從勤揩。
客戶端隨機(jī)地 請(qǐng)求任意一個(gè) Redis 實(shí)例咧党，然后由 Redis 將請(qǐng)求 轉(zhuǎn)發(fā) 給 正確 的 Redis 節(jié)點(diǎn)。Redis Cluster 實(shí)現(xiàn)了一種 混合形式 的 查詢路由雄可，但并不是 直接 將請(qǐng)求從一個(gè) Redis 節(jié)點(diǎn) 轉(zhuǎn)發(fā) 到另一個(gè) Redis 節(jié)點(diǎn)凿傅，而是在 客戶端 的幫助下直接 重定向（ redirected）到正確的 Redis 節(jié)點(diǎn)。
核心原理
redis cluster集群采?數(shù)據(jù)分?中的哈希槽來進(jìn)?數(shù)據(jù)存儲(chǔ)與讀取的数苫，Cluster會(huì)預(yù)分好16384個(gè)槽聪舒，每個(gè)節(jié)點(diǎn)負(fù)責(zé)其中的一部分槽位。當(dāng)需要在 Redis集群中放置?個(gè)數(shù)據(jù)時(shí)虐急，Cluster默認(rèn)會(huì)根據(jù) CRC16算法CRC16(key) mod 16384 的值箱残，決定將?個(gè)key放到哪個(gè)槽位中。
常見的配置
cluster-enabled yes：開啟集群模式(cluster)
cluster-config-file：該參數(shù)指定了集群配置文件的位置止吁，記錄集群節(jié)點(diǎn)信息被辑。以集群模式啟動(dòng)時(shí)，會(huì)首先尋找是否有集群配置文件敬惦，如果有則使用文件中的配置啟動(dòng)盼理，如果沒有，則初始化配置并將配置保存到文件中
cluster-node-timeout time：節(jié)點(diǎn)連接超時(shí)時(shí)間
cluster-announce-ip ip：集群節(jié)點(diǎn)的ip俄删，當(dāng)前節(jié)點(diǎn)的ip
cluster-announce-port port：集群節(jié)點(diǎn)映射端?
優(yōu)點(diǎn)
無中心節(jié)點(diǎn)宏怔，數(shù)據(jù)按照 槽 存儲(chǔ)分布在多個(gè) Redis 實(shí)例上，可以平滑的進(jìn)行節(jié)點(diǎn) 擴(kuò)容/縮容畴椰，支持 高可用 和 自動(dòng)故障轉(zhuǎn)移臊诊，運(yùn)維成本低。
缺點(diǎn)
嚴(yán)重依賴 Redis-trib 工具斜脂，缺乏監(jiān)控管理抓艳，需要依賴 Smart Client (維護(hù)連接，緩存路由表帚戳，MultiOp 和 Pipeline 支持)玷或。
- Failover 節(jié)點(diǎn)的 檢測(cè)過慢，不如 中心節(jié)點(diǎn) ZooKeeper 及時(shí)片任。
- Gossip 消息具有一定開銷偏友。
- 無法根據(jù)統(tǒng)計(jì)區(qū)分 冷熱數(shù)據(jù)。
