客戶端分片

Redis Sharding是Redis Cluster出來之前，業界普遍使用的多Redis實例集群方法。其主要思想是采用哈希算法將Redis數據的key進行散列，通過hash函數，特定的key會映射到特定的Redis節點上。java redis客戶端驅動jedis，支持Redis Sharding功能，即ShardedJedis以及結合緩存池的ShardedJedisPool。

Redis Sentinel提供了主備模式下Redis監控、故障轉移功能達到系統的高可用性。在主Redis宕機時，備Redis接管過來，上升為主Redis，繼續提供服務。主備共同組成一個Redis節點，通過自動故障轉移，保證了節點的高可用性。

客戶端sharding技術其優勢在于非常簡單，服務端的Redis實例彼此獨立，相互無關聯，每個Redis實例像單服務器一樣運行，非常容易線性擴展，系統的靈活性很強。

客戶端sharding的劣勢也是很明顯的。由于sharding處理放到客戶端，規模進一步擴大時給運維帶來挑戰。客戶端sharding不支持動態增刪節點。服務端Redis實例群拓撲結構有變化時，每個客戶端都需要更新調整。連接不能共享，當應用規模增大時，資源浪費制約優化。

基于代理的分片

客戶端發送請求到一個代理組件，代理解析客戶端的數據，并將請求轉發至正確的節點，最后將結果回復給客戶端。

該模式的特性如下：

1.透明接入，業務程序不用關心后端Redis實例，切換成本低。

2.Proxy的邏輯和存儲的邏輯是隔離的。

3.代理層多了一次轉發，性能有所損耗。

簡單的結構圖如下：

主流的組件有：Twemproxy和Codis。

Codis

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

Codis當前最新release版本為codis-3.2，codis-server基于redis-3.2.8。有一下組件組成：

Codis

Codis Server：基于redis-3.2.8分支開發。增加了額外的數據結構，以支持slot有關的操作以及數據遷移指令。

Codis Proxy：客戶端連接的Redis代理服務,實現了Redis協議。除部分命令不支持以外(不支持的命令列表)，表現的和原生的Redis沒有區別（就像Twemproxy）。

Codis Dashboard：集群管理工具，支持codis-proxy、codis-server的添加、刪除，以及據遷移等操作。在集群狀態發生改變時，codis-dashboard維護集群下所有codis-proxy的狀態的一致性。

對于同一個業務集群而言，同一個時刻codis-dashboard只能有0個或者1個；所有對集群的修改都必須通過codis-dashboard完成。

Codis Admin：集群管理的命令行工具。

可用于控制codis-proxy、codis-dashboard狀態以及訪問外部存儲。

Codis FE：集群管理界面。

多個集群實例共享可以共享同一個前端展示頁面；

通過配置文件管理后端codis-dashboard列表，配置文件可自動更新。

Storage：為集群狀態提供外部存儲。

提供Namespace概念，不同集群的會按照不同product name進行組織；目前僅提供了Zookeeper、Etcd、Fs三種實現，但是提供了抽象的interface可自行擴展。

至于具體的安裝與使用，見官網CodisLabs，不在此涉及。

Codis的特性：

Codis支持的命令更加豐富，基本支持redis的命令。

遷移成本低，遷移到codis沒這么麻煩，只要使用的redis命令在codis支持的范圍之內，只要修改一下配置即可接入。

Codis提供的運維工具更加友好，提供web圖形界面管理集群。

支持多核心CPU，twemproxy只能單核

支持group劃分，組內可以設置一個主多個從，通過sentinel監控redis主從，當主down了自動將從切換為主

以上就是對“redis集群教程之實現的幾種方法”的介紹，希望對大家有所幫助，如有疑問，請在線咨詢，有專業老師隨時為你服務。