後端架構高可用可伸縮

Reference: https://www.cnblogs.com/liuroy/p/6537660.htmlhtml

 

後端架構高可用可伸縮

去年參加技術分享活動,七牛的一個技術簡要的介紹了一些高可用可伸縮的一些經驗之談,聽完以後受益不淺,整理一下,主要分如下幾個部分:nginx

  • 入口層高可用
  • 業務層高可用
  • 緩存層高可用
  • 數據庫高可用
  • 入口層可伸縮
  • 業務層可伸縮
  • 緩存層可伸縮
  • 數據庫可伸縮

這裏寫圖片描述

下面來分層介紹實踐方法。redis

入口層高可用

nigix兩個 keeplive保活 心跳作好。
這裏寫圖片描述算法

  • 使用心跳技術:keeplive提供這個技術
  • 好比機器A IP是1.2.3.4,機器B IP是1.2.3.5,那麼再申請一個IP (1.2.3.6)咱們稱之爲心跳IP,平時綁定再A上面,若是A宕機,那麼IP會自動綁定到B上面
  • DNS 層面綁定到心跳IP便可
  • 兩臺機器必須在同一網段
  • 服務監聽必須監聽全部IP,若是僅僅監聽心跳IP,那麼從機上的服務(不持有心跳IP的機器)會啓動失敗
  • 服務器利用率降低(混合部署能夠改善這一點)

考慮一個問題,兩臺機器,兩個公網IP,DNS把域名同時定位到兩個IP,這算高可用嗎數據庫

不算,客戶端(好比瀏覽器) 解析完後會隨機選一個 IP訪問 , 而不是一個失敗後就去另外一個 。 因此若是一臺機器當機 ,那麼就有一半左右的用戶沒法訪問 。後端

業務層高可用

這裏寫圖片描述

  • 業務層不要有狀態 , 狀態分散到緩存層和數據庫層 。 只要沒有狀態,業務層的服務死掉後,前面的nginx會自動把流量打到剩下的服務 。 因此,業務層無狀態是一個重點。
  • 友情提醒:不要由於想讓服務無狀態就直接用cookie session, 裏邊的坑有點大,考察清楚後再用比較好。好比重放攻擊 。

緩存層高可用

這裏寫圖片描述

  • 緩存層分得細一點,保證單臺緩存宕機後數據庫還能撐得住 。
  • 中小模下緩存層和業務層能夠混合部署, 這樣能夠節省機器
  • 大型規模網站,業務層和緩存層分開部署。
  • 緩存層高可用,緩存能夠啓用主從兩臺,主緩存活着的時候,主緩存讀,主從緩存都寫,主緩存宕機後,從變主,主恢復後, 變成新的從。這樣能夠保證數據完整性,實現高可用

數據庫高可用

  • MySQL有主從模式, 還有主主模式都能知足你的需求
  • MongoDB也有ReplicaSet的概念,基本都能知足你們的需求。

高可用小結

這裏寫圖片描述

入口層可伸縮

  • 入囗層如何提供伸縮性?直接鋪機器 ?而後DNS加IP就能夠了吧?
  • 能夠,但也有須要注意的地方
  • 儘管一個域名解析到幾十個IP沒有問題,可是很瀏覽器客戶端只會使用前面幾個IP,部分域名供應商對此有優化(好比每次返回的IP順序隨機 ), 可是這個優化效果不穩定。推薦的作法是使用少許的nginx機 器做爲入囗,業務服務器隱藏在內網(HTTP類型的業務這種方式居多)

業務層可伸縮

  • 跟應付高可用同樣,保證無狀態是很好的手段。加機器繼續水平部署便可。

緩存層可伸縮

  • 直接用 codis或者redis 3.0 便可瀏覽器

  • 若是低峯期間數據庫能抗的住 ,那麼直接下線存而後上新緩存就是最簡單有效的辦法緩存

緩存類型 服務器

  • 強一致性緩存: 沒法接受從緩存中讀取錯誤的數據(好比用戶餘額)
  • 弱一致性緩存:能夠接受一段時間內的錯誤數據,例如微博轉發數
  • 不變型緩存:緩存key對應的value不會變動
    弱一致性和不變型緩存擴容很方便,用一致性HASH便可cookie

    一致性HASH

    在分佈式集羣中,對機器的添加刪除,或者機器故障後自動脫離集羣這些操做是分佈式集羣管理最基本的功能。若是採用經常使用的hash(object)%N算法,那麼在有機器添加或者刪除後,不少原有的數據就沒法找到了,這樣嚴重的違反了單調性原則
    一致性HASH能夠有效解決這個問題,一致性哈希算法在保持了單調性的同時,仍是數據的遷移達到了最小,這樣的算法對分佈式集羣來講是很是合適的,避免了大量數據遷移,減少了服務器的的壓力。
    舉個例子
    若是緩存從9臺擴容到10臺, 簡單Hash況下90%的緩存會立刻失效,而一致性Hash 狀況下,只有10%的緩存會失效。

強一致緩存問題

  • 1.緩存客戶端的配置更新時間會有微小的差別,在這個時間窗內有可能會拿到過時的數據。
  • 2.若是在擴充節點以後裁撤節點,會拿到髒數據。好比a這個key以前在機器1, 擴容後在機器2,數據更新了, 但裁撤節點後key回到機器1 這樣就會有髒數據的問題

問題二解決方法:要麼保持永不減小節點,要麼節點調整間隔大於數據有效時間。
問題一解決方法:
  - 兩套hash配置都更新到客戶端,但仍使用舊的配置
  - 兩個個客戶端改成只有兩套hash結果一致的狀況下會使用緩存,其他狀況從數據庫讀,但寫入緩存。
  -  逐個客戶端通知使用新配置。

數據庫可伸縮

  • 水平拆分
  • 垂直拆分
  • 按期滾動

這裏寫圖片描述

相關文章
相關標籤/搜索