《大型网站技术架构：核心原理与案例分析》读书笔记-高可用
萬無一失：網站的高可用架構
1.網站可用性的度量
網站的頁面能完整呈現在最終用戶面前，需要經過很多個環節，任何一個環節出了 問題，都可能導致網站頁面不可訪問。DNS會被劫持、CDN服務可能會掛掉、網站服務 器可能會宕機、網絡交換機可能會失效、硬盤會損壞、網卡會松掉、甚至機房會停電、 空調會失靈、程序會有Bug、黑客會攻擊、促銷會引來大量訪問、第三方合作伙伴的服務 會不可用……要保證一個網站永遠完全可用幾乎是一件不可能完成的使命。
1.1?網站可用性度量
網站不可用也被稱作網站故障，業界通常用多少個9來衡量網站的可用性，如QQ的 可用性是4個9，即QQ服務99.99%可用，這意味著QQ服務要保證其在所有運行時間中， 只有0.01 %的時間不可用，也就是一年中大約最多53分鐘不可用。
網站不可用時間（故障時間）=故障修復時間點-故障發現（報告）時間點
網站年度可用性指標=(1-網站不可用時間/年度總時間）xl00%
對于大多數網站而目，2個9是基本可用，網站年度不可用時間小于88小時；3個9 是較高可用，網站年度不可用時間小于9小時；4個9是具有自動恢復能力的高可用，網 站年度不可用時間小于53分鐘；5個9是極高可用性，網站年度不可用時間小于5分鐘。
2.高可用的網站架構
硬件故障是常態，網站的高可用架構設計的主要目的就是保證服務器硬件故障 時服務依然可用、數據依然保存并能夠被訪問。?實現上述高可用架構的主要手段是數據和服務的冗余備份及失效轉移，一旦某些服務器宕機，就將服務切換到其他可用的服務器上，如果磁盤損壞，則從備份的磁盤讀取 數據。
網站典型的分層模型是三層，即應用層、服務層、數據層；各層之間具有相對獨立性， 應用層主要負責具體業務邏輯處理；服務層負責提供可復用的服務；數據層負責數據的 存儲與訪問。中小型網站在具體部署時，通常將應用層和服務層部署在一起，而數據層 則另外部署，如圖5.3所示（事實上，這也是網站架構演化的第一步）。
在復雜的大型網站架構中，劃分的粒度會更小、更詳細，結構更加復雜，服務器規 模更加龐大，但通常還是能夠把這些服務器劃分到這三層中。如圖5.4所示。
不同的業務產品會部署在不同的服務器集群上，如某網站的文庫、貼吧、百科等屬 于不同的產品，部署在各自獨立的服務器集群上，互不相干。這些產品又會依賴一些共 同的復用業務，如注冊登錄服務、Session管理服務、賬戶管理服務等，這些可復用的業 務服務也各自部署在獨立的服務器集群上。至于數據層，數據庫服務、文件服務、緩存 服務、搜索服務等數據存儲與訪問服務都部署在各自獨立的服務器集群上。
位于應用層的服務器通常為了應對高并發的訪問請求，會通過負載均衡設備將一組 服務器組成一個集群共同對外提供服務，當負載均衡設備通過心跳檢測等手段監控到某 臺應用服務器不可用時，就將其從集群列表中剔除，并將請求分發到集群中其他可用的 服務器上，使整個集群保持可用，從而實現應用高可用。位于服務層的服務器情況和應用層的服務器類似，也是通過集群方式實現高可用， 只是這些服務器被應用層通過分布式服務調用框架訪問，分布式服務調用框架會在應用 層客戶端程序中實現軟件負載均衡，并通過服務注冊中心對提供服務的服務器進行心跳檢 測，發現有服務不可用，立即通知客戶端程序修改服務訪問列表，剔除不可用的服務器。位于數據層的服務器情況比較特殊，數據服務器上存儲著數據，為了保證服務器宕 機時數據不丟失，數據訪問服務不中斷，需要在數據寫入時進行數據同步復制，將數據 寫入多臺服務器上，實現數據冗余備份。當數據服務器宕機時，應用程序將訪問切換到 有備份數據的服務器上。
3.高可用的應用
應用層主要處理網站應用的業務邏輯，因此有時也稱作業務邏輯層，應用的一個顯 著特點是應用的無狀態性。所謂無狀態的應用是指應用服務器不保存業務的上下文信息，而僅根據每次請求提 交的數據進行相應的業務邏輯處理，多個服務實例（服務器）之間完全對等，請求提交到任意服務器，處理結果都是完全一樣的。
3.1通過負載均衡進行無狀態服務的失效轉移
不保存狀態的應用給高可用的架構設計帶來了巨大便利，既然服務器不保存請求的 狀態，那么所有的服務器完全對等，當任意一臺或多臺服務器宕機，請求提交給集群中 其他任意一臺可用機器處理，這樣對終端用戶而言，請求總是能夠成功的，整個系統依 然可用。對于應用服務器集群，實現這種服務器可用狀態實時監測、自動轉移失敗任務 的機制是負載均衡。
負載均衡，顧名思義，主要使用在業務量和數據量較高的情況下，當單臺服務器不 足以承擔所有的負載壓力時，通過負載均衡手段，將流量和數據分攤到一個集群組成的 多臺服務器上，以提高整體的負載處理能力。目前，不管是幵源免費的負載均衡軟件還 是昂貴的負載均衡硬件，都提供失效轉移功能。在網站應用中，當集群中的服務是無狀 態對等時，負載均衡可以起到事實上高可用的作用，如圖5.5所示。
當Web服務器集群中的服務器都可用時，負載均衡服務器會把用戶發送的訪問請求 分發到任意一臺服務器上進行處理，而當服務器10.0.0.1宕機時，負載均衡服務器通過心 跳檢測機制發現該服務器失去響應，就會把它從服務器列表中刪除，而將請求發送到其 他服務器上，這些服務器是完全一樣的，請求在任何一臺服務器中處理都不會影響最終 的結果。
由于負載均衡在應用層實際上起到了系統高可用的作用，因此即使某個應用訪問量 非常少，只用一臺服務器提供服務就綽綽有余，但如果需要保證該服務高可用，也必須 至少部署兩臺服務器，使用負載均衡技術構建一個小型的集群。
3.2應用服務器集群的Session管理
應用服務器的高可用架構設計主要基于服務無狀態這一特性，但是事實上，業務總 是有狀態的，在交易類的電子商務網站，需要有購物車記錄用戶的購買信息，用戶每次 購買請求都是向購物車中增加商品；在社交類的網站中，需要記錄用戶的當前登錄狀態、 最新發布的消息及好友狀態等，用戶每次刷新頁面都需要更新這些信息。
Web應用中將這些多次請求修改使用的上下文對象稱作會話（Session )，單機情況下， Session可由部署在服務器上的Web容器（如JBoss )管理。在使用負載均衡的集群環境 中，由于負載均衡服務器可能會將請求分發到集群任何一臺應用服務器上，所以保證每 次請求依然能夠獲得正確的Session比單機時要復雜很多。
集群環境下，Session管理主要有以下幾種手段。
a.Session 復制
應用 服務器開啟Web容器的Session復制功能，在集群中的幾臺服務器之間同步Session對象， 使得每臺服務器上都保存所有用戶的Session信息，這樣任何一臺機器宕機都不會導致 Session數據的丟失，而服務器使用Session時，也只需要在本機獲取即可。如網5.6。
這種方案雖然簡單，從本機讀取Session信息也很快速，但只能使用在集群規模比較 小的情況下。當集群規模較大時，集群服務器間需要大量的通信進行Session復制，占用 服務器和網絡的大量資源，系統不堪負擔。而且由于所有用戶的Session信息在每臺服務 器上都有備份，在大量用戶訪問的情況下，甚至會出現服務器內存不夠Session使用的情況而大型網站的核心應用集群就是數千臺服務器，同時在線用戶可達千萬，因此并不 適用這種方案。
b.Session 綁定
Session綁定可以利用負載均衡的源地址Hash算法實現，負載均衡服務器總是將來源 于同一 IP?的請求分發到同一臺服務器上（也可以根據Cookie信息將同一個用戶的請求總 是分發到同一臺服務器上，當然這時負載均衡服務器必須工作在HTTP協議層上。這樣在整個會話期間，用戶所有的請 求都在同一臺服務器上處理，即Session綁定在某臺特定服務器上，保證Session總能在這臺服務器上獲取。這種方法又被稱作會話黏滯，如圖5.7所示
但是Session綁定的方案顯然不符合我們對系統高可用的需求，因為一旦某臺服務器 宕機，那么該機器上的Session也就不復存在了，用戶請求切換到其他機器后因為沒有 Session而無法完成業務處理。因此雖然大部分負載均衡服務器都提供源地址負載均衡算 法，但很少有網站利用這個算法進行Session管理。
c.利用 Cookie 記錄 Session
早期的企業應用系統使用C/S (客戶端/服務器）架構，一種管理Session的方式是將 Session記錄在客戶端，每次請求服務器的時候，將Session放在請求中發送給服務器，服 務器處理完請求后再將修改過的Session響應給客戶端。
網站沒有客戶端，但是可以利用瀏覽器支持的Cookie記錄Session，如圖5.8所示。
?
利用Cookie記錄Session也有一些缺點，比如受Cookie大小限制，能記錄的信息有 限；每次請求響應都需要傳輸Cookie，影響性能；如果用戶關閉Cookie，訪問就會不正 常。但是由于Cookie的簡單易用，可用性高，支持應用服務器的線性伸縮，而大部分應 用需要記錄的Session信息又比較小。因此事實上，許多網站都或多或少地使用Cookie 記錄 Session.
d.Session服務器
Session服務器利用獨立部署的Session服務器(集群）統一?管理Session， 應用服務器每次讀寫Session時，都訪問Session服務器，如圖5.9所示。
這種解決方案事實上是將應用服務器的狀態分離，分為無狀態的應用服務器和有狀 態的Session服務器，然后針對這兩種服務器的不同特性分別設計其架構。對于有狀態的Session服務器，一種比較簡單的方法是利用分布式緩存、數據庫等， 在這些產品的基礎上進行包裝，使其符合Session的存儲和訪問要求。如果業務場景對 Session管理有比較高的要求，比如利用Session服務集成單點登錄（SSO )、用戶服務等 功能，則需要開發專門的Session服務管理平臺。
4. 高可用的服務
可復用的服務模塊為業務產品提供基礎公共服務，大型網站中這些服務通常都獨立 分布式部署，被具體應用遠程調用。可復用的服務和應用一樣，也是無狀態的服務，因 此可以使用類似負載均衡的失效轉移策略實現高可用的服務。
除此之外，具體實踐中，還有以下幾點高可用的服務策略。
a.分級管理
運維上將服務器進行分級管理，核心應用和服務優先使用更好的硬件，在運維響應 速度上也格外迅速。顯然，用戶及時付款購物比能不能評價商品更重要，所以訂單、支 付服務比評價服務有更高優先級。同時在服務部署上也進行必要的隔離，避免故障的連鎖反應。低優先級的服務通過 啟動不同的線程或者部署在不同的虛擬機上進行隔離，而高優先級的服務則需要部署在 不同的物理機上，核心服務和數據甚至需要部署在不同地域的數據中心。
b.超時設置
由于服務端宕機、線程死鎖等原因，可能導致應用程序對服務端的調用失去響應， 進而導致用戶請求長時間得不到響應，同時還占用應用程序的資源，不利于及時將訪問 請求轉移到正常的服務器上。
在應用程序中設置服務調用的超時時間，一旦超時，通信框架就拋出異常，應用程 序根據服務調度策略，可選擇繼續重試或將請求轉移到提供相同服務的其他服務器上。
c.異步調用
應用對服務的調用通過消息隊列等異步方式完成，避免一個服務失敗導致整個應用 請求失敗的情況。如提交一個新用戶注冊請求，應用需要調用三個服務：將用戶信息寫 入數據庫，發送賬戶注冊成功郵件，開通對應權限。如果采用同步服務調用，當郵件隊 列阻塞不能發送郵件時，會導致其他兩個服務也無法執行，最終導致用戶注冊失敗。
如果釆用異步調用的方式，應用程序將用戶注冊信息發送給消息隊列服務器后立即 返回用戶注冊成功響應。而記錄用戶注冊信息到數據庫、發送用戶注冊成功郵件、調用 用戶服務幵通權限這三個服務作為消息的消費者任務，分別從消息隊列獲取用戶注冊信 息異步執行。即使郵件服務隊列阻塞，郵件不能成功發送，也不會影響其他服務的執行， 用戶注冊操作可順利完成，只是晚一點收到注冊成功的郵件而已。
當然不是所有服務調用都可以異步調用，對于獲取用戶信息這類調用，釆用異步方 式會延長響應時間，得不償失。對于那些必須確認服務調用成功才能繼續下一步操作的 應用也不合適使用異步調用。
d.服務降級
在網站訪問高峰期，服務可能因為大量的并發調用而性能下降，嚴重時可能會導致 服務宕機。為了保證核心應用和功能的正常運行，需要對服務進行降級。降級有兩種手 段：拒絕服務及關閉服務。
拒絕服務：拒絕低優先級應用的調用，減少服務調用并發數，確保核心應用正常使 用；或者隨機拒絕部分請求調用，節約資源，讓另一部分請求得以成功，避免要死大家 一起死的慘劇。貌似Twitter比較喜歡使用隨機拒絕請求的策略，經常有用戶看到請求失 敗的故障頁面，但是問下身邊的人，其他人都正常使用，自己再刷新頁面，也好了。
關閉功能：關閉部分不重要的服務，或者服務內部關閉部分不重要的功能，以節約 系統開銷，為重要的服務和功能讓出資源。淘寶在每年的“雙十一”促銷中就使用這種 方法，在系統最繁忙的時段關閉“評價”、“確認收貨”等非核心服務，以保證核心交易服 務的順利完成。
e.冪等性設計
應用調用服務失敗后，會將調用請求重新發送到其他服務器，但是這個失敗可能是 虛假的失敗。比如服務已經處理成功，但因為網絡故障應用沒有收到響應，這時應用重 新提交請求就導致服務重復調用，如果這個服務是一個轉賬操作，就會產生嚴重后果。服務重復調用是無法避免的，應用層也不需要關心服務是否真的失敗，只要沒有收 到調用成功的響應，就可以認為調用失敗，并重試服務調用。因此必須在服務層保證服 務重復調用和調用一次產生的結果相同，即服務具有冪等性。有些服務天然具有冪等性，比如將用戶性別設置為男性，不管設置多少次，結果都 一樣。但是對于轉賬交易等操作，問題就會比較復雜，需要通過交易編號等信息進行服 務調用有效性校驗，只有有效的操作才能繼續執行。
5.高可用的數據
不同于高可用的應用和服務，由于數據存儲服務器上保存的數據不同，當某臺服務 器宕機的時候，數據訪問請求不能任意切換到集群中其他的機器上。
保證數據存儲高可用的手段主要是數據備份和失效轉移機制。數據備份是保證數據 有多個副本，任意副本的失效都不會導致數據的永久丟失，從而實現數據完全的持久化。 而失效轉移機制則保證當一個數據副本不可訪問時，可以快速切換訪問數據的其他副本， 保證系統可用。
關于緩存服務的高可用，在實踐中爭議很大，一種觀點認為緩存已經成為網站數據 服務的重要組成部分，事實上承擔了業務中絕大多數的數據讀取訪問服務，緩存服務失 效可能會導致數據庫負載過高而宕機，進而影響整個網站的可用性，因此緩存服務需要 實現和數據存儲服務同樣的高可用。
另一種觀點認為，緩存服務不是數據存儲服務，緩存服務器宕機引起緩存數據丟失 導致服務器負載壓力過高應該通過其他手段解決，而不是提高緩存服務本身的高可用。
筆者持后一種觀點，對于緩存服務器集群中的單機宕機，如果緩存服務器集群規模 較大，那么單機宕機引起的緩存數據丟失比例和數據庫負載壓力變化都較小，對整個系 統影響也較小。擴大緩存服務器集群規模的一個簡單手段就是整個網站共享同一個分布 式緩存集群，單獨的應用和產品不需要部署自己的緩存服務器，只需要向共享緩存集群 申請緩存資源即可。并且通過邏輯或物理分區的方式將每個應用的緩存部署在多臺服務 器上，任何一臺服務器宕機引起的緩存失效都只影響應用緩存數據的一小部分，不會對 應用性能和數據庫負載造成太大影響。
?5.1?CAP 原理
高可用的數據有如下幾個層面的含義。
數據持久性:保證數據可持久存儲，在各種情況下都不會出現數據丟失的問題。為了實現數據的 持久性，不但在寫入數據時需要寫入持久性存儲，還需要將數據備份一個或多個副本， 存放在不同的物理存儲設備上，在某個存儲故障或災害發生時，數據不會丟失。
數據可訪問性:在多份數據副本分別存放在不同存儲設備的情況下，如果一個數據存儲設備損壞， 就需要將數據訪問切換到另一個數據存儲設備上，如果這個過程不能很快完成（終端用 戶幾乎沒有感知），或者在完成過程中需要停止終端用戶訪問數據，那么這段時間數據是 不可訪問的。
數據一致性:在數據有多份副本的情況下，如果網絡、服務器或者軟件出現故障，會導致部分副 本寫入成功，部分副本寫入失敗。這就會造成各個副本之間的數據不一致，數據內容沖 突。實踐中，導致數據不一致的情形有很多種，表現形式也多種多樣，比如數據更新返 回操作失敗，事實上數據在存儲服務器已經更新成功。
CAP原理認為，一個提供數據服務的存儲系統無法同時滿足數據一致性 (Consistency)、數據可用性（Availibility )、分區耐受性(Patition Tolerance,系統具有跨 網絡分區的伸縮性）這三個條件
在大型網站應用中，數據規模總是快速擴張的，因此可伸縮性即分區耐受性必不可少，規模變大以后，機器數量也會變得龐大，這時網絡和服務器故障會頻繁出現，要想 保證應用可用，就必須保證分布式處理系統的高可用性。所以在大型網站中，通常會選 擇強化分布式存儲系統的可用性（A )和伸縮性（P )，而在某種程度上放棄一致性（C )。 一般說來，數據不一致通常出現在系統高并發寫操作或者集群狀態不穩（故障恢復、集 群擴容……）的情況下，應用系統需要對分布式數據處理系統的數據不一致性有所了解 并進行某種意義上的補償和糾錯，以避免出現應用系統數據不正確。
具體說來，數據一致性又可分為如下幾點。
數據強一致:各個副本的數據在物理存儲中總是一致的；數據更新操作結果和操作響應總是一致 的，即操作響應通知更新失敗，那么數據一定沒有被更新，而不是處于不確定狀態。
數據用戶一致:即數據在物理存儲中的各個副本的數據可能是不一致的，但是終端用戶訪問時，通 過糾錯和校驗機制，可以確定一個一致的且正確的數據返回給用戶。
數據最終一致:這是數據一致性中較弱的一種，即物理存儲的數據可能是不一致的，終端用戶訪問 到的數據可能也是不一致的（同一用戶連續訪問，結果不同；或者不同用戶同時訪問， 結果不同），但系統經過一段時間（通常是一個比較短的時間段）的自我恢復和修正，數 據最終會達到一致。
因為難以滿足數據強一致性，網站通常會綜合成本、技術、業務場景等條件，結合 應用服務和其他的數據監控與糾錯功能，使存儲系統達到用戶一致，保證最終用戶訪問 數據的正確性。
5.2數據備份
數據冷備作為一種傳統的數據保護手段，依然在網站日常運維中使用，同時 在網站實時在線業務中，還需要進行數據熱備，以提供更好的數據可用性。數據熱備可分為兩種：異步熱備方式和同步熱備方式。
異步方式是指多份數據副本的寫入操作異步完成，應用程序收到數據服務系統的寫 操作成功響應時，只寫成功了一份，存儲系統將會異步地寫其他副本（這個過程有可能 會失敗)。如圖5.11。
在異步寫入方式下，存儲服務器分為主存儲服務器（Master )和從存儲服務器（Slave )， 應用程序正常情況下只連接主存儲服務器，數據寫入時，由主存儲服務器的寫操作代理模塊將數據寫入本機存儲系統后立即返回寫操作成功響應，然后通過異步線程將寫操作 數據同步到從存儲服務器。
同步方式是指多份數據副本的寫入操作同步完成，即應用程序收到數據服務系統的 寫成功響應時，多份數據都已經寫操作成功。但是當應用程序收到數據寫操作失敗的響 應時，可能有部分副本或者全部副本都已經寫成功了（因為網絡或者系統故障，無法返 回操作成功的響應），如圖5.12所示。
同步熱備具體實現的時候，為了提高性能，在應用程序客戶端并發向多個存儲服務 器同時寫入數據，然后等待所有存儲服務器都返回操作成功的響應后，再通知應用程序 寫操作成功。
這種情況下，存儲服務器沒有主從之分，完全對等，更便于管理和維護。存儲服務 客戶端在寫多份數據的時候，并發操作，這意味著多份數據的總寫操作延遲是響應最慢 的那臺存儲服務器的響應延遲，而不是多臺存儲服務器響應延遲之和。其性能和異步熱 備方式差不多。
傳統的企業級關系數據庫系統幾乎都提供了數據實時同步備份的機制。而一開始就 為大型網站而設計的各種NoSQL數據庫（如HBase )更是將數據備份機制作為產品最主 要的功能點之一。
關系數據庫熱備機制就是通常所說的Master-Slave同步機制。Master-Slave機制不但 解決了數據備份問題，還改善了數據庫系統的性能，實踐中，通常使用讀寫分離的方法
?訪問Slave和Master數據庫，寫操作只訪問Master數據庫，讀操作只訪問Slave數據庫。
5.3失效轉移
若數據服務器集群中任何一臺服務器宕機，那么應用程序針對這臺服務器的所有讀 寫操作都需要重新路由到其他服務器，保證數據訪問不會失敗，這個過程叫作失效轉移。
失效轉移操作由三部分組成：失效確認、訪問轉移、數據恢復。
6.高可用網站的軟件質量保證
6.1網站發布
網站發布畢竟是一次提前預知的服務器宕機，所以過程可以更柔和，對用戶影 響更小。通常使用發布腳本來完成發布，其流程如圖5.14所示。
發布過程中，每次關閉的服務器都是集群中的一小部分，并在發布完成后立即可以 訪問，因此整個發布過程不影響用戶使用。
6.2預發布驗證
在網站發布時，并不是把測試通過的代碼包直接發布到線上服務器，而是先發 布到預發布機器上，開發工程師和測試工程師在預發布服務器上進行預發布驗證，執行 一些典型的業務流程，確認系統沒有問題后才正式發布。
6.3灰度發布
大型網站的主要業務服務器集群規模非常龐大，比如某大型應用集群服務器數量超 過一萬臺。一旦發現故障，即使想要發布回滾也需要很長時間才能完成，只能眼睜睜看 著故障時間不斷增加卻干著急。為了應付這種局面，大型網站會使用灰度發布模式，將 集群服務器分成若干部分，每天只發布一部分服務器，觀察運行穩定沒有故障，第二天 繼續發布一部分服務器，持續幾天才把整個集群全部發布完畢，期間如果發現問題，只 需要回滾已發布的一部分服務器即可。如圖5.18所示。
7.網站運行監控
7.1監控數據采集
廣義上的網站監控涵蓋所有非直接業務行為的數據釆集與管理，包括供數據分析師 和產品設計師使用的網站用戶行為日志、業務運行數據，以及供運維工程師和開發工程 師使用的系統性能數據等。
a.用戶行為日志收集
用戶行為日志指用戶在瀏覽器上所做的所有操作及其所在的操作環境，包括用戶操 作系統與瀏覽器版本信息，ip地址、頁面訪問路徑、頁面停留時間等，這些數據對統計 網站PV/UV指標、分析用戶行為、優化網站設計、個性化營銷與推薦等非常重要。
具體用戶行為日志收集手段有兩種。
服務器端日志收集。這個方案比較簡單，Apache等幾乎所有Web服務器都具備曰志記錄功能，可以記錄大部分用戶行為日志，開啟Web服務器的日志記錄功能即可。其缺 點是可能會出現信息失真，如IP ±也址是代理服務器地址而不是用戶真實IP;無法識別訪 問路徑等。
客戶端瀏覽器日志收集.利用頁面嵌入專門的JavaScript腳本可以收集用戶真實的操 作行為，因此比服務器日志收集更加精準。其缺點是比較麻煩，需要在頁面嵌入特定的 JavaScript腳本來完成。此外，大型網站的用戶日志數據量驚人，數據存儲與計算壓力很大，目前許多網站 逐步開發基于實時計算框架Storm的日志統計與分析工具。
b.服務器性能監控
收集服務器性能指標，如系統Load、內存占用、磁盤10、網絡IO等對盡早做出故 障預警，及時判斷應用狀況，防患于未然，將故障扼殺在萌芽時期非常重要。此外根據 性能監控數據，運維工程師可以合理安排服務器集群規模，架構師及時改善系統性能及 調整系統伸縮性策略。
目前網站使用比較廣泛的開源性能監控工具是Ganglia，它支持大規模服務器集群， 并支持以圖形的方式在瀏覽器展示實時性能曲線。
c.運行數據報告
除了服務器系統性能監控，網站還需要監控一些與具體業務場景相關的技術和業務 指標，比如緩沖命中率、平均響應延遲時間、每分鐘發送郵件數目、待處理的任務總數等。??????????????? ?
對于服務器性能監控，網站運維人員可以在初始化系統時統一部署，應用程序開發 完全不關心服務器性能監控。而運行數據需要在具體程序中采集并報告，匯總后統一顯 示，應用程序需要在代碼中處理運行數據釆集的邏輯。
7.2監控管理
監控數據采集后，除了用作系統性能評估、集群規模伸縮性預測等，還可以根據實 時監控數據進行風險預警，并對服務器進行失效轉移，自動負載調整，最大化利用集群 所有機器的資源。
系統報警
在服務器運行正常的情況下，其各項監控指標基本穩定在一個特定水平，如果這些 指標超過某個閾值，就意味著系統可能將要出現故障，這時就需要對相關人員報警，及 時采取措施，在故障還未真正發生時就將其扼殺在萌芽狀態。
監控管理系統可以配置報警閾值和值守人員的聯系方式，報警方式除了郵件，即時 通信工具，還可以配置手機短信，語音報警，系統發生報警時，工程師即使在千里之外、 夜里睡覺也能被及時通知，迅速響應。
失效轉移
除了應用程序訪問失敗時進行失效轉移，監控系統還可以在發現故障的情況下主動 通知應用，進行失效轉移。
自動優雅降級
優雅降級是指網站為了應付突然爆發的訪問高峰，主動關閉部分功能，釋放部分系 統資源，保證網站核心功能正常訪問的一個手段。淘寶每年一次的“雙十一”促銷活動 主動關閉“評價”、“確認收貨”等非核心功能，以保證交易功能的正常進行，就可以看作 是一種優雅降級。
網站在監控管理基礎之上實現自動優雅降級，是網站柔性架構的理想狀態：監控系 統實時監控所有服務器的運行狀況，根據監控參數判斷應用訪問負載情況，如果發現部 分應用負載過高，而部分應用負載過低，就會適當卸載低負載應用部分服務器，重新安 裝啟動部分高負載應用，使應用負載總體均衡，如果所有應用負載都很高，而且負載壓 力還在繼續增加，就會自動關閉部分非重要功能，保證核心功能正常運行。
?
轉載于:https://www.cnblogs.com/xuwc/p/8372270.html
總結
以上是生活随笔為你收集整理的《大型网站技术架构：核心原理与案例分析》读书笔记-高可用的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ORA-16198: LGWR rece
- 下一篇： path.join 和 path.res