Redis高可用分佈式集羣

一,高可用

高可用(High Availability),是當一臺服務器中止服務後,對於業務及用戶毫無影響。 中止服務的緣由可能因爲網卡、路由器、機房、CPU負載太高、內存溢出、天然災害等不可預期的緣由致使,在不少時候也稱單點問題。前端

(1)解決單點問題主要有2種方式:算法

主備方式sql

這種一般是一臺主機、一臺或多臺備機,在正常狀況下主機對外提供服務,並把數據同步到備機,當主機宕機後,備機馬上開始服務。緩存

Redis HA中使用比較多的是keepalived,它使主機備機對外提供同一個虛擬IP,客戶端經過虛擬IP進行數據操做,正常期間主機一直對外提供服務,宕機後VIP自動漂移到備機上。安全

優勢是對客戶端毫無影響,仍然經過VIP操做。服務器

缺點也很明顯,在絕大多數時間內備機是一直沒使用,被浪費着的。架構

主從方式

這種採起一主多從的辦法,主從之間進行數據同步。 當Master宕機後,經過選舉算法(Paxos、Raft)從slave中選舉出新Master繼續對外提供服務,主機恢復後以slave的身份從新加入。併發

主從另外一個目的是進行讀寫分離,這是當單機讀寫壓力太高的一種通用型解決方案。 其主機的角色只提供寫操做或少許的讀,把多餘讀請求經過負載均衡算法分流到單個或多個slave服務器上。負載均衡

缺點是主機宕機後,Slave雖然被選舉成新Master了,但對外提供的IP服務地址卻發生變化了,意味着會影響到客戶端。 解決這種狀況須要一些額外的工做,在當主機地址發生變化後及時通知到客戶端,客戶端收到新地址後,使用新地址繼續發送新請求。異步

(2)數據同步

不管是主備仍是主從都牽扯到數據同步的問題,這也分2種狀況:

同步方式:當主機收到客戶端寫操做後,以同步方式把數據同步到從機上,當從機也成功寫入後,主機才返回給客戶端成功,也稱數據強一致性。 很顯然這種方式性能會下降很多,當從機不少時,能夠不用每臺都同步,主機同步某一臺從機後,從機再把數據分發同步到其餘從機上,這樣提升主機性能分擔同步壓力。 在Redis中是支持這楊配置的,一臺master,一臺slave,同時這臺salve又做爲其餘slave的master。

異步方式:主機接收到寫操做後,直接返回成功,而後在後臺用異步方式把數據同步到從機上。 這種同步性能比較好,但沒法保證數據的完整性,好比在異步同步過程當中主機忽然宕機了,也稱這種方式爲數據弱一致性。

Redis主從同步採用的是異步方式,所以會有少許丟數據的危險。還有種弱一致性的特例叫最終一致性,這塊詳細內容可參見CAP原理及一致性模型。

(3)方案選擇

keepalived方案配置簡單、人力成本小,在數據量少、壓力小的狀況下推薦使用。 若是數據量比較大,不但願過多浪費機器,還但願在宕機後,作一些自定義的措施,好比報警、記日誌、數據遷移等操做,推薦使用主從方式,由於和主從搭配的通常還有個管理監控中心。

宕機通知這塊,能夠集成到客戶端組件上,也可單獨抽離出來。 Redis官方Sentinel支持故障自動轉移、通知等,詳情見低成本高可用方案設計(四)。

邏輯圖:

clipboard.png

2、分佈式

分佈式(distributed), 是當業務量、數據量增長時,能夠經過任意增長減小服務器數量來解決問題。

集羣時代

至少部署兩臺Redis服務器構成一個小的集羣,主要有2個目的:

高可用性:在主機掛掉後,自動故障轉移,使前端服務對用戶無影響。

讀寫分離:將主機讀壓力分流到從機上。

可在客戶端組件上實現負載均衡,根據不一樣服務器的運行狀況,分擔不一樣比例的讀請求壓力。

邏輯圖:

clipboard.png

三,分佈式集羣時代

當緩存數據量不斷增長時,單機內存不夠使用,須要把數據切分不一樣部分,分佈到多臺服務器上。

可在客戶端對數據進行分片,數據分片算法詳見C#一致性Hash詳解、C#之虛擬桶分片。

邏輯圖:

clipboard.png

大規模分佈式集羣時代

當數據量持續增長時,應用可根據不一樣場景下的業務申請對應的分佈式集羣。 這塊最關鍵的是緩存治理這塊,其中最重要的部分是加入了代理服務。 應用經過代理訪問真實的Redis服務器進行讀寫,這樣作的好處是:

避免愈來愈多的客戶端直接訪問Redis服務器難以管理,而形成風險。

在代理這一層能夠作對應的安全措施,好比限流、受權、分片。

避免客戶端愈來愈多的邏輯代碼,不但臃腫升級還比較麻煩。

代理這層無狀態的,可任意擴展節點,對於客戶端來講,訪問代理跟訪問單機Redis同樣。

目前樓主公司使用的是客戶端組件和代理兩種方案並存,由於經過代理會影響必定的性能。 代理這塊對應的方案實現有Twitter的Twemproxy和豌豆莢的codis。

邏輯圖:

clipboard.png

四,總結

分佈式緩存再向後是雲服務緩存,對使用端徹底屏蔽細節,各應用自行申請大小、流量方案便可,如淘寶OCS雲服務緩存。

分佈式緩存對應須要的實現組件有:

  • 一個緩存監控、遷移、管理中心。
  • 一個自定義的客戶端組件,上圖中的SmartClient。
  • 一個無狀態的代理服務。
  • N臺服務器。

本文的重點是你有沒有收穫與成長,其他的都不重要,但願讀者們能謹記這一點。同時我通過多年的收藏目前也算收集到了一套完整的學習資料,包括但不限於:分佈式架構、高可擴展、高性能、高併發、Jvm性能調優、Spring,MyBatis,Nginx源碼分析,Redis,ActiveMQ、、Mycat、Netty、Kafka、Mysql、Zookeeper、Tomcat、Docker、Dubbo、Nginx等多個知識點高級進階乾貨,但願對想成爲架構師的朋友有必定的參考和幫助

須要更詳細架構師技能思惟導圖和如下資料的能夠加一下技術交流分享羣:「708 701 457」免費獲取




相關文章
相關標籤/搜索