原作者：張東洪

常見的使用方式

Redis的幾種常見的使用方式包括：

        Redis 單副本

        Redis 多副本（主從）

        Redis Sentinel（哨兵）

        Redis Cluster

        Redis 自研

各種使用的優缺點

Redis 單副本

Redis 單副本，採用單個Redis節點部署架構，沒有備用節點實時同步資料，不提供資料持久化和備份策略，適用於資料可靠性要求不高的純快取業務場景。

優點

• 架構簡單，部署方便。
• 高性價比：快取使用時無需備用節點（單例項可用性可以用supervisor或crontab保證），當然為了滿足業務的高可用性，也可以犧牲一個備用節點，但同一時刻只有一個例項對外提供服務。
• 高效能。

缺點

• 不保證資料的可靠性。
• 在快取使用，程序重啟後，資料丟失，即使有備用的節點解決高效能，但是仍然不能解決快取預熱問題，因此不適用於資料可靠性要求高的業務。
• 高效能受限於單核CPU的處理能力（Redis是單執行緒機制），CPU為主要瓶頸，所以適合操作命令簡單，排序，計算較少的場景。也可以考慮用memcached替代。

Redis 多副本（主從）

Redis 多副本，採用主從（replication）部署結構，相較於單副本而言最大的特點就是主從例項間資料實時同步，並且提供資料持久化和備份策略。

主從例項部署在不同的物理伺服器上，根據公司的基礎環境配置，可以實現同時對外提供服務和讀寫分離策略。

優點

• 高可靠性：一方面，採用雙擊主備架構，能夠在主庫出現故障時自動進行主備切換，從庫提升為主庫提供服務，保證服務平穩執行；另一方面，開啟資料持久化功能和配置合理的備份策略，能有效的解決資料誤操作和資料異常丟失的問題。
• 讀寫分離策略：從節點可以擴充套件主庫節點的讀能力，有效應對大併發量的讀操作。

缺點

• 故障恢復複雜，如果沒有Redis HA 系統（需要開發），當主庫節點出現故障時，需要手動將一個從節點晉升為主節點，同時需要通知業務方變更配置，並且需要讓其他從庫節點去複製新主庫節點，整個過程需要人為干預，比較繁瑣。
• 主庫的寫能力受到單機的限制，可以考慮分片。
• 主庫的儲存能力受到單機的限制，可以考慮Pika。
• 原生複製的弊端在早期的版本中也會比價突出，如：Redis 複製中斷後，Slave 會發起 psync ，此時如果同步不成功，則會進行全量同步，主庫執行全量備份的同時，可能會造成毫秒或秒級的卡頓。
• 又由於COW 機制，導致極端情況下的主庫記憶體溢位，程式異常退出或宕機；主庫節點生成備份檔案導致伺服器磁碟IO和CPU 資源消耗；傳送數GB 大小的備份檔案導致伺服器出口頻寬暴增，阻塞請求，建議升級到最新版本。

Redis Sentinel（哨兵）

Redis Sentinel 是社群版本推出的原生高可用解決方案，其部署架構主要包括兩部分：Redis Sentinel 叢集和 Redis 資料叢集。

其中Redis Sentinel 叢集是由若干Sentinel 節點組成的分散式叢集，可以實現故障發現，故障自動轉移，配置中心和客戶端通知。Redis Sentinel 的節點數量要滿足 2n + 1 （n>=1）的奇數個。

優點

• Redis Sentinel 叢集部署簡單；
• 能夠解決 Redis 主從模式下的高可用切換問題；
• 很方便實現 Redis 資料節點的線形擴充套件，輕鬆突破 Redis 自身單執行緒瓶頸，可極大滿足 Redis 大容量或高效能的業務需求；
• 可以實現一套 Sentinel 監控一組 Redis 資料節點或多組資料節點。

缺點

• 部署相對 Redis 主從模式要複雜一些，原理理解更繁瑣；
• 資源浪費，Redis 資料節點中 slave 節點作為備份節點不提供服務；
• Redis Sentinel 主要是針對 Redis 資料節點中的主節點的高可用切換，對 Redis 的資料節點做失敗判定分為主觀下線和客觀下線兩種，對於 Redis 的從節點有對節點做主觀下線操作，並不執行故障轉移。
• 不能解決讀寫分離問題，實現起來相對複雜。

建議

• 如果監控同一業務，可以選擇一套 Sentinel 叢集監控多組 Redis 資料節點的方案，反之選擇一套 Sentinel 監控一組 Redis 資料節點的方案。
• sentinel monitor <master-name> <ip> <port> <quorum> 配置中的<quorum>建議設定成 Sentinel 節點的一半加 1，當 Sentinel 部署在多個 IDC 的時候，單個 IDC 部署的 Sentinel 數量不建議超過（Sentinel 數量 – quorum）。
• 合理設定引數，防止誤切，控制切換靈敏度控制：

1. quorum
2. down-after-milliseconds 30000
3. failover-timeout 180000
4. maxclient
5. timeout

• 部署的各個節點伺服器時間儘量要同步，否則日誌的時序性會混亂。
• Redis 建議使用 pipeline 和 multi-keys 操作，減少 RTT 次數，提高請求效率。
• 自行搞定配置中心（zookeeper），方便客戶端對例項的連結訪問。

Redis Cluster

Redis Cluster 是社群版推出的 Redis 分散式叢集解決方案，主要解決 Redis 分散式方面的需求，比如，當遇到單機記憶體，併發和流量等瓶頸的時候，Redis Cluster 能起到很好的負載均衡的目的。

Redis Cluster 叢集節點最小配置 6 個節點以上（3 主 3 從），其中主節點提供讀寫操作，從節點作為備用節點，不提供請求，只作為故障轉移使用。

Redis Cluster 採用虛擬槽分割槽，所有的鍵根據雜湊函式對映到 0～16383 個整數槽內，每個節點負責維護一部分槽以及槽所對映的鍵值資料。

優點

• 無中心架構；
• 資料按照 slot 儲存分佈在多個節點，節點間資料共享，可動態調整資料分佈；
• 可擴充套件性：可線性擴充套件到 1000 多個節點，節點可動態新增或刪除；
• 高可用性：部分節點不可用時，叢集仍可用。通過增加 Slave 做 standby 資料副本，能夠實現故障自動 failover，節點之間通過 gossip 協議交換狀態資訊，用投票機制完成 Slave 到 Master 的角色提升；
• 降低運維成本，提高系統的擴充套件性和可用性。

缺點

• Client 實現複雜，驅動要求實現 Smart Client，快取 slots mapping 資訊並及時更新，提高了開發難度，客戶端的不成熟影響業務的穩定性。目前僅 JedisCluster 相對成熟，異常處理部分還不完善，比如常見的“max redirect exception”。
• 節點會因為某些原因發生阻塞（阻塞時間大於 clutser-node-timeout），被判斷下線，這種 failover 是沒有必要的。
• 資料通過非同步複製，不保證資料的強一致性。
• 多個業務使用同一套叢集時，無法根據統計區分冷熱資料，資源隔離性較差，容易出現相互影響的情況。
• Slave 在叢集中充當“冷備”，不能緩解讀壓力，當然可以通過 SDK 的合理設計來提高 Slave 資源的利用率。
• Key 批量操作限制，如使用 mset、mget 目前只支援具有相同 slot 值的 Key 執行批量操作。對於對映為不同 slot 值的 Key 由於 Keys 不支援跨 slot 查詢，所以執行 mset、mget、sunion 等操作支援不友好。
• Key 事務操作支援有限，只支援多 key 在同一節點上的事務操作，當多個 Key 分佈於不同的節點上時無法使用事務功能。
• Key 作為資料分割槽的最小粒度，不能將一個很大的鍵值物件如 hash、list 等對映到不同的節點。
• 不支援多資料庫空間，單機下的 redis 可以支援到 16 個數據庫，叢集模式下只能使用 1 個數據庫空間，即db  0 。
• 複製結構只支援一層，從節點只能複製主節點，不支援巢狀樹狀複製結構。
• 避免產生 hot-key，導致主庫節點成為系統的短板。
• 避免產生 big-key，導致網絡卡撐爆、慢查詢等。
• 重試時間應該大於 cluster-node-time 時間。
• Redis Cluster 不建議使用 pipeline和multi-keys 操作，減少 max redirect 產生的場景。

Redis 自研

Redis 自研的高可用解決方案，主要體現在配置中心、故障探測和 failover 的處理機制上，通常需要根據企業業務的實際線上環境來定製化。

優點

• 高可靠性、高可用性；
• 自主可控性高；
• 貼合業務實際需求，可縮性好，相容性好。

缺點

• 實現複雜，開發成本高；
• 需要建立配套的周邊設施，如監控，域名服務，儲存元資料資訊的資料庫等；
• 維護成本高。