前言

如果Redis的讀寫請求量很大，那么單個實例很有可能承擔不了這么大的請求量，如何提高Redis的性能呢？你也許已經想到了，可以部署多個副本節點，業務采用讀寫分離的方式，把讀請求分擔到多個副本節點上，提高訪問性能。要實現讀寫分離，就必須部署多個副本，每個副本需要實時同步主節點的數據。

1. 單機模式

Redis 單副本，采用單個 Redis 節點部署架構，沒有備用節點實時同步數據，不提供數據持久化和備份策略，適用于數據可靠性要求不高的純緩存業務場景。

• 優點：

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

• 缺點：

  • 不保證數據的可靠性。
  • 在緩存使用，進程重啟后，數據丟失，即使有備用的節點解決高可用性，但是仍然不能解決緩存預熱問題，因此不適用于數據可靠性要求高的業務。
  • 高性能受限于單核 CPU 的處理能力(Redis 是單線程機制)，CPU 為主要瓶頸，所以適合操作命令簡單，排序、計算較少的場景。也可以考慮用 Memcached 替代。

2. 主從架構

主（master）和 從（slave）部署在不同的服務器上，當主節點服務器寫入數據時會同步到從節點的服務器上，一般主節點負責寫入數據，從節點負責讀取數據。

從節點設置只讀屬性，而主節點沒有只寫屬性，因此，主節點可讀可以寫

• 優點：

  • 讀寫分離，提高效率
    主節點負責寫操作，從節點負責讀操作；如果寫少讀多場景，配置多個從節點的話，效率非常高
  • 數據熱備份，提供多個副本。
    從節點宕機，影響較小

• 缺點：

  • 主節點故障，集群則無法進行工作，可用性比較低，從節點升主節點需要人工手動干預。

    因為只有主節點能進行寫操作，一旦主節點宕機，整個服務就無法使用。當然此時從節點仍可以進行讀操作，但是對于整個服務流程來說，是無法使用的。

  • Master的寫的壓力難以降低。

    如果寫操作比較多，那么只有一個主節點的話，無法分擔壓力。

  • 主節點存儲能力受到單擊限制。

    主節點只能有一個，因此單節點內存大小不會太大，因此存儲數據量受限。

  • 主從數據同步，可能產生部分的性能影響甚至同步風暴。

風暴問題，對于任何集群分布式來說都存在，要合理分布節點。

3. 哨兵

為了解決這兩個問題，在2.8版本之后redis正式提供了sentinel架構。

在redis3.0以前的版本要實現集群一般是借助哨兵sentinel工具來監控master節點的狀態。

如果master節點異常，則會做主從切換，將某一臺slave作為master，哨兵的配置略微復雜，并且性能和高可用性等各方面表現一般。

• 優點：

  • 對節點進行監控，來完成自動的故障發現與轉移

• 缺點：

  • 特別是在主從切換的瞬間存在訪問瞬斷的情況，等待時間比較長，至少十來秒不可用。
  • 哨兵模式只有一個主節點對外提供服務，沒法支持很高的并發
  • 單個主節點內存也不宜設置得過大，否則會導致持久化文件過大，影響數據恢復或主從同步的效率。

與主從相比，哨兵僅解決了手動切換主從節點問題，至于其他的問題，基本上仍然存在。

哨兵的主要問題還是由于中心架構，僅存在一個master節點引起的，寫的效率太低。

4. 集群模式

Redis Cluster 是 3.0 版后推出的 Redis 分布式集群解決方案，主要解決 Redis 分布式方面的需求，比如，當遇到單機內存，并發和流量等瓶頸的時候，Redis Cluster 能起到很好的負載均衡的目的。

Redis Cluster 集群節點最小配置 6 個節點以上(3 主 3 從)，其中主節點提供讀寫操作，從節點作為備用節點，不提供請求，只作為故障轉移使用。Redis Cluster 采用虛擬槽分區，所有的鍵根據哈希函數映射到 0～16383 個整數槽內，每個節點負責維護一部分槽以及槽所印映射的鍵值數據。

注意：集群模式下 從節點不提供讀寫，與主從模式不一樣。 總結一下經驗，分布式
場景下：集群模式一般從節點不參與讀寫，僅作為備用節點。而主從一般都要負責讀或寫，都要參與具體的工作。

• 優點：

  • 無中心架構。

    即有多個master節點，不像哨兵模式下僅有一個。這樣寫的壓力就可以分散了；并且存儲量也可以擴展了，因為多個主節點都可以存儲一部分數據，總量要遠大于單主節點架構。
    

  • 數據按照 slot 存儲分布在多個節點，節點間數據共享，可動態調整數據分布。

  • 可擴展性：可線性擴展到 1000 多個節點，節點可動態添加或刪除。

  • 高可用性：部分節點不可用時，集群仍可用。通過增加 Slave 做 standby 數據副本，能夠 實現故障自動 failover，節點之間通過 gossip 協議交換狀態信息，用投票機制完成 Slave 到 Master 的角色提升。

當然，如果某個槽歸屬的小群內都不可用時，整個服務仍然是不可用的！通過cluster-require-full-coverageyes
控制該特性， 默認yes 即需要集群完整，方可對外提供服務，設置為no ，其他的小集群仍然可以對外提供服務。

• 缺點：

  • 如果主節點A和它的從節點A1都宕機了，那么該集群就無法再提供服務了。

總結

本文主要介紹了 Redis 四種集群模式，以及優缺點，總結一下

• 主從模式 可以實現讀寫分離，數據備份。但是并不是「高可用」的
• 哨兵模式 可以看做是主從模式的「高可用」版本，其引入了 Sentinel 對整個 Redis 服務集群進行監控。但是由于只有一個主節點，因此仍然有寫入瓶頸。
• Cluster 模式 不僅提供了高可用的手段，同時數據是分片保存在各個節點中的，可以支持高并發的寫入與讀取。當然實現也是其中最復雜的。