redis常見的使用方式

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

• Redis單副本;
• Redis多副本(主從) ;
• Redis Sentinel (哨兵) ;
• Redis Cluster;
• Redis自研。

使用場景:
如果數據量很少，主要是承載高并發高性能的場景，比如緩存一般就幾個G的話， 單機足夠了。
主從模式: master節點掛掉后，需要手動指定新的master，可用性不高，基本不用。

哨兵模式: master 節點掛掉后，哨兵進程會主動選舉新的master,可用性高，但是每個節點存儲的數據是一樣的，浪費內存空間。數據量不是很多，集群規模不是很大，需要自動容錯容災的時候使用。

Redis cluster主要是針對海量數據+高并發+高可用的場景，如果是海量數據，如果你的數據量很大，那么建議就用Redis cluster，所有master的容量總和就是Redis cluster可緩存的數據容量。

redis單副本

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

多副本（主從）

? Redis多副本，采用主從(replication) 部署結構，相較于單副本而言最大的特點就是主從實例間數據實時同步，并且提供數據持久化和備份策略。主從實例部署在不同的物理服務器上，根據公司的基礎環境配置，可以實現同時對外提供服務和讀寫分離策略。

優點：

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

缺點:

• 故障恢復復雜，如果沒有RedisHA系統(需要開發)，當主庫節點出現故障時，需要手動將一個從
  節點晉升為主節點，同時需要通知業務方變更配置，并且需要讓其它從庫節點去復制新主庫節點，整個過程需要人為干預，比較繁瑣;
• 主庫的寫能力受到單機的限制，可以考慮分片;
• 主庫的存儲能力受到單機的限制，可以考慮Pika;
• 原生復制的弊端在早期的版本中也會比較突出，如: Redis 復制中斷后，Slave 會發起psync,此時如果同步不成功，則會進行全量同步，主庫執行全量備份的同時可能會造成毫秒或秒級的卡頓；又由于COW機制，導致極端情況下的主庫內存溢出，程序異常退出或宕機；主庫節點生成備份文件導致服務器磁盤IO和CPU (壓縮)資源消耗；發送數GB大小的備份文件導致服務器出口帶寬暴增，阻塞請求，建議升級到最新版本。

哨兵（sentinel）

主從模式下，當主服務器宕機后，需要手動把一臺從服務器切換為主服務器，這就需要人工千預，費事費力，還會造成一段時間內服務不可用。這種方式并不推薦，實際生產中，我們優先考慮哨兵模式。這種模式下，master
宕機，哨兵會自動選舉master并將其他的slave指向新的master。

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的從節點有對節點做主觀下線操作，并不執行故障轉
  移。
• 不能解決讀寫分離問題，實現起來相對復雜。

Redis哨 兵是怎么工作的?

1.每個Sentinel以每秒鐘一次的頻率向它所知的Master，Slave以及 其他Sentinel實例發送一個
PING命令。

2.如果一個實例(instance) 距離最后一次有效回復PING命令的時間超過down-after-milliseconds
選項所指定的值，則這個實例會被當前Sentinel標記為主觀下線。

3.如果一個Master被標記為主觀下線，則正在監視這個Master的所有Sentinel要以每秒一次的頻率
確認Master的確進入了主觀下線狀態。

4.當有足夠數量的Sentinel (大于等于配置文件指定的值)在指定的時間范圍內確認Master的確進入
了主觀下線狀態，則Master 會被標記為客觀下線。

5.當Master被Sentinel標記為客觀下線時，Sentinel 向下線的Master的所有Slave發送INFO命令的頻率會從10秒一次改為每秒一次(在一般情況下，每個Sentinel會以每10秒一次的頻率向它已知的所有Master，Slave發送INFO命令)。

6.若沒有足夠數量的Sentinel同意Master已經下線，Master 的客觀下線狀態就會變成主觀下線。若Master重新向Sentinel的PING命令返回有效回復，Master 的主觀下線狀態就會被移除。

7.sentinel節點會與其他sentinel節點進行“溝通”，投票選舉- - 個sentine|節點進行故障處理，在從節
點中選取一個主節點，其他從節點掛載到新的主節點上自動復制新主節點的數據。

集群（cluster）

Redis的哨兵模式基本已經可以實現高可用，讀寫分離，但是在這種模式下每臺Redis服務器都存儲相同的數據，很浪費內存，所以在Redis3.0.上加入了Cluster集群模式，實現了Redis的分布式存儲，對數據進行分片，也就是說每臺Redis節點上存儲不同的內容。

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

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

Redis Cluster采用虛擬槽分區，所有的鍵根據哈希函數映射到0~ 16383個整數槽內，每個節點負責維護
一部分槽以及槽所印映射的鍵值數據。

總結

以上是生活随笔為你收集整理的redis—主从，哨兵，集群的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。