Redis高可用方案對比
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,此時如果同步不成功,則會進行全量同步,主庫執行全量備份的同時可能會造成毫秒或秒級的卡頓。
三. 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)。
- 合理設定引數,防止誤切,控制切換靈敏度控制: a. quorum; b. down-after-milliseconds 30000; c. failover-timeout 180000; d. maxclient; e. 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 的處理機制上,通常需要根據企業業務的實際線上環境來定製化。
優點:
- 高可靠性、高可用性;
- 自主可控性高;
- 貼合業務實際需求,可縮性好,相容性好。
缺點:
- 實現複雜,開發成本高;
- 需要建立配套的周邊設施,如監控,域名服務,儲存元資料資訊的資料庫等;
- 維護成本高。
相關推薦
Redis高可用方案對比
Redis的幾種常見使用方式包括: Redis 單副本 Redis 多副本(主從) Redis Sentinel(哨兵) Redis Cluster Redis 自研 一. Redis 單副本 Redis單副本,採用單個Redis節點部署架構,沒有備用節點實
Redis高可用方案哨兵機制------ 配置文件sentinel.conf詳解
有一個 發生 sim 超時時間 style 通信 配置文件 針對性 mas redis的哨兵機制是官方推薦的一種高可用(HA)方案,我們在使用Redis的主從結構時,如果主節點掛掉,這時是不能自動進行主備切換和通知客戶端主節點下線的。Redis-Sentinel機制主要用三
Redis高可用方案-哨兵與集群
可用 mar slot 解決 ali 發現 -a 物理 架構 Redis高可用方案 一.名詞解釋 二.主從復制 Redis主從復制模式可以將主節點的數據同步給從節點,從而保障當主節點不可達的情況下,從節點可以作為 後備頂上來,並且可以保障數據盡
深入理解Redis高可用方案-Sentinel
Redis Sentinel是Redis的高可用方案。是Redis 2.8中正式引入的。 在之前的主從複製方案中,如果主節點出現問題,需要手動將一個從節點升級為主節點,然後將其它從節點指向新的主節點,並且需要修改應用方主節點的地址。整個過程都需要人工干預。 下面通過日誌具體看看Sentinel的切換流
Redis高可用方案-哨兵與叢集
Redis主從複製模式可以將主節點的資料同步給從節點,從而保障當主節點不可達的情況下,從節點可以作為 後備頂上來,並且可以保障資料儘量不丟失(主從複製可以保障最終一致性)。第二,從節點可以擴充套件主節點的讀 能力,一旦主節點不能支援大規模併發量的讀操作,從節點可以在一定程度上分擔主節點
Windows版本redis高可用方案探究
目錄 前言 前提 搭建redis主從 配置主redis-28380 配置從redis-23381 配置從redis-23382 將redis部署為服務 啟動redis 配置哨兵 啟動哨兵 主從自動切換 動態
理解redis高可用方案
理解並從頭搭建redis叢集 部分開發人員工作當中只是在應用中使用redis,比如用來做資料結果的快取。而且現在有很多不錯的redis客戶端工具(redisson),基本上可以不用關注redis命令就可以完成相當部分的功能。所以可能會對如下這些問題關注點不夠: 如何容災?即
mysql高可用方案對比
MySQL常見高可用方案 1. 概述 我們在考慮MySQL資料庫的高可用的架構時,主要要考慮如下幾方面: Ø 如果資料庫發生了宕機或者意外中斷等故障,能儘快恢復資料庫的可用性,儘可能的減少停機時間,保證業務不會因為資料庫的故障而中斷。 Ø 用作備份、只讀副本等功能的
【獨家】終生受用的Redis高可用技術解決方案大全
帶寬 技術分享 學習 控制 單個 即使 效應 pan 元數據 最近很多朋友向我咨詢關於高可用的方案的優缺點以及如何選擇合適的方案線上使用,剛好最近在給宜人貸,光大銀行做企業內訓的時候也詳細講過,這裏我再整理發出來,供大家參考,如有不妥之處,歡迎批評指正,也歡迎推薦更好的技術
Redis主從復制與高可用方案
安裝配置 失敗 tle nap 腳本 登錄 上線 集群 masters redis簡單介紹 Redis 是完全開源免費的,遵守BSD協議,是一個高性能的key-value數據庫。Redis與其他key – value緩存產品有以下三個特點: 支持數據的持久化,可以將內存中
Redis高可用技術解決方案總結
一、常見使用方式 Redis的幾種常見使用方式包括: Redis單副本; Redis多副本(主從); Redis Sentinel(哨兵); Redis Cluster; Redis自研。 二、各種使用方式的優缺點 1、Redis單副本 Redis單副本
基於Redis Sentinel的Redis叢集(主從&Sharding)高可用方案
本文主要介紹一種通過Jedis&Sentinel實現Redis叢集高可用方案,該方案需要使用Jedis2.2.2及以上版本(強制),Redis2.8及以上版本(可選,Sentinel最早出現在Redis2.4中,Redis2.8中Sentinel更加穩定),Red
這可能是史上最全 Redis 高可用解決方案總結
一、常見使用方式 Redis 的幾種常見使用方式包括: Redis 單副本; Redis 多副本(主從); Redis Sentinel(哨兵); Redis Cluster; Redis 自研。 二、各種使用方式的優缺點 1、Redis 單副本 Redis
Redis高可用詳解:持久化技術及方案選擇
本文將先說明上述幾種技術分別解決了Redis高可用的什麼問題,然後詳細介紹Redis的持久化技術,主要是RDB和AOF兩種持久化方案。在介紹RDB和AOF方案時,不僅介紹其作用及操作方法,同時還會介紹持久化實現的一些原理細節及需要注意的問題。最後,介紹在實際使用中持久化方案的
寫的很全面的Redis高可用技術解決方案大全
很多朋友向我諮詢關於裡面提到的高可用的方案的優缺點以及如何選擇合適的方案線上使用,這裡再整理髮出來,供大家參考,如有不妥之處,歡迎批評指正,也歡迎推薦更好的技術方案。不廢話了,來看看方案吧~ Redis常見的幾種主要使用方式: Redis 單副本 Redis 多副本(主
基於Redis Sentinel主從切換以及Sharding分片的Redis叢集高可用方案
本文主要介紹一種通過Jedis&Sentinel實現Redis叢集高可用方案,該方案需要使用Jedis2.2.2及以上版本(強制),Redis2.8及以上版本(可選,Sentinel最早出現在Redis2.4中,Redis2.8中Sentinel更加穩定),Redis叢集是以分片(Sharding
【方法】Redis叢集生產環境高可用方案實戰過程
佈署方案說明 1、sentinel負責對redis叢集中的主從服務監控、提醒和自動故障轉移 2、redis叢集負責對外提供相關服務 Sentinel原理介紹 原理: s
redis HA高可用方案Sentinel和shard
1、搭建redis-master、redis-slave以及seninel哨兵監控 在最小配置:master、slave各一個節點的情況下,不管是master還是slave down掉一個,“完整的”讀/寫功能都將受影響,這在生產環境中顯然不能接受。幸好redis提供了s
Redis之高可用方案
Redis以其高效的訪問速度著稱。但由於官方還未釋出redis-cluster,而redis的replica又有諸多不便:比如一組master-slave的機器,如果之間有連結瞬段,或者對slave重新執行slaveo
這可能是目前最全的Redis高可用技術解決方案總結
本文主要針對Redis常見的幾種使用方式及其優缺點展開分析。 一、常見使用方式 Redis的幾種常見使用方式包括: Redis單副本; Redis多副本(主從); Redis Sentinel(哨兵); Redis Cluster;