Redis高可用分散式內部交流(九)

蘑菇先生發表於2015-08-25

這是上月在公司內部的一次分享,現把PPT及交流內容整理成部落格。

閱讀目錄:

  1. 高可用
  2. 資料同步
  3. 分散式
  4. 分散式叢集時代
  5. 總結

高可用

高可用(High Availability),是當一臺伺服器停止服務後,對於業務及使用者毫無影響。 停止服務的原因可能由於網路卡、路由器、機房、CPU負載過高、記憶體溢位、自然災害等不可預期的原因導致,在很多時候也稱單點問題。
解決單點問題主要有2種方式:

主備方式

這種通常是一臺主機、一臺或多臺備機,在正常情況下主機對外提供服務,並把資料同步到備機,當主機當機後,備機立刻開始服務。
Redis HA中使用比較多的是keepalived,它使主機備機對外提供同一個虛擬IP,客戶端通過虛擬IP進行資料操作,正常期間主機一直對外提供服務,當機後VIP自動漂移到備機上。

優點是對客戶端毫無影響,仍然通過VIP操作。
缺點也很明顯,在絕大多數時間內備機是一直沒使用,被浪費著的。

主從方式

這種採取一主多從的辦法,主從之間進行資料同步。 當Master當機後,通過選舉演算法(Paxos、Raft)從slave中選舉出新Master繼續對外提供服務,主機恢復後以slave的身份重新加入。
主從另一個目的是進行讀寫分離,這是當單機讀寫壓力過高的一種通用型解決方案。 其主機的角色只提供寫操作或少量的讀,把多餘讀請求通過負載均衡演算法分流到單個或多個slave伺服器上。

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

資料同步

無論是主備還是主從都牽扯到資料同步的問題,這也分2種情況:

  • 同步方式:當主機收到客戶端寫操作後,以同步方式把資料同步到從機上,當從機也成功寫入後,主機才返回給客戶端成功,也稱資料強一致性。 很顯然這種方式效能會降低不少,當從機很多時,可以不用每臺都同步,主機同步某一臺從機後,從機再把資料分發同步到其他從機上,這樣提高主機效能分擔同步壓力。 在Redis中是支援這楊配置的,一臺master,一臺slave,同時這臺salve又作為其他slave的master。

  • 非同步方式:主機接收到寫操作後,直接返回成功,然後在後臺用非同步方式把資料同步到從機上。 這種同步效能比較好,但無法保證資料的完整性,比如在非同步同步過程中主機突然當機了,也稱這種方式為資料弱一致性。

Redis主從同步採用的是非同步方式,因此會有少量丟資料的危險。還有種弱一致性的特例叫最終一致性,這塊詳細內容可參見CAP原理及一致性模型。

方案選擇

keepalived方案配置簡單、人力成本小,在資料量少、壓力小的情況下推薦使用。 如果資料量比較大,不希望過多浪費機器,還希望在當機後,做一些自定義的措施,比如報警、記日誌、資料遷移等操作,推薦使用主從方式,因為和主從搭配的一般還有個管理監控中心。

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

邏輯圖:

分散式

分散式(distributed), 是當業務量、資料量增加時,可以通過任意增加減少伺服器數量來解決問題。

叢集時代

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

  • 高可用性:在主機掛掉後,自動故障轉移,使前端服務對使用者無影響。
  • 讀寫分離:將主機讀壓力分流到從機上。

可在客戶端元件上實現負載均衡,根據不同伺服器的執行情況,分擔不同比例的讀請求壓力。

邏輯圖:

分散式叢集時代

當快取資料量不斷增加時,單機記憶體不夠使用,需要把資料切分不同部分,分佈到多臺伺服器上。
可在客戶端對資料進行分片,資料分片演算法詳見C#一致性Hash詳解C#之虛擬桶分片

邏輯圖:

大規模分散式叢集時代

當資料量持續增加時,應用可根據不同場景下的業務申請對應的分散式叢集。 這塊最關鍵的是快取治理這塊,其中最重要的部分是加入了代理服務。 應用通過代理訪問真實的Redis伺服器進行讀寫,這樣做的好處是:

  • 避免越來越多的客戶端直接訪問Redis伺服器難以管理,而造成風險。
  • 在代理這一層可以做對應的安全措施,比如限流、授權、分片。
  • 避免客戶端越來越多的邏輯程式碼,不但臃腫升級還比較麻煩。
  • 代理這層無狀態的,可任意擴充套件節點,對於客戶端來說,訪問代理跟訪問單機Redis一樣。

目前樓主公司使用的是客戶端元件和代理兩種方案並存,因為通過代理會影響一定的效能。 代理這塊對應的方案實現有Twitter的Twemproxy和豌豆莢的codis。

邏輯圖:

總結

分散式快取再向後是雲服務快取,對使用端完全遮蔽細節,各應用自行申請大小、流量方案即可,如淘寶OCS雲服務快取。
分散式快取對應需要的實現元件有:

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

謝謝大家

相關文章