後端架構高可用可伸縮
去年參加技術分享活動，七牛的一個技術簡要的介紹了一些高可用可伸縮的一些經驗之談，聽完之後受益匪淺，整理一下，主要分以下幾個部分:
- 入口層高可用
- 業務層高可用
- 緩存層高可用
- 資料庫高可用
- 入口層可伸縮
- 業務層可伸縮
- 緩存層可伸縮
- 資料庫可伸縮
下面來分層介紹實踐方法。
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結果一緻的情況下會使用緩存，其餘情況從資料庫讀，但寫入緩存。
- 逐個用戶端通知使用新配置。
- 水準拆分
- 垂直拆分
- 定期滾動