5、高可用-萬無一失
廉價的服務器硬件故障是常態，網站的高可用架構設計的主要目的就是保證服務器硬件故障時服務依然可用、數據依然保存並能夠訪問。
實現上述高可用方案的主要數據和服務的手段是冗餘備份和失效轉移。
應用層：應對高併發，負載均衡，心跳檢測監控，不可用時候剔除。
服務層：通過集羣方式實現高可用，被應用層通過分佈式調用框架訪問，分佈式調用框架會在客戶端程序中實現軟件負載均衡、心跳檢測。
數據層：同步複製，冗餘備份。
高可用的應用
健身房小姐姐填表單的栗子。
無狀態性！！！
可以直接通過負載均衡實現無狀態服務的負載均衡。
應用服務器集羣的 Session 管理
事實上，業務總是有狀態的，在交易類的電商網站需要有購物車記錄的購買信息，用戶每次購買請求都是向購物車中增加商品；在社交類網站中，需要記錄用戶的當前登錄狀態、最新發布的消息和好友列表等，每次刷新頁面都需要更新這些信息。
- Session 複製
應用服務器開啓 Web 容器的 Session 複製功能，在集羣中的幾臺服務器之間同步 Session 對象，每臺服務器保存所有用戶的 Session 信息。
當集羣規模較大時候，大量的 Session 複製通信佔用服務器的網絡資源較大，甚至有內存不夠存 Session 情況。
- Session 綁定
Session 綁定可以利用負載均衡的源地址 Hash 算法實現，總是將同一個 IP 的請求分發到同一臺服務器上，也可以根據 Cookie 信息將同一個用戶的請求分發到同一臺服務器上。這個負載均衡服務器必須工作在 HTTP 協議層上。這樣就能保證這個用戶的請求都在同一臺服務器上，這種方法又被成爲會話粘滯。
但是 Session 綁定的方案不符合高可用程序，某臺服務器宕機後一些依賴此服務器的用戶的服務就不可用了。
- 利用 Cookie 記錄 Session
- Cookie 大小限制，記錄信息有限
- 每次響應都要傳輸 Cookie，影響性能
- 如果用戶關閉 Cookie 功能，訪問就會不正常
- Session 分離
獨立的 Session 服務器或者集羣，基礎服務平臺。
高可用的服務
可複用的服務和應用一樣，也是無狀態的服務，此可以使用類似負載均衡的失效轉移策略實現高可用服務。
- 分級管理
- 核心應用和服務優先使用更好的硬件，運維響應時間也要迅速
- 超時設置
- 超時後繼續重試或者將請求失效轉移到提供相同服務的其他服務器上
- 異步調用
- 消息隊列等異步調用的方式
- 服務降級
- 拒絕服務？關閉服務？
- 拒絕服務：拒絕優先級低的應用調用，減少服務器的併發數，保證核心功能正常調用；或者隨機拒絕部分請求調用，節約資源。
- 關閉服務：關閉不中喲的部分服務，或者服務內部關閉部分不重要的功能。
- 冪等性設計
- 服務重複調用是無法避免的，應用層也不需要關心服務是否真的失效，只要沒有得到調用成功的響應，就可以認爲調用失效，並充實服務調用。因此必須在服務層保證服務重複調用和調用一次產生的結果相同，即服務具有冪等性。
高可用的數據
數據備份和失效轉移機制。
爲了保證數據的高可用，網站通常會犧牲另一個很重要的指標：數據一致性。
**
CAP 原理
數據持久性
數據可訪問性
數據一致性
- 數據強一致
- 數據用戶一致
- 數據最終一致
數據備份
異步熱備份、同步熱備份
失效確認
訪問轉移
轉移到存儲的數據完全一樣的服務器上（對等服務器）
如果服務不對等，就需要重新計算路由，選擇存儲服務器。
數據恢復
。。。
軟件質量保證
網站發佈
飛行中給飛機換個引擎。
自動化測試
全面的迴歸測試。
預發佈驗證
預發佈機器。
代碼控制
主幹發佈，分支開發。主幹開發，分支發佈。
~~
自動化發佈
灰度發佈
第一天發佈 0~999 服務器，遇到故障回滾。
第二天發佈 1000~1999 服務器，遇到故障回滾。
。。。
網站運行監控
不允許沒有監控的系統上線。
監控數據採集
- 用戶行爲日誌收集
- 服務端日誌手機
- 客戶端瀏覽器日誌收集
- 服務器性能監控
- 運行數據報告
監控管理
- 系統報警
- 失效轉移
- 自動優雅降級
EOF！