摘要：哨兵是社區(qū)版本推出的原生高可用解決方案，部署架構(gòu)主要包括兩部分集群和數(shù)據(jù)集群，其中集群是由若干節(jié)點(diǎn)組成的分布式集群。自研推薦推薦自研的高可用解決方案，主要體現(xiàn)在配置中心故障探測(cè)和的處理機(jī)制上，通常需要根據(jù)企業(yè)業(yè)務(wù)的實(shí)際線上環(huán)境來(lái)定制化。

最近很多朋友向我咨詢(xún)關(guān)于高可用的方案的優(yōu)缺點(diǎn)以及如何選擇合適的方案線上使用，剛好最近在給宜人貸，光大銀行做企業(yè)內(nèi)訓(xùn)的時(shí)候也詳細(xì)講過(guò)，這里我再整理發(fā)出來(lái)，供大家參考，如有不妥之處，歡迎批評(píng)指正，也歡迎推薦更好的技術(shù)方案。不廢話了，來(lái)看看方案吧～

總綱

Redis常見(jiàn)的幾種主要使用方式：

Redis 單副本

Redis 多副本（主從）

Redis Sentinel（哨兵）

Redis Cluster

Redis 自研

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)：

1、架構(gòu)簡(jiǎn)單、部署方便

2、高性?xún)r(jià)比，當(dāng)緩存使用時(shí)無(wú)需備用節(jié)點(diǎn)（單實(shí)例可用性可以用supervisor或crontab保證），當(dāng)然為了滿足業(yè)務(wù)的高可用性，也可以犧牲一個(gè)備用節(jié)點(diǎn)，但同時(shí)刻只有一個(gè)實(shí)例對(duì)外提供服務(wù)。

3、高性能

缺點(diǎn)：

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

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

3、高性能受限于單核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ù)和讀寫(xiě)分離策略。

優(yōu)點(diǎn)：

1、高可靠性，一方面，采用雙機(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)題。

2、讀寫(xiě)分離策略，從節(jié)點(diǎn)可以擴(kuò)展主庫(kù)節(jié)點(diǎn)的讀能力，有效應(yīng)對(duì)大并發(fā)量的讀操作。

缺點(diǎn)：

1、故障恢復(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ù)，比較繁瑣。

2、主庫(kù)的寫(xiě)能力受到單機(jī)的限制，可以考慮分片

3、主庫(kù)的存儲(chǔ)能力受到單機(jī)的限制，可以考慮Pika

4、原生復(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ù)器磁盤(pán)IO和CPU（壓縮）資源消耗；發(fā)送數(shù)GB大小的備份文件導(dǎo)致服務(wù)器出口帶寬暴增，阻塞請(qǐng)求。建議升級(jí)到最新版本。

3、Redis Sentinel（哨兵）

Redis Sentinel是社區(qū)版本推出的原生高可用解決方案，Redis Sentinel部署架構(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)：

1、Redis Sentinel集群部署簡(jiǎn)單

2、能夠解決Redis主從模式下的高可用切換問(wèn)題

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

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

缺點(diǎn)：

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

2、資源浪費(fèi)，Redis數(shù)據(jù)節(jié)點(diǎn)中slave節(jié)點(diǎn)作為備份節(jié)點(diǎn)不提供服務(wù)

3、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)移。

4、不能解決讀寫(xiě)分離問(wèn)題，實(shí)現(xiàn)起來(lái)相對(duì)復(fù)雜

建議：

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

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

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

quorum

down-after-milliseconds 30000

failover-timeout 180000

maxclient

timeout

4、部署的各個(gè)節(jié)點(diǎn)服務(wù)器時(shí)間盡量要同步，否則日志的時(shí)序性會(huì)混亂

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

6、自行搞定配置中心（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)提供讀寫(xiě)操作，從節(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ù)。

文章寫(xiě)到這里，也給大家送一個(gè)福利，給大家推薦一個(gè)Java架構(gòu)方面的交流學(xué)習(xí)群：650385180，里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：有Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化這些成為架構(gòu)師必備的知識(shí)體系。還能領(lǐng)取免費(fèi)的學(xué)習(xí)資源。文章開(kāi)頭的總綱就是在群里面獲取的，相信對(duì)于已經(jīng)工作和遇到技術(shù)瓶頸的碼友，在這個(gè)群里一定有你需要的內(nèi)容。

優(yōu)點(diǎn)：

1、無(wú)中心架構(gòu)

2、數(shù)據(jù)按照slot存儲(chǔ)分布在多個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)間數(shù)據(jù)共享，可動(dòng)態(tài)調(diào)整數(shù)據(jù)分布。

3、可擴(kuò)展性，可線性擴(kuò)展到1000多個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)可動(dòng)態(tài)添加或刪除。

4、高可用性，部分節(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的角色提升。

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

缺點(diǎn)：

1、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”。

2、節(jié)點(diǎn)會(huì)因?yàn)槟承┰虬l(fā)生阻塞（阻塞時(shí)間大于clutser-node-timeout），被判斷下線，這種failover是沒(méi)有必要的。

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

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

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

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

7、key事務(wù)操作支持有限，只支持多key在同一節(jié)點(diǎn)上的事務(wù)操作，當(dāng)多個(gè)key分布于不同的節(jié)點(diǎn)上時(shí)無(wú)法使用事務(wù)功能。

8、key作為數(shù)據(jù)分區(qū)的最小粒度，因此不能將一個(gè)很大的鍵值對(duì)象如hash、list等映射到不同的節(jié)點(diǎn)。

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

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

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

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

13、重試時(shí)間應(yīng)該大于cluster-node-time時(shí)間

14、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)：

1、高可靠性、高可用性

2、自主可控性高

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

缺點(diǎn)：

1、實(shí)現(xiàn)復(fù)雜，開(kāi)發(fā)成本高

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

3、維護(hù)成本高