您好,登錄后才能下訂單哦!
小編給大家分享一下Redis高可用技術(shù)解決方案有哪些,相信大部分人都還不怎么了解,因此分享這篇文章給大家參考一下,希望大家閱讀完這篇文章后大有收獲,下面讓我們一起去了解一下吧!
本文主要針對(duì)Redis常見(jiàn)的幾種使用方式及其優(yōu)缺點(diǎn)展開(kāi)分析。
一、常見(jiàn)使用方式
Redis的幾種常見(jiàn)使用方式包括:
Redis單副本;
Redis多副本(主從);
Redis Sentinel(哨兵);
Redis Cluster;
Redis自研。
二、各種使用方式的優(yōu)缺點(diǎn)
1、Redis單副本
Redis單副本,采用單個(gè)Redis節(jié)點(diǎn)部署架構(gòu),沒(méi)有備用節(jié)點(diǎn)實(shí)時(shí)同步數(shù)據(jù),不提供數(shù)據(jù)持久化和備份策略,適用于數(shù)據(jù)可靠性要求不高的純緩存業(yè)務(wù)場(chǎng)景。
優(yōu)點(diǎn):
架構(gòu)簡(jiǎn)單,部署方便;
高性價(jià)比:緩存使用時(shí)無(wú)需備用節(jié)點(diǎn)(單實(shí)例可用性可以用supervisor或crontab保證),當(dāng)然為了滿足業(yè)務(wù)的高可用性,也可以犧牲一個(gè)備用節(jié)點(diǎn),但同時(shí)刻只有一個(gè)實(shí)例對(duì)外提供服務(wù);
高性能。
缺點(diǎn):
不保證數(shù)據(jù)的可靠性;
在緩存使用,進(jìn)程重啟后,數(shù)據(jù)丟失,即使有備用的節(jié)點(diǎn)解決高可用性,但是仍然不能解決緩存預(yù)熱問(wèn)題,因此不適用于數(shù)據(jù)可靠性要求高的業(yè)務(wù);
高性能受限于單核CPU的處理能力(Redis是單線程機(jī)制),CPU為主要瓶頸,所以適合操作命令簡(jiǎn)單,排序、計(jì)算較少的場(chǎng)景。也可以考慮用Memcached替代。
2、Redis多副本(主從)
Redis多副本,采用主從(replication)部署結(jié)構(gòu),相較于單副本而言最大的特點(diǎn)就是主從實(shí)例間數(shù)據(jù)實(shí)時(shí)同步,并且提供數(shù)據(jù)持久化和備份策略。主從實(shí)例部署在不同的物理服務(wù)器上,根據(jù)公司的基礎(chǔ)環(huán)境配置,可以實(shí)現(xiàn)同時(shí)對(duì)外提供服務(wù)和讀寫分離策略。
優(yōu)點(diǎn):
高可靠性:一方面,采用雙機(jī)主備架構(gòu),能夠在主庫(kù)出現(xiàn)故障時(shí)自動(dòng)進(jìn)行主備切換,從庫(kù)提升為主庫(kù)提供服務(wù),保證服務(wù)平穩(wěn)運(yùn)行;另一方面,開(kāi)啟數(shù)據(jù)持久化功能和配置合理的備份策略,能有效的解決數(shù)據(jù)誤操作和數(shù)據(jù)異常丟失的問(wèn)題;
讀寫分離策略:從節(jié)點(diǎn)可以擴(kuò)展主庫(kù)節(jié)點(diǎn)的讀能力,有效應(yīng)對(duì)大并發(fā)量的讀操作。
缺點(diǎn):
故障恢復(fù)復(fù)雜,如果沒(méi)有RedisHA系統(tǒng)(需要開(kāi)發(fā)),當(dāng)主庫(kù)節(jié)點(diǎn)出現(xiàn)故障時(shí),需要手動(dòng)將一個(gè)從節(jié)點(diǎn)晉升為主節(jié)點(diǎn),同時(shí)需要通知業(yè)務(wù)方變更配置,并且需要讓其它從庫(kù)節(jié)點(diǎn)去復(fù)制新主庫(kù)節(jié)點(diǎn),整個(gè)過(guò)程需要人為干預(yù),比較繁瑣;
主庫(kù)的寫能力受到單機(jī)的限制,可以考慮分片;
主庫(kù)的存儲(chǔ)能力受到單機(jī)的限制,可以考慮Pika;
原生復(fù)制的弊端在早期的版本中也會(huì)比較突出,如:Redis復(fù)制中斷后,Slave會(huì)發(fā)起psync,此時(shí)如果同步不成功,則會(huì)進(jìn)行全量同步,主庫(kù)執(zhí)行全量備份的同時(shí)可能會(huì)造成毫秒或秒級(jí)的卡頓;又由于COW機(jī)制,導(dǎo)致極端情況下的主庫(kù)內(nèi)存溢出,程序異常退出或宕機(jī);主庫(kù)節(jié)點(diǎn)生成備份文件導(dǎo)致服務(wù)器磁盤IO和CPU(壓縮)資源消耗;發(fā)送數(shù)GB大小的備份文件導(dǎo)致服務(wù)器出口帶寬暴增,阻塞請(qǐng)求,建議升級(jí)到最新版本。
3、Redis Sentinel(哨兵)
Redis Sentinel是社區(qū)版本推出的原生高可用解決方案,其部署架構(gòu)主要包括兩部分:Redis Sentinel集群和Redis數(shù)據(jù)集群。
其中Redis Sentinel集群是由若干Sentinel節(jié)點(diǎn)組成的分布式集群,可以實(shí)現(xiàn)故障發(fā)現(xiàn)、故障自動(dòng)轉(zhuǎn)移、配置中心和客戶端通知。Redis Sentinel的節(jié)點(diǎn)數(shù)量要滿足2n+1(n>=1)的奇數(shù)個(gè)。
優(yōu)點(diǎn):
Redis Sentinel集群部署簡(jiǎn)單;
能夠解決Redis主從模式下的高可用切換問(wèn)題;
很方便實(shí)現(xiàn)Redis數(shù)據(jù)節(jié)點(diǎn)的線形擴(kuò)展,輕松突破Redis自身單線程瓶頸,可極大滿足Redis大容量或高性能的業(yè)務(wù)需求;
可以實(shí)現(xiàn)一套Sentinel監(jiān)控一組Redis數(shù)據(jù)節(jié)點(diǎn)或多組數(shù)據(jù)節(jié)點(diǎn)。
缺點(diǎn):
部署相對(duì)Redis主從模式要復(fù)雜一些,原理理解更繁瑣;
資源浪費(fèi),Redis數(shù)據(jù)節(jié)點(diǎn)中slave節(jié)點(diǎn)作為備份節(jié)點(diǎn)不提供服務(wù);
Redis Sentinel主要是針對(duì)Redis數(shù)據(jù)節(jié)點(diǎn)中的主節(jié)點(diǎn)的高可用切換,對(duì)Redis的數(shù)據(jù)節(jié)點(diǎn)做失敗判定分為主觀下線和客觀下線兩種,對(duì)于Redis的從節(jié)點(diǎn)有對(duì)節(jié)點(diǎn)做主觀下線操作,并不執(zhí)行故障轉(zhuǎn)移。
不能解決讀寫分離問(wèn)題,實(shí)現(xiàn)起來(lái)相對(duì)復(fù)雜。
建議:
如果監(jiān)控同一業(yè)務(wù),可以選擇一套Sentinel集群監(jiān)控多組Redis數(shù)據(jù)節(jié)點(diǎn)的方案,反之選擇一套Sentinel監(jiān)控一組Redis數(shù)據(jù)節(jié)點(diǎn)的方案。
sentinel monitor 配置中的建議設(shè)置成Sentinel節(jié)點(diǎn)的一半加1,當(dāng)Sentinel部署在多個(gè)IDC的時(shí)候,單個(gè)IDC部署的Sentinel數(shù)量不建議超過(guò)(Sentinel數(shù)量 – quorum)。
合理設(shè)置參數(shù),防止誤切,控制切換靈敏度控制:
a. quorum
b. down-after-milliseconds 30000
c. failover-timeout 180000
d. maxclient
e. timeout
部署的各個(gè)節(jié)點(diǎn)服務(wù)器時(shí)間盡量要同步,否則日志的時(shí)序性會(huì)混亂。
Redis建議使用pipeline和multi-keys操作,減少RTT次數(shù),提高請(qǐng)求效率。
自行搞定配置中心(zookeeper),方便客戶端對(duì)實(shí)例的鏈接訪問(wèn)。
4、Redis Cluster
Redis Cluster是社區(qū)版推出的Redis分布式集群解決方案,主要解決Redis分布式方面的需求,比如,當(dāng)遇到單機(jī)內(nèi)存,并發(fā)和流量等瓶頸的時(shí)候,Redis Cluster能起到很好的負(fù)載均衡的目的。
Redis Cluster集群節(jié)點(diǎn)最小配置6個(gè)節(jié)點(diǎn)以上(3主3從),其中主節(jié)點(diǎn)提供讀寫操作,從節(jié)點(diǎn)作為備用節(jié)點(diǎn),不提供請(qǐng)求,只作為故障轉(zhuǎn)移使用。
Redis Cluster采用虛擬槽分區(qū),所有的鍵根據(jù)哈希函數(shù)映射到0~16383個(gè)整數(shù)槽內(nèi),每個(gè)節(jié)點(diǎn)負(fù)責(zé)維護(hù)一部分槽以及槽所印映射的鍵值數(shù)據(jù)。
優(yōu)點(diǎn):
無(wú)中心架構(gòu);
數(shù)據(jù)按照slot存儲(chǔ)分布在多個(gè)節(jié)點(diǎn),節(jié)點(diǎn)間數(shù)據(jù)共享,可動(dòng)態(tài)調(diào)整數(shù)據(jù)分布;
可擴(kuò)展性:可線性擴(kuò)展到1000多個(gè)節(jié)點(diǎn),節(jié)點(diǎn)可動(dòng)態(tài)添加或刪除;
高可用性:部分節(jié)點(diǎn)不可用時(shí),集群仍可用。通過(guò)增加Slave做standby數(shù)據(jù)副本,能夠?qū)崿F(xiàn)故障自動(dòng)failover,節(jié)點(diǎn)之間通過(guò)gossip協(xié)議交換狀態(tài)信息,用投票機(jī)制完成Slave到Master的角色提升;
降低運(yùn)維成本,提高系統(tǒng)的擴(kuò)展性和可用性。
缺點(diǎn):
Client實(shí)現(xiàn)復(fù)雜,驅(qū)動(dòng)要求實(shí)現(xiàn)Smart Client,緩存slots mapping信息并及時(shí)更新,提高了開(kāi)發(fā)難度,客戶端的不成熟影響業(yè)務(wù)的穩(wěn)定性。目前僅JedisCluster相對(duì)成熟,異常處理部分還不完善,比如常見(jiàn)的“max redirect exception”。
節(jié)點(diǎn)會(huì)因?yàn)槟承┰虬l(fā)生阻塞(阻塞時(shí)間大于clutser-node-timeout),被判斷下線,這種failover是沒(méi)有必要的。
數(shù)據(jù)通過(guò)異步復(fù)制,不保證數(shù)據(jù)的強(qiáng)一致性。
多個(gè)業(yè)務(wù)使用同一套集群時(shí),無(wú)法根據(jù)統(tǒng)計(jì)區(qū)分冷熱數(shù)據(jù),資源隔離性較差,容易出現(xiàn)相互影響的情況。
Slave在集群中充當(dāng)“冷備”,不能緩解讀壓力,當(dāng)然可以通過(guò)SDK的合理設(shè)計(jì)來(lái)提高Slave資源的利用率。
Key批量操作限制,如使用mset、mget目前只支持具有相同slot值的Key執(zhí)行批量操作。對(duì)于映射為不同slot值的Key由于Keys不支持跨slot查詢,所以執(zhí)行mset、mget、sunion等操作支持不友好。
Key事務(wù)操作支持有限,只支持多key在同一節(jié)點(diǎn)上的事務(wù)操作,當(dāng)多個(gè)Key分布于不同的節(jié)點(diǎn)上時(shí)無(wú)法使用事務(wù)功能。
Key作為數(shù)據(jù)分區(qū)的最小粒度,不能將一個(gè)很大的鍵值對(duì)象如hash、list等映射到不同的節(jié)點(diǎn)。
不支持多數(shù)據(jù)庫(kù)空間,單機(jī)下的redis可以支持到16個(gè)數(shù)據(jù)庫(kù),集群模式下只能使用1個(gè)數(shù)據(jù)庫(kù)空間,即db 0。
復(fù)制結(jié)構(gòu)只支持一層,從節(jié)點(diǎn)只能復(fù)制主節(jié)點(diǎn),不支持嵌套樹(shù)狀復(fù)制結(jié)構(gòu)。
避免產(chǎn)生hot-key,導(dǎo)致主庫(kù)節(jié)點(diǎn)成為系統(tǒng)的短板。
避免產(chǎn)生big-key,導(dǎo)致網(wǎng)卡撐爆、慢查詢等。
重試時(shí)間應(yīng)該大于cluster-node-time時(shí)間。
Redis Cluster不建議使用pipeline和multi-keys操作,減少max redirect產(chǎn)生的場(chǎng)景。
5、Redis自研
Redis自研的高可用解決方案,主要體現(xiàn)在配置中心、故障探測(cè)和failover的處理機(jī)制上,通常需要根據(jù)企業(yè)業(yè)務(wù)的實(shí)際線上環(huán)境來(lái)定制化。
優(yōu)點(diǎn):
高可靠性、高可用性;
自主可控性高;
貼切業(yè)務(wù)實(shí)際需求,可縮性好,兼容性好。
缺點(diǎn):
實(shí)現(xiàn)復(fù)雜,開(kāi)發(fā)成本高;
需要建立配套的周邊設(shè)施,如監(jiān)控,域名服務(wù),存儲(chǔ)元數(shù)據(jù)信息的數(shù)據(jù)庫(kù)等;
維護(hù)成本高。
以上是“Redis高可用技術(shù)解決方案有哪些”這篇文章的所有內(nèi)容,感謝各位的閱讀!相信大家都有了一定的了解,希望分享的內(nèi)容對(duì)大家有所幫助,如果還想學(xué)習(xí)更多知識(shí),歡迎關(guān)注億速云行業(yè)資訊頻道!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。