網站的可用就是指網站可以進行有效訪問，不可用就是服務器掛了，無法訪問了，稱為網站故障。
通常用多少個9來衡量網站的可用性。
如QQ的可用性為4個9，即99.99%，那么QQ一年之中不可用時間為：365×24×60×（1-99.99%）≈ 53分鐘。

不可用的主要原因：
a.服務器硬件故障；
b.網站升級發布引起的宕機；

一個典型的網站設計基本分層架構：
應用層：不同業務產品，主要處理網站應用的業務邏輯；
服務層：共同的復用業務，如登錄服務、賬戶管理等；
數據層：數據庫服務、文件服務、緩存服務、搜索服務等

構建高可用架構的網站，主要從以上三個方面進行。

一、高可用的應用

分兩種情況：應用無狀態和應用有狀態

1.1 應用無狀態

所謂無狀態的應用是指應用服務器不保存業務的上下文信息，而僅根據每次請求提交的數據進行相應的業務邏輯處理，多個服務實例（服務器）之間完全對等 ，請求提交到任意服務器，處理結果都是完全一樣的。

使用負載均衡進行無狀態服務的失效轉移

負載均衡是指將流量和數據分攤到一個集群組成的多臺服務器上，提高整體的負載處理能力。當任意一臺服務器宕機時，負載均衡服務器通過心跳監測機制發現該服務失去響應，就會把它從服務器列表中刪除，而將請求發送到其他服務器上。為了保證系統的高可用，即使流量很小的應用，也應該至少部署兩臺應用服務器，使用負載均衡技術構建一個小型的集群。

負載均衡可以通過開源的免費軟件或負載均衡硬件實現，都提供失效轉移功能。

1.2 應用有狀態

由于業務總是有狀態的，常常將這些狀態（上下文對象）保存在會話（Session）中。此時面臨的主要問題就是應用服務器集群的Session管理。
集群環境下，Session管理主要有以下幾種方案：

• Session復制
  定義：應用服務器開啟Web容器的Session復制功能，集群中的幾臺服務器之間進行同步Session對象，使得每臺服務器上都保存所有用戶的Session信息。
  優點：任何一臺服務器宕機都不會導致Session的丟失，而服務器使用Session時，只需要從本機獲取即可。
  缺點：Session復制時的同步操作，會占用服務器和網絡資源；每個服務器上都保存所有Session，在大量用戶訪問時，Session會占用大量內存，甚至超出服務器內存。

• Session綁定
  定義：負載均衡服務器利用源地址Hash算法，將來自同一IP的請求分發到同一臺服務器上，這種方法又叫會話黏滯。
  缺點：不符合高可用的要求，一旦某臺應用服務器宕機，那么該機上的Session就會丟失，用戶請求切換到其他服務器上就會因為沒有Session而無法完成業務。很少采用該方式。

• 利用Cookie記錄Session
  定義：將Session通過Cookie保存在瀏覽器，每次請求時，將Session放在請求中發送給服務器，服務器處理完請求后，再將修改過的Session通過Cookie響應給瀏覽器。
  缺點：每次都傳輸Cookie，影響性能；如果用戶關閉Cookie，訪問就會不正常；Cookie大小有限制，能記錄的信息有限。
  優點：簡單易用，支持應用服務器的線性伸縮，許多網站或多或少都會使用Cookie記錄Session。

• Session服務器
  定義：獨立部署Session服務器，統一管理Session，應用服務器每次讀寫Session時，都訪問Session服務器。
  實現：一種簡單的方法是利用分布式緩存、數據庫等，在這些產品的基礎上進行包裝，使其符合Session的存儲和訪問要求。如果業務場景對Session管理有比較高的要求，比如利用Session服務集成單點登錄（SSO）、用戶服務等，則需要開發專門的Session服務管理平臺。

二、高可用的服務

可復用的服務模塊為業務產品提供基礎公共服務，大型網站中這些服務通常都獨立分布式部署，被具體應用遠程調用。是一種無狀態的服務，可以使用類似負載均衡的失效轉移策略實現高可用。
此外，具體實踐中，還有以下幾點高可用的服務策略：

• 分級管理
  核心應用和服務、優先級低的服務區別分配不同的資源
• 超時設置
  在應用程序中設置服務調用的超時時間，一旦超時，通信框架就拋出異常，應用程序根據服務調度策略，可選擇繼續重試或者將請求轉移到提供相同服務的其他服務器上。
• 異步調用
  應用服務通過消息隊列等異步方式進行調用，避免一個服務失敗導致整個請求失敗的情況。但對于必須確認服務調用成功才能進行下一步操作的應用不適合使用異步調用。
• 服務降級
  在訪問高峰期，為保證核心應用和功能的正常，對服務降級
• 拒絕服務：拒絕低優先級應用的調用，減少服務調用的并發數或隨機拒絕部分調用請求
• 關閉功能：關閉部分不重要的服務或非核心服務
• 冪等級設計
  在服務層必須保證服務重復調用和一次調用產生的結果相同，即服務具有冪等性。

三、高可用的數據

主要是指數據存儲的高可用（不包含緩存數據的高可用），主要手段是數據備份和失效轉移。

CAP原理
CAP原理認為，一個提供數據服務的存儲系統無法同時滿足數據一致性（Consistency）、數據可用性(Avalibaility)、分區耐受性（Partition Tolerance，系統具有跨網絡分區的伸縮性）這三個條件。大型網站通常選擇選擇強化可用性和伸縮性，而在一定程度上犧牲一致性。
</br>數據一致性分類

• 數據強一致：各個副本的數據在物理存儲中總是一致的；數據更新操作和操作響應總是一致的。

• 數據用戶一致：數據在物理存儲的各個副本的數據可能是不一致的，但是終端用戶訪問時，通過糾錯和校驗機制，可以確定一個一致的且正確的數據返回給用戶。網站通常達到這一級別的一致性。

• 數據最終一致性：一致性最弱的一種，即物理存儲的數據可能是不一致的，不同用戶同時訪問的結果返回也可能不一致，但系統經過一段時間的自我恢復和修正，數據會達到最終一致。

• 數據備份
  主要分為數據冷備份和熱備份。冷備份是指定期將數據復制到某種存儲介質。這種方式不能保證數據最終一致和數據可用，只是作為一種傳統數據保護手段使用。熱備份則是指對數據實時備份，分為異步熱備和同步熱備。

• 異步熱備份
  將服務器分為主、從服務器，數據寫入時，由主服務器的寫操作代理模塊將數據寫入本機存儲系統后立即返回寫操作成功的響應，然后通過異步線程將寫操作同步到從服務器。

• 同步熱備份
  在應用程序客戶端并發向多個存儲服務器同時寫入數據，然后等待所有存儲服務器都返回操作成功的響應后，再通知應用程序寫操作成功。這種情況下，沒有主從之分，完全對等，便于管理和維護。由于并發寫，所以性能和異步熱備份差不多。

關系型數據庫的Master-Slave同步機制不但解決了數據備份問題，還改善了性能：使用讀寫分離方式，寫在Master，讀在Slaver。
NoSQL都提供完備的實時備份機制。

• 失效轉移
  某臺服務器宕機后，將讀寫操作轉移到其他服務器上。失效轉移操作主要由三部分組成：失效確認、訪問轉移、數據恢復
• 失效確認：心跳監測和應用程序的訪問失敗報告
• 訪問轉移：對于完全對等的服務器，直接切換到對等的服務器上即可。如果存儲不對等，就要重新計算路由，選擇存儲服務器。
• 數據恢復：將數據副本數目恢復到設定值

四、軟件質量保證

• 網站發布：使用發布腳本完成，逐步更新
• 自動化測試
• 預發布驗證：先把代碼發到預發布服務器上進行驗證，預發布服務器與正式服務器所有環境均一致，只是外部無法訪問。
• 代碼控制：一般采用分支開發，主干發布
• 自動化發布
• 灰度發布

五、網站運行監控

• 監控數據采集
• 用戶行為日志收集：主要有①服務器端收集②客戶端瀏覽器通過嵌入專門的JavaScript收集；由于日志數據量巨大，很多網站逐步開發基于實時計算框架Storm的日志統計與分析工具。
• 服務器性能監控：如系統Load、內存占用、硬盤IO、網絡IO等，使用較多的工具是Ganglia
• 運行數據報告：監控一些與具體業務相關的技術和業務指標，比如緩沖命中率、平均響應延時時間等
• 監控管理
• 系統報警
• 失效轉移
• 自動降級