繼采訪 “對話張冬洪 | 全面解讀NoSQL資料庫Redis的核心技術與應用實踐” 發出後，很多朋友向我咨詢關于裡面提到的高可用的方案的優缺點以及如何選擇合适的方案線上使用，剛好最近在給宜人貸，光大銀行做企業内訓的時候也詳細講過（廣告一下：極數雲舟不僅提供企業教育訓練、技術咨詢、解決方案，還有項目産品，歡迎勾搭～），這裡我再整理發出來，供大家參考，如有不妥之處，歡迎批評指正，也歡迎推薦更好的技術方案。不廢話了，來看看方案吧～
Redis常見的幾種主要使用方式：
● Redis 單副本
● Redis 多副本（主從）
● Redis Sentinel（哨兵）
● Redis Cluster
● Redis 自研
Redis各種使用方式的優缺點：
1Redis單副本
Redis 單副本，采用單個Redis節點部署架構，沒有備用節點實時同步資料，不提供資料持久化和備份政策，适用于資料可靠性要求不高的純緩存業務場景。
優點：
1、架構簡單、部署友善
2、高成本效益，當緩存使用時無需備用節點（單執行個體可用性可以用supervisor或crontab保證），當然為了滿足業務的高可用性，也可以犧牲一個備用節點，但同時刻隻有一個執行個體對外提供服務。
3、高性能
缺點：
1、不保證資料的可靠性
2、當緩存使用，程序重新開機後，資料丢失，即使有備用的節點解決高可用性，但是仍然不能解決緩存預熱問題，是以不适用于資料可靠性要求高的業務。
3、高性能受限于單核CPU的處理能力（Redis是單線程機制），CPU為主要瓶頸，是以适合操作指令簡單，排序、計算較少的場景。也可以考慮用memcached替代。
2Redis多副本（主從）
Redis 多副本，采用主從（replication）部署結構，相較于單副本而言最大的特點就是主從執行個體間資料實時同步，并且提供資料持久化和備份政策。主從執行個體部署在不同的實體伺服器上，根據公司的基礎環境配置，可以實作同時對外提供服務和讀寫分離政策。
1、高可靠性，一方面，采用雙機主備架構，能夠在主庫出現故障時自動進行主備切換，從庫提升為主庫提供服務，保證服務平穩運作。另一方面，開啟資料持久化功能和配置合理的備份政策，能有效的解決資料誤操作和資料異常丢失的問題。
2、讀寫分離政策，從節點可以擴充主庫節點的讀能力，有效應對大并發量的讀操作。
1、故障恢複複雜，如果沒有RedisHA系統（需要開發），當主庫節點出現故障時，需要手動将一個從節點晉升為主節點，同時需要通知業務方變更配置，并且需要讓其他從庫節點去複制新主庫節點，整個過程需要人為幹預，比較繁瑣。
2、主庫的寫能力受到單機的限制，可以考慮分片
3、主庫的存儲能力受到單機的限制，可以考慮Pika
4、原生複制的弊端在早期的版本也會比較突出，如：Redis複制中斷後，Slave會發起psync，此時如果同步不成功，則會進行全量同步，主庫執行全量備份的同時可能會造成毫秒或秒級的卡頓；又由于COW機制，導緻極端情況下的主庫記憶體溢出，程式異常退出或當機；主庫節點生成備份檔案導緻伺服器磁盤IO和CPU（壓縮）資源消耗；發送數GB大小的備份檔案導緻伺服器出口帶寬暴增，阻塞請求。建議更新到最新版本。
3Redis Sentinel（哨兵）
Redis Sentinel是社群版本推出的原生高可用解決方案，Redis Sentinel部署架構主要包括兩部分：Redis Sentinel叢集和Redis資料叢集，其中Redis Sentinel叢集是由若幹Sentinel節點組成的分布式叢集。可以實作故障發現、故障自動轉移、配置中心和用戶端通知。Redis Sentinel的節點數量要滿足2n+1（n>=1）的奇數個。
1、Redis Sentinel叢集部署簡單
2、能夠解決Redis主從模式下的高可用切換問題
3、很友善實作Redis資料節點的線形擴充，輕松突破Redis自身單線程瓶頸，可極大滿足對Redis大容量或高性能的業務需求。
4、可以實作一套Sentinel監控一組Redis資料節點或多組資料節點
1、部署相對Redis 主從模式要複雜一些，原理了解更繁瑣
2、資源浪費，Redis資料節點中slave節點作為備份節點不提供服務
3、Redis Sentinel主要是針對Redis資料節點中的主節點的高可用切換，對Redis的資料節點做失敗判定分為主觀下線和客觀下線兩種，對于Redis的從節點有對節點做主觀下線操作，并不執行故障轉移。
4、不能解決讀寫分離問題，實作起來相對複雜
建議：
1、如果監控同一業務，可以選擇一套Sentinel叢集監控多組Redis資料節點的方案，反之選擇一套Sentinel監控一組Redis資料節點的方案
2、sentinel monitor <master-name> <ip> <port> <quorum> 配置中的<quorum>建議設定成Sentinel節點的一半加1，當Sentinel部署在多個IDC的時候，單個IDC部署的Sentinel數量不建議超過（Sentinel數量 – quorum）。
3、合理設定參數，防止誤切，控制切換靈敏度控制
● quorum
● down-after-milliseconds 30000
● failover-timeout 180000
● maxclient
● timeout
4、部署的各個節點伺服器時間盡量要同步，否則日志的時序性會混亂
5、Redis建議使用pipeline和multi-keys操作，減少RTT次數，提高請求效率
6、自行搞定配置中心（zookeeper），友善用戶端對執行個體的連結通路
4Redis Cluster
Redis Cluster是社群版推出的Redis分布式叢集解決方案，主要解決Redis分布式方面的需求，比如，當遇到單機記憶體，并發和流量等瓶頸的時候，Redis Cluster能起到很好的負載均衡的目的。Redis Cluster叢集節點最小配置6個節點以上（3主3從），其中主節點提供讀寫操作，從節點作為備用節點，不提供請求，隻作為故障轉移使用。Redis Cluster采用虛拟槽分區，所有的鍵根據哈希函數映射到0～16383個整數槽内，每個節點負責維護一部分槽以及槽所印映射的鍵值資料。
1、無中心架構
2、資料按照slot存儲分布在多個節點，節點間資料共享，可動态調整資料分布。
3、可擴充性，可線性擴充到1000多個節點，節點可動态添加或删除。
4、高可用性，部分節點不可用時，叢集仍可用。通過增加Slave做standby資料副本，能夠實作故障自動failover，節點之間通過gossip協定交換狀态資訊，用投票機制完成Slave到Master的角色提升。
5、降低運維成本，提高系統的擴充性和可用性。
1、Client實作複雜，驅動要求實作Smart Client，緩存slots mapping資訊并及時更新，提高了開發難度，用戶端的不成熟影響業務的穩定性。目前僅JedisCluster相對成熟，異常處理部分還不完善，比如常見的“max redirect exception”。
2、節點會因為某些原因發生阻塞（阻塞時間大于clutser-node-timeout），被判斷下線，這種failover是沒有必要的。
3、資料通過異步複制,不保證資料的強一緻性。
4、多個業務使用同一套叢集時，無法根據統計區分冷熱資料，資源隔離性較差，容易出現互相影響的情況。
5、Slave在叢集中充當“冷備”，不能緩解讀壓力，當然可以通過SDK的合理設計來提高Slave資源的使用率。
6、key批量操作限制，如使用mset、mget目前隻支援具有相同slot值的key執行批量操作。對于映射為不同slot值的key由于keys 不支援跨slot查詢，是以執行mset、mget、sunion等操作支援不友好。
7、key事務操作支援有限，隻支援多key在同一節點上的事務操作，當多個key分布于不同的節點上時無法使用事務功能。
8、key作為資料分區的最小粒度，是以不能将一個很大的鍵值對象如hash、list等映射到不同的節點。
9、不支援多資料庫空間，單機下的redis可以支援到16個資料庫，叢集模式下隻能使用1個資料庫空間，即db 0。
10、複制結構隻支援一層，從節點隻能複制主節點，不支援嵌套樹狀複制結構。
11、避免産生hot-key，導緻主庫節點成為系統的短闆。
12、避免産生big-key，導緻網卡撐爆、慢查詢等。
13、重試時間應該大于cluster-node-time時間
14、Redis Cluster不建議使用pipeline和multi-keys操作，減少max redirect産生的場景。
5Redis自研 - 推薦
Redis 自研的高可用解決方案，主要展現在配置中心、故障探測和failover的處理機制上，通常需要根據企業業務的實際線上環境來定制化。
1、高可靠性、高可用性
2、自主可控性高
3、貼切業務實際需求，可縮性好，相容性好
1、實作複雜，開發成本高
2、需要建立配套的周邊設施，如監控，域名服務，存儲中繼資料資訊的資料庫等
3、維護成本高
原文釋出時間為：2018-11-15
本文來自雲栖社群合作夥伴“
網際網路架構師”，了解相關資訊可以關注“
”。