1. IT運維知識：Redis五種集群方式優(yōu)缺點

2020-03-22 14:56 作者：admin 瀏覽量：

 
中小企業(yè)選擇IT外包服務(wù)的原因，首先大家想到的可能是節(jié)省成本，但從專業(yè)的角度上來說，節(jié)省成本卻不是最重要的，這時代任何一家企業(yè)都會成為IT公司，任何一家企業(yè)都會成互聯(lián)網(wǎng)公司，任何一家企業(yè)最終也都會成為數(shù)據(jù)公司，所以中小企業(yè)在發(fā)展中，IT的規(guī)劃和運用是最重要的，這直接決定著這家企業(yè)能活多久，能活多好.
 
但往往中小企業(yè)負責人為了方便，會直接花錢找個網(wǎng)絡(luò)管理員，讓這個人即處理企業(yè)內(nèi)部電腦和網(wǎng)絡(luò)的問題，又兼著其它方面的工作，從表面上看好像還挺劃算，而且人是自己公司的人，好像也挺放心.
 
但實際恰恰相反，我給大家講個故事，可能你就明白了.
 
有一家手機企業(yè)，他們的核心優(yōu)勢是研發(fā)和生產(chǎn)，營銷和廣告并不是他們具備的能力，為了更好的銷售他們生產(chǎn)的手機，他們就請來了一個專門搞營銷和廣告的經(jīng)理，因為公司處在發(fā)展時期，為了節(jié)省成本，所以這個經(jīng)理就自己一個兵，在沒有團隊的情況下，又要想策劃，又要搞制作，還要設(shè)計圖片，最終策劃出來的方案是二流的，制作和設(shè)計還是三流的，導致手機銷售量非常差，沒有正常現(xiàn)金流，后來這家企業(yè)就倒閉關(guān)門了.
 
還有一家手機企業(yè)，他們的核心優(yōu)勢也是研發(fā)和生產(chǎn)，但他們的負責人非常智慧，把營銷和廣告部分外包給了一家行業(yè)頂尖的企業(yè)，這家企業(yè)幫助他們策劃出了一個絕佳的方案，還幫助落實和執(zhí)行了整個方案，最終大獲全勝，當年手機銷量邁進了全國前三，后來核算整體在營銷和廣告的投入和產(chǎn)出卻是極低的.
 
上面兩個案例，讓我們看到了企業(yè)致勝的關(guān)鍵不是你有什么，而是你如何利用你的沒有.
 
總的來說中小企業(yè)選擇IT外包公司有三大優(yōu)勢：
 
l  首先節(jié)省成本是第一點優(yōu)勢
我們透過下圖可以看出企業(yè)自招網(wǎng)管和用IT外包公司成本可以節(jié)省90%以上，而且還是專業(yè)的團隊提供服務(wù). l  其次專業(yè)化的服務(wù)讓企業(yè)有更多的時間搶占先機是第二大優(yōu)勢
專業(yè)的團隊，可以根據(jù)你不同的需要匹配不同的工程師，這大大節(jié)省了企業(yè)的時間，互聯(lián)網(wǎng)時代，分秒必爭，當年滴滴和快滴的100億戰(zhàn)爭，不就是為了贏得時間，讓自己更快的戰(zhàn)領(lǐng)這個市場，失去先機就失去了一切，所以IT外包公司給你帶來的不僅僅是專業(yè)，還有先機. l  最后獲得專業(yè)的解決方案成為行業(yè)的領(lǐng)導地位是第三大優(yōu)勢
這個時代已經(jīng)不是人海戰(zhàn)術(shù)，而是運用互聯(lián)網(wǎng)技術(shù)，以一當十，以十當百的快速發(fā)展，那怎樣可以迅速從行業(yè)中脫穎而出，就需要互聯(lián)網(wǎng)的解決方案，一家專業(yè)的互聯(lián)網(wǎng)IT外包公司可以讓你快速轉(zhuǎn)型升級，最重要的不僅僅只有方案，還有切實可行的落地執(zhí)行，讓你更專注自己核心業(yè)務(wù)，達到強強聯(lián)合的效果. 你的企業(yè)IT外包了嗎？
 

 
 
1. IT運維知識：Redis五種集群方式優(yōu)缺點
 
 
Redis 多副本，采用主從(replication)部署結(jié)構(gòu)，相較于單副本而言最大的特點就是主從實例間數(shù)據(jù)實時同步，并且提供數(shù)據(jù)持久化和備份策略。本文主要針對 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 保證)，當然為了滿足業(yè)務(wù)的高可用性，也可以犧牲一個備用節(jié)點，但同時刻只有一個實例對外提供服務(wù);
高性能。
缺點：
不保證數(shù)據(jù)的可靠性;
在緩存使用，進程重啟后，數(shù)據(jù)丟失，即使有備用的節(jié)點解決高可用性，但是仍然不能解決緩存預(yù)熱問題，因此不適用于數(shù)據(jù)可靠性要求高的業(yè)務(wù);
高性能受限于單核 CPU 的處理能力(Redis 是單線程機制)，CPU 為主要瓶頸，所以適合操作命令簡單，排序、計算較少的場景。也可以考慮用 Memcached 替代。
2、Redis 多副本(主從)
Redis 多副本，采用主從(replication)部署結(jié)構(gòu)，相較于單副本而言最大的特點就是主從實例間數(shù)據(jù)實時同步，并且提供數(shù)據(jù)持久化和備份策略。主從實例部署在不同的物理服務(wù)器上，根據(jù)公司的基礎(chǔ)環(huán)境配置，可以實現(xiàn)同時對外提供服務(wù)和讀寫分離策略。 優(yōu)點：
高可靠性：一方面，采用雙機主備架構(gòu)，能夠在主庫出現(xiàn)故障時自動進行主備切換，從庫提升為主庫提供服務(wù)，保證服務(wù)平穩(wěn)運行;另一方面，開啟數(shù)據(jù)持久化功能和配置合理的備份策略，能有效的解決數(shù)據(jù)誤操作和數(shù)據(jù)異常丟失的問題;
讀寫分離策略：從節(jié)點可以擴展主庫節(jié)點的讀能力，有效應(yīng)對大并發(fā)量的讀操作。
缺點：
故障恢復(fù)復(fù)雜，如果沒有 RedisHA 系統(tǒng)(需要開發(fā))，當主庫節(jié)點出現(xiàn)故障時，需要手動將一個從節(jié)點晉升為主節(jié)點，同時需要通知業(yè)務(wù)方變更配置，并且需要讓其它從庫節(jié)點去復(fù)制新主庫節(jié)點，整個過程需要人為干預(yù)，比較繁瑣;
主庫的寫能力受到單機的限制，可以考慮分片;
主庫的存儲能力受到單機的限制，可以考慮 Pika;
原生復(fù)制的弊端在早期的版本中也會比較突出，如：Redis 復(fù)制中斷后，Slave 會發(fā)起 psync，此時如果同步不成功，則會進行全量同步，主庫執(zhí)行全量備份的同時可能會造成毫秒或秒級的卡頓;又由于 COW 機制，導致極端情況下的主庫內(nèi)存溢出，程序異常退出或宕機;主庫節(jié)點生成備份文件導致服務(wù)器磁盤 IO 和 CPU(壓縮)資源消耗;發(fā)送數(shù) GB 大小的備份文件導致服務(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é)點的線形擴展，輕松突破 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，當 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 分布式方面的需求，比如，當遇到單機內(nèi)存，并發(fā)和流量等瓶頸的時候，Redis Cluster 能起到很好的負載均衡的目的。
Redis Cluster 集群節(jié)點最小配置 6 個節(jié)點以上(3 主 3 從)，其中主節(jié)點提供讀寫操作，從節(jié)點作為備用節(jié)點，不提供請求，只作為故障轉(zhuǎn)移使用。
Redis Cluster 采用虛擬槽分區(qū)，所有的鍵根據(jù)哈希函數(shù)映射到 0～16383 個整數(shù)槽內(nèi)，每個節(jié)點負責維護一部分槽以及槽所印映射的鍵值數(shù)據(jù)。 優(yōu)點：
無中心架構(gòu);
數(shù)據(jù)按照 slot 存儲分布在多個節(jié)點，節(jié)點間數(shù)據(jù)共享，可動態(tài)調(diào)整數(shù)據(jù)分布;
可擴展性：可線性擴展到 1000 多個節(jié)點，節(jié)點可動態(tài)添加或刪除;
高可用性：部分節(jié)點不可用時，集群仍可用。通過增加 Slave 做 standby 數(shù)據(jù)副本，能夠?qū)崿F(xiàn)故障自動 failover，節(jié)點之間通過 gossip 協(xié)議交換狀態(tài)信息，用投票機制完成 Slave 到 Master 的角色提升;
降低運維成本，提高系統(tǒng)的擴展性和可用性。
缺點：
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ù)的強一致性。
多個業(yè)務(wù)使用同一套集群時，無法根據(jù)統(tǒng)計區(qū)分冷熱數(shù)據(jù)，資源隔離性較差，容易出現(xiàn)相互影響的情況。
Slave 在集群中充當“冷備”，不能緩解讀壓力，當然可以通過 SDK 的合理設(shè)計來提高 Slave 資源的利用率。
Key 批量操作限制，如使用 mset、mget 目前只支持具有相同 slot 值的 Key 執(zhí)行批量操作。對于映射為不同 slot 值的 Key 由于 Keys 不支持跨 slot 查詢，所以執(zhí)行 mset、mget、sunion 等操作支持不友好。
Key 事務(wù)操作支持有限，只支持多 key 在同一節(jié)點上的事務(wù)操作，當多個 Key 分布于不同的節(jié)點上時無法使用事務(wù)功能。
Key 作為數(shù)據(jù)分區(qū)的最小粒度，不能將一個很大的鍵值對象如 hash、list 等映射到不同的節(jié)點。
不支持多數(shù)據(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，導致主庫節(jié)點成為系統(tǒng)的短板。
避免產(chǎn)生 big-key，導致網(wǎng)卡撐爆、慢查詢等。
重試時間應(yīng)該大于 cluster-node-time 時間。
Redis Cluster 不建議使用 pipeline 和 multi-keys 操作，減少 max redirect 產(chǎn)生的場景。
 
5、Redis 自研
Redis 自研的高可用解決方案，主要體現(xiàn)在配置中心、故障探測和 failover 的處理機制上，通常需要根據(jù)企業(yè)業(yè)務(wù)的實際線上環(huán)境來定制化。 優(yōu)點：
高可靠性、高可用性;
自主可控性高;
貼切業(yè)務(wù)實際需求，可縮性好，兼容性好。
缺點：
實現(xiàn)復(fù)雜，開發(fā)成本高;
需要建立配套的周邊設(shè)施，如監(jiān)控，域名服務(wù)，存儲元數(shù)據(jù)信息的數(shù)據(jù)庫等;
維護成本高。