第五章 萬無一失：網站的高可用架構
5.1網站可用性的度量和考覈
通常用多少個9來衡量網站可用性，qq是4個9qq服務99.99%可用，twitter 不足2個9
5.2高可用的網站架構
由於硬件故障是常態，那麼網站高可用主要目的是保證硬件故障的情況下服務依舊可用，數據依然保存並能夠被能夠被訪問主要手段就是數據和服務的冗餘備份以及失效轉移。
一般網站架構都分爲：
應用層：處理業務邏輯；
服務層：提供可複用服務；
數據層：提供數據服務
應用層爲了應對高併發會通過集羣，利用心跳檢測剔除不用服務器，把請求轉移到可用服務器。
服務層和應用層類似。
數據層寫入時同步複製利用數據冗餘。
5.3高可用應用
5.3.1通過負載均衡進行無狀態服務的失效轉移
5.3.2應用服務器集羣的Session管理
1.Session複製
集羣的所有服務器之間同步Session，適用小規模集羣，大規模集羣大量Session信息同步佔去太多系統資源。
2.Session綁定
同一IP的用戶請求發送到一臺服務器上，這種方法也叫會話粘滯，但是這種Session管理不能很好支持網站高可用，某臺綁定服務器意外宕機，Session丟失則將無法完成任務。
3.利用Cookie記錄Session
4.Session服務器
5.4高可用的服務
1.分級管理
服務器分級，核心業務優先使用更好的硬件；服務部署進行必要的隔離，避免連鎖反應。
2.超時設置
在應用程序中設置服務調用超時，以便服務器宕機能及時轉換到正常服務器
3.異步調用
應用對服務通過消息隊列異步方式完成，避免一個服務失敗導致整個請求失敗；例如，新用戶註冊，可以將用戶信息寫入，發送註冊郵件，開通權限分別到各自的消息隊列，避免一個不成全部失敗。當然也不是所有服務都可以用異步調用，對於獲取用戶信息則會延長響應所以不合適，需要立即確認的異步不合適。
4.服務降級
拒絕服務：拒絕低優先級或者隨機拒絕，節約資源讓一部分請求成功，避免導致所有都失敗。
關閉服務：關閉非核心業務，如淘寶雙十一關閉確認收貨以及退款服務
5.冪等性設計
必須在服務層保證重複調用不會影響結果，即服務具有冪等性。例如，設置性別爲男，不管設置多少次都一樣；轉賬則需要通過交易編號進行服務調用有效性校驗。
5.5高可用的數據
數據是最有價值的
5.5.1CAP原理
C（Consistency）數據一致性；A（Availibility）數據可用性；P（Patition Tolerance）分區耐受性
爲了數據的高可用網站通常會捨棄另一個重要的標準：數據一致性
高可用數據有如下幾層的含義。
數據持久性：既要持久性存儲也要多副本存儲
數據可訪問性：數據副本切換訪問應很快完成
數據一致性：
數據強一致：副本數據在存儲處總是一致，即操作響應更新失敗，那麼數據一定沒有更新
數據用戶一致：副本存儲處可能不一致，但是終端返回給用戶時候通過校驗和糾錯保證返回到用戶的是正確的
數據最終一致：副本存儲可能不一致，返回給用戶的多次數據也不一致，通過短時間修復達到一致
5.5.2數據備份
冷備份：定時備份數據到存儲介質
廉價但是不能保證數據一致性以及數據不完整（從最近備份點到事故時間點之間的數據丟失）
熱備份：
分爲同步熱備份：副本數據同步更新，應用程序收到失敗響應那麼可能會有部分副本已經成功的，不存在主從機。
異步熱備份：應用程序收到寫成功響應時，只寫成功一份，之後纔會異步將其他副本進行數據同步但是這個過程可能會有數據或副本同步失敗，存在主從機之分
5.5.3失效轉移
數據服務一臺服務器宕機，那麼應用程序對這條服務器的所有操作都將重新路由到新的服務器，保證數據訪問不會失敗。
過程包括：失效確認---訪問轉移---數據恢復
1.失效確認
心跳機制和應用程序訪問失敗報告
2.訪問轉移
重新路由到等同服務器，存儲數據完全一樣的稱爲等同服務器
3.數據恢復
將因宕機缺少的數據即使進行恢復
5.6高可用網站的軟件質量保證
5.6.1網站發佈
5.6.2自動化檢測
5.6.3預發佈驗證
處理錯誤應該是快速失敗原則，如果系統在啓動時發現問題就立刻拋出異常，停止啓動等待工程師解決
5.6.4代碼控制
1.主幹開發，分支發佈
2.分支開發，主幹發佈
5.6.5自動化發佈
5.6.6灰度發佈
5.7網站運行監控
不允許沒有監控的系統上線
5.7.1監控數據採集
1.用戶行爲信息採集
服務端日誌收集
客戶瀏覽器日誌收集
2.服務性能收集
3.運行數據收集
5.7.2監控管理
系統管理；失效轉移；優雅自動降級
第六章 永無止境：網站的伸縮性架構
所謂網站伸縮性是指不需要改變網站的軟硬設計，僅僅通過改變部署服務器數量就可以擴大或縮小網站的服務處理能力。
6.1網站架構的伸縮性設計
網站伸縮性可以分爲兩類，一類是根據功能進行物理分離；一類是單一功能根據集羣實現伸縮，前者是不同服務器部署不同的服務，提供不同功能；後者是集羣部署相同的服務，提供相同的功能。
6.1.1不同功能實現物理分離
縱向分離將不同業務模塊分離部署
橫向分離力度可以很小，甚至可以一個關鍵頁面部署一個獨立服務
6.1.2單一功能通過集羣實現伸縮性
隨着訪問量逐步增加，單個功能部署一臺單獨的服務器也是不能滿足的，不得不多個服務器部署一個功能
【一頭牛拉不動車，不要首先找一頭更強壯的牛，而是用兩頭牛】
6.2應用服務器伸縮性設計
負載均衡分爲以下幾種：
6.2.1HTTP重定向負載均衡
這種負載均衡方案優點是比較簡單，缺點是瀏覽器需要兩次請求服務器才能進行一次訪問，性能差。
6.2.2DNS域名解析負載均衡
將負載均衡的工作交給了DNS，但是修改DNS記錄生效時間較長，容易導致DNS域名解析到已經下線的服務器上。
大型網站總使用DNS域名解析，利用域名解析作爲第一級負載均衡手段，得動但是不是實際提供Web服務的服務器，然後在進行負載均衡，將請求發動到真正的服務器上。
6.2.3反向代理負載均衡
6.2.4IP負載均衡
6.2.5數據鏈路層負載均衡
三角傳輸模式的鏈路層負載均衡是目前大型網站使用最廣的負載均衡手段。Linux平臺最好的開源產品是LVS
6.2.6負載均衡算法
負載均衡服務器實現可以分爲兩部分：
1.根據負載均衡算法和服務器列表的集羣中其中一臺服務器地址
2.將請求數據發送到此地址服務器
具體的負載均衡算法有:
輪詢：所有請求依次發送到每臺應用服務器
加權輪詢：根據服務器性能，在輪詢的基礎上進行分發
隨機
最少連接
源地址散列：根據請求來源的的IP進行Hash值計算，得到應用服務器，這樣一來相同IP的請求會在一臺服務器進行處理
6.3分佈式緩存的伸縮性設計
分佈式緩存跟應用服務器緩存不太一樣，不適合只用負載均衡就能解決的，應用用服務器上都是相同應用，而緩存服務器存儲的是不同的數據，並且新上線的緩存服務器是沒有數據的，下線的緩存服務器還有許多數據。這嚴重限制了分佈式緩存的設計伸縮性。
6.3.1Memcached分佈式緩存集羣的訪問模型
6.3.2Memcached分佈式緩存伸縮性挑戰
獲取哪一臺服務器，一般算法就是用服務器臺數n除以存儲數據key值的hash值的餘數得到具體哪臺服務器。
但是問題是如果存儲數據是三臺服務器，假設3/hash值的餘數爲1，當讀取緩存時服務器數量增加爲4臺，4/hash的餘數就不一定是1啦，這就導致讀取緩存失敗就需要讀取數據庫，增加數量增加，失敗率增加，數據庫壓力劇增。這是一一個問題。
6.3.3分佈式緩存一致性算法
緩存數據key的hash值在hash環上順時針尋找最近的node節點，這樣即使添加新的節點也只會影響一小段。
增加node3會影響node1的部分數據，但是node0和node2不受影響，那麼四臺服務器就會出現不是負載均衡的場景。
那麼只需要將node節點用一組虛擬節點均勻分佈進行代替，就能很大程度解決不均衡問題。
6.4數據存儲服務器的伸縮性設計
數據存儲服務器的集羣相比緩存服務器集羣有着更高的數據一致性和持久性
6.4.1關係型數據庫的伸縮性設計
【5-8章爲本書核心，四章內容太多就分開記錄啦】
長按關注，一起進步！