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

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

入口層高可用

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即可

  一致性HASH

  在分布式集群中，對機器的添加刪除，或者機器故障後自動脫離集群這些操作是分布式集群管理最基本的功能。如果采用常用的hash(object)%N算法，那麽在有機器添加或者刪除後，很多原有的數據就無法找到了，這樣嚴重的違反了單調性原則
  一致性HASH可以有效解決這個問題，一致性哈希算法在保持了單調性的同時，還是數據的遷移達到了最小，這樣的算法對分布式集群來說是非常合適的，避免了大量數據遷移，減小了服務器的的壓力。
  舉個例子
  如果緩存從9臺擴容到10臺， 簡單Hash況下90％的緩存會馬上失效，而一致性Hash 情況下，只有10%的緩存會失效。

強一致緩存問題

• 1.緩存客戶端的配置更新時間會有微小的差異，在這個時間窗內有可能會拿到過期的數據。
• 2.如果在擴充節點之後裁撤節點，會拿到臟數據。比如a這個key之前在機器1， 擴容後在機器2，數據更新了， 但裁撤節點後key回到機器1 這樣就會有臟數據的問題

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

數據庫可伸縮

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

後端架構高可用可伸縮