Redis高可用技術(shù)解決方案有哪些-創(chuàng)新互聯(lián)

小編給大家分享一下Redis高可用技術(shù)解決方案有哪些，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

專注于為中小企業(yè)提供成都網(wǎng)站設(shè)計、成都網(wǎng)站制作服務(wù),電腦端+手機(jī)端+微信端的三站合一,更高效的管理,為中小企業(yè)固鎮(zhèn)免費做網(wǎng)站提供優(yōu)質(zhì)的服務(wù)。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上千余家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設(shè)實現(xiàn)規(guī)模擴(kuò)充和轉(zhuǎn)變。

本文主要針對Redis常見的幾種使用方式及其優(yōu)缺點展開分析。

一、常見使用方式

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

Redis單副本；

Redis多副本（主從）；

Redis Sentinel（哨兵）；

Redis Cluster；

Redis自研。

二、各種使用方式的優(yōu)缺點

1、Redis單副本

Redis單副本，采用單個Redis節(jié)點部署架構(gòu)，沒有備用節(jié)點實時同步數(shù)據(jù)，不提供數(shù)據(jù)持久化和備份策略，適用于數(shù)據(jù)可靠性要求不高的純緩存業(yè)務(wù)場景。

優(yōu)點：

架構(gòu)簡單，部署方便；

高性價比：緩存使用時無需備用節(jié)點（單實例可用性可以用supervisor或crontab保證），當(dāng)然為了滿足業(yè)務(wù)的高可用性，也可以犧牲一個備用節(jié)點，但同時刻只有一個實例對外提供服務(wù)；

高性能。

缺點：

不保證數(shù)據(jù)的可靠性；

在緩存使用，進(jìn)程重啟后，數(shù)據(jù)丟失，即使有備用的節(jié)點解決高可用性，但是仍然不能解決緩存預(yù)熱問題，因此不適用于數(shù)據(jù)可靠性要求高的業(yè)務(wù)；

高性能受限于單核CPU的處理能力（Redis是單線程機(jī)制），CPU為主要瓶頸，所以適合操作命令簡單，排序、計算較少的場景。也可以考慮用Memcached替代。

2、Redis多副本（主從）

Redis多副本，采用主從（replication）部署結(jié)構(gòu)，相較于單副本而言大的特點就是主從實例間數(shù)據(jù)實時同步，并且提供數(shù)據(jù)持久化和備份策略。主從實例部署在不同的物理服務(wù)器上，根據(jù)公司的基礎(chǔ)環(huán)境配置，可以實現(xiàn)同時對外提供服務(wù)和讀寫分離策略。

優(yōu)點：

高可靠性：一方面，采用雙機(jī)主備架構(gòu)，能夠在主庫出現(xiàn)故障時自動進(jìn)行主備切換，從庫提升為主庫提供服務(wù)，保證服務(wù)平穩(wěn)運(yùn)行；另一方面，開啟數(shù)據(jù)持久化功能和配置合理的備份策略，能有效的解決數(shù)據(jù)誤操作和數(shù)據(jù)異常丟失的問題；

讀寫分離策略：從節(jié)點可以擴(kuò)展主庫節(jié)點的讀能力，有效應(yīng)對大并發(fā)量的讀操作。

缺點：

故障恢復(fù)復(fù)雜，如果沒有RedisHA系統(tǒng)（需要開發(fā)），當(dāng)主庫節(jié)點出現(xiàn)故障時，需要手動將一個從節(jié)點晉升為主節(jié)點，同時需要通知業(yè)務(wù)方變更配置，并且需要讓其它從庫節(jié)點去復(fù)制新主庫節(jié)點，整個過程需要人為干預(yù)，比較繁瑣；

主庫的寫能力受到單機(jī)的限制，可以考慮分片；

主庫的存儲能力受到單機(jī)的限制，可以考慮Pika；

原生復(fù)制的弊端在早期的版本中也會比較突出，如：Redis復(fù)制中斷后，Slave會發(fā)起psync，此時如果同步不成功，則會進(jìn)行全量同步，主庫執(zhí)行全量備份的同時可能會造成毫秒或秒級的卡頓；又由于COW機(jī)制，導(dǎo)致極端情況下的主庫內(nèi)存溢出，程序異常退出或宕機(jī)；主庫節(jié)點生成備份文件導(dǎo)致服務(wù)器磁盤IO和CPU（壓縮）資源消耗；發(fā)送數(shù)GB大小的備份文件導(dǎo)致服務(wù)器出口帶寬暴增，阻塞請求，建議升級到最新版本。

3、Redis Sentinel（哨兵）

Redis Sentinel是社區(qū)版本推出的原生高可用解決方案，其部署架構(gòu)主要包括兩部分：Redis Sentinel集群和Redis數(shù)據(jù)集群。

其中Redis Sentinel集群是由若干Sentinel節(jié)點組成的分布式集群，可以實現(xiàn)故障發(fā)現(xiàn)、故障自動轉(zhuǎn)移、配置中心和客戶端通知。Redis Sentinel的節(jié)點數(shù)量要滿足2n+1（n>=1）的奇數(shù)個。

優(yōu)點：

Redis Sentinel集群部署簡單；

能夠解決Redis主從模式下的高可用切換問題；

很方便實現(xiàn)Redis數(shù)據(jù)節(jié)點的線形擴(kuò)展，輕松突破Redis自身單線程瓶頸，可極大滿足Redis大容量或高性能的業(yè)務(wù)需求；

可以實現(xiàn)一套Sentinel監(jiān)控一組Redis數(shù)據(jù)節(jié)點或多組數(shù)據(jù)節(jié)點。

缺點：

部署相對Redis主從模式要復(fù)雜一些，原理理解更繁瑣；

資源浪費，Redis數(shù)據(jù)節(jié)點中slave節(jié)點作為備份節(jié)點不提供服務(wù)；

Redis Sentinel主要是針對Redis數(shù)據(jù)節(jié)點中的主節(jié)點的高可用切換，對Redis的數(shù)據(jù)節(jié)點做失敗判定分為主觀下線和客觀下線兩種，對于Redis的從節(jié)點有對節(jié)點做主觀下線操作，并不執(zhí)行故障轉(zhuǎn)移。

不能解決讀寫分離問題，實現(xiàn)起來相對復(fù)雜。

建議：

如果監(jiān)控同一業(yè)務(wù)，可以選擇一套Sentinel集群監(jiān)控多組Redis數(shù)據(jù)節(jié)點的方案，反之選擇一套Sentinel監(jiān)控一組Redis數(shù)據(jù)節(jié)點的方案。

sentinel monitor 配置中的建議設(shè)置成Sentinel節(jié)點的一半加1，當(dāng)Sentinel部署在多個IDC的時候，單個IDC部署的Sentinel數(shù)量不建議超過（Sentinel數(shù)量 – quorum）。

合理設(shè)置參數(shù)，防止誤切，控制切換靈敏度控制：

a. quorum

b. down-after-milliseconds 30000

c. failover-timeout 180000

d. maxclient

e. timeout

部署的各個節(jié)點服務(wù)器時間盡量要同步，否則日志的時序性會混亂。

Redis建議使用pipeline和multi-keys操作，減少RTT次數(shù)，提高請求效率。

自行搞定配置中心（zookeeper），方便客戶端對實例的鏈接訪問。

4、Redis Cluster

Redis Cluster是社區(qū)版推出的Redis分布式集群解決方案，主要解決Redis分布式方面的需求，比如，當(dāng)遇到單機(jī)內(nèi)存，并發(fā)和流量等瓶頸的時候，Redis Cluster能起到很好的負(fù)載均衡的目的。

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

Redis Cluster采用虛擬槽分區(qū)，所有的鍵根據(jù)哈希函數(shù)映射到0～16383個整數(shù)槽內(nèi)，每個節(jié)點負(fù)責(zé)維護(hù)一部分槽以及槽所印映射的鍵值數(shù)據(jù)。

優(yōu)點：

無中心架構(gòu)；

數(shù)據(jù)按照slot存儲分布在多個節(jié)點，節(jié)點間數(shù)據(jù)共享，可動態(tài)調(diào)整數(shù)據(jù)分布；

可擴(kuò)展性：可線性擴(kuò)展到1000多個節(jié)點，節(jié)點可動態(tài)添加或刪除；

高可用性：部分節(jié)點不可用時，集群仍可用。通過增加Slave做standby數(shù)據(jù)副本，能夠?qū)崿F(xiàn)故障自動failover，節(jié)點之間通過gossip協(xié)議交換狀態(tài)信息，用投票機(jī)制完成Slave到Master的角色提升；

降低運(yùn)維成本，提高系統(tǒng)的擴(kuò)展性和可用性。

缺點：

Client實現(xiàn)復(fù)雜，驅(qū)動要求實現(xiàn)Smart Client，緩存slots mapping信息并及時更新，提高了開發(fā)難度，客戶端的不成熟影響業(yè)務(wù)的穩(wěn)定性。目前僅JedisCluster相對成熟，異常處理部分還不完善，比如常見的“max redirect exception”。

節(jié)點會因為某些原因發(fā)生阻塞（阻塞時間大于clutser-node-timeout），被判斷下線，這種failover是沒有必要的。

數(shù)據(jù)通過異步復(fù)制，不保證數(shù)據(jù)的強(qiáng)一致性。

多個業(yè)務(wù)使用同一套集群時，無法根據(jù)統(tǒng)計區(qū)分冷熱數(shù)據(jù)，資源隔離性較差，容易出現(xiàn)相互影響的情況。

Slave在集群中充當(dāng)“冷備”，不能緩解讀壓力，當(dāng)然可以通過SDK的合理設(shè)計來提高Slave資源的利用率。

Key批量操作限制，如使用mset、mget目前只支持具有相同slot值的Key執(zhí)行批量操作。對于映射為不同slot值的Key由于Keys不支持跨slot查詢，所以執(zhí)行mset、mget、sunion等操作支持不友好。

Key事務(wù)操作支持有限，只支持多key在同一節(jié)點上的事務(wù)操作，當(dāng)多個Key分布于不同的節(jié)點上時無法使用事務(wù)功能。

Key作為數(shù)據(jù)分區(qū)的最小粒度，不能將一個很大的鍵值對象如hash、list等映射到不同的節(jié)點。

不支持多數(shù)據(jù)庫空間，單機(jī)下的redis可以支持到16個數(shù)據(jù)庫，集群模式下只能使用1個數(shù)據(jù)庫空間，即db 0。

復(fù)制結(jié)構(gòu)只支持一層，從節(jié)點只能復(fù)制主節(jié)點，不支持嵌套樹狀復(fù)制結(jié)構(gòu)。

避免產(chǎn)生hot-key，導(dǎo)致主庫節(jié)點成為系統(tǒng)的短板。

避免產(chǎn)生big-key，導(dǎo)致網(wǎng)卡撐爆、慢查詢等。

重試時間應(yīng)該大于cluster-node-time時間。

Redis Cluster不建議使用pipeline和multi-keys操作，減少max redirect產(chǎn)生的場景。

5、Redis自研

Redis自研的高可用解決方案，主要體現(xiàn)在配置中心、故障探測和failover的處理機(jī)制上，通常需要根據(jù)企業(yè)業(yè)務(wù)的實際線上環(huán)境來定制化。

優(yōu)點：

高可靠性、高可用性；

自主可控性高；

貼切業(yè)務(wù)實際需求，可縮性好，兼容性好。

缺點：

實現(xiàn)復(fù)雜，開發(fā)成本高；

需要建立配套的周邊設(shè)施，如監(jiān)控，域名服務(wù)，存儲元數(shù)據(jù)信息的數(shù)據(jù)庫等；

維護(hù)成本高。

以上是“Redis高可用技術(shù)解決方案有哪些”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)網(wǎng)站制作公司行業(yè)資訊頻道！

創(chuàng)新互聯(lián)www.cdcxhl.cn，專業(yè)提供香港、美國云服務(wù)器，動態(tài)BGP最優(yōu)骨干路由自動選擇，持續(xù)穩(wěn)定高效的網(wǎng)絡(luò)助力業(yè)務(wù)部署。公司持有工信部辦法的idc、isp許可證， 機(jī)房獨有T級流量清洗系統(tǒng)配攻擊溯源，準(zhǔn)確進(jìn)行流量調(diào)度，確保服務(wù)器高可用性。佳節(jié)活動現(xiàn)已開啟，新人活動云服務(wù)器買多久送多久。

當(dāng)前題目：Redis高可用技術(shù)解決方案有哪些-創(chuàng)新互聯(lián)
鏈接分享：http://bm7419.com/article4/dihcie.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)頁設(shè)計公司、面包屑導(dǎo)航、虛擬主機(jī)、網(wǎng)站設(shè)計、網(wǎng)站改版、外貿(mào)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)