Redis 單機模式,主從模式,哨兵模式(sentinel),叢集模式(cluster)優缺點分析
阿新 • • 發佈:2020-12-28
Redis 的幾種常見使用方式包括:
- 單機模式
- 主從模式
- 哨兵模式(sentinel)
- 叢集模式(cluster)
- 第三方模式
單機模式
Redis 單副本,採用單個 Redis 節點部署架構,沒有備用節點實時同步資料,不提供資料持久化和備份策略,適用於資料可靠性要求不高的純快取業務場景。
優點:
- 架構簡單,部署方便。
- 高性價比:快取使用時無需備用節點(單例項可用性可以用 supervisor 或 crontab 保證),當然為了滿足業務的高可用性,也可以犧牲一個備用節點,但同時刻只有一個例項對外提供服務。
- 高效能。
缺點:
- 不保證資料的可靠性。
- 在快取使用,程序重啟後,資料丟失,即使有備用的節點解決高可用性,但是仍然不能解決快取預熱問題,因此不適用於資料可靠性要求高的業務。
- 高效能受限於單核 CPU 的處理能力(Redis 是單執行緒機制),CPU 為主要瓶頸,所以適合操作命令簡單,排序、計算較少的場景。也可以考慮用 Memcached 替代。
主從模式
Redis 採用主從(可以多從)部署結構,相較於單副本而言最大的特點就是主從例項間資料實時同步,並且提供資料持久化和備份策略。主從例項部署在不同的物理伺服器上,根據公司的基礎環境配置,可以實現同時對外提供服務和讀寫分離策略。
優點:
- 高可靠性:一方面,採用雙機主備架構,能夠在主庫出現故障時自動進行主備切換,從庫提升為主庫提供服務,保證服務平穩執行;另一方面,開啟資料持久化功能和配置合理的備份策略,能有效的解決資料誤操作和資料異常丟失的問題。
- 讀寫分離策略:從節點可以擴充套件主庫節點的讀能力,有效應對大併發量的讀操作。
缺點:
- 故障恢復複雜,如果沒有 RedisHA 系統(需要開發),當主庫節點出現故障時,需要手動將一個從節點晉升為主節點,同時需要通知業務方變更配置,並且需要讓其它從庫節點去複製新主庫節點,整個過程需要人為干預,比較繁瑣。
- 主庫的寫能力受到單機的限制,可以考慮分片。
- 主庫的儲存能力受到單機的限制,可以考慮 Pika。
- 原生複製的弊端在早期的版本中也會比較突出,如:Redis 複製中斷後,Slave 會發起 psync,此時如果同步不成功,則會進行全量同步,主庫執行全量備份的同時可能會造成毫秒或秒級的卡頓;又由於 COW 機制,導致極端情況下的主庫記憶體溢位,程式異常退出或宕機;主庫節點生成備份檔案導致伺服器磁碟 IO 和 CPU(壓縮)資源消耗;傳送數 GB 大小的備份檔案導致伺服器出口頻寬暴增,阻塞請求,建議升級到最新版本。
哨兵模式
Redis Sentinel 是 2.8 版本後推出的原生高可用解決方案,其部署架構主要包括兩部分: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 的從節點有對節點做主觀下線操作,並不執行故障轉移。
- 不能解決讀寫分離問題,實現起來相對複雜。
叢集模式
Redis Cluster 是 3.0 版後推出的 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 產生的場景。
優點多,缺點也多啊,事物都有雙面性。
第三方模式
第三方模式比較少,已知的有 codis,但是好像有段時間沒更新了。