大型網站中通常把系統分爲三層：1.應用層，2.服務層，3.數據層。
位於應用層的服務器在面對高併發訪問請求，通常用負載均衡進行解決。例如：將一組服務器組成集羣對外提供服務。負載均衡設備通過心跳檢測手段發現某臺服務器不可用時就將其剔除服務器列表，並將請求分發到急羣衆其他可用的服務器上。而處於服務層的服務器與應用層類似。
位於數據層的服務器則比較特殊，因爲數據就存儲在上面，爲了保證服務器宕機時數據不丟失、訪問不中斷，所以會在數據寫入操作的時候進行數據同步複製，寫入到多臺服務器上，實現數據冗餘備份。當數據服務器宕機，應用程序將訪問切換到其他備用數據服務器上，保持整體服務的可用性。
對於以上三層的講述中都是用意外發生時的應對方式，但有時候整個系統宕機時必然的，例如：網站系統升級，需要關閉服務器並重新部署系統，整個過程相當於服務器宕機。這種主動的服務器宕機，在現在的應對方式是採用灰度發佈的手段，以免出現大規模的問題或災難。
通過負載均衡進行無狀態服務的失效轉移。
應用層具有無狀態性，在用戶的每次請求中不包括業務上下文，多個服務器實例完全對等。無論請求打到哪個服務器處理的結果都是一樣的。不保存狀態給系統高可用帶來巨大便利，因爲多個服務器實例對等，當一臺服務器宕機後請求可以發給其他服務器進行處理，對於終端用戶而言請求總是能成功的。實現服務器狀態實時監測、失效轉移的方式爲負載均衡。
負載均衡只在業務量和數量較高時，單臺服務器不足以承擔所有壓力，可以通過負載均衡將流量和數據分攤到一個集羣組成的多臺服務器上，提高整體負載處理能力。
服務器session管理
網站無狀態性是一種高可用的理想狀態，通常業務總是有狀態的，這時就會使用服務器端保存session會話：即多次請求修改使用的上下文對象。單機處理session時可以將session部署到web容器中進行管理。但是在分佈式集羣中，負載均衡服務器可能將請求分發到任何一臺可用服務器上，如果想保證獲得正確的session會話要比單機情況下困難的多。大致可以有如下集中處理方式進行session管理。
1.session複製
一種早起企業應用系統使用較多的服務器集羣session管理機制。應用服務器開啓web容器的session複製功能，session在各個服務器間同步session對象，每臺服務器都保有所有用戶session信息。優點時在服務器發生宕機時不會導致session數據丟失，而服務器使用session只要在本機獲得。雖然方法簡單、獲取速度也很快，但是不能用在集羣數量較多的情況下：服務器數量很多的時候，集羣服務器之間的session複製要浪費大量的通信，佔用服務器和網絡的大量資源，系統負擔大，並且在訪問量很大時，每臺服務器保存大量的session信息，可能會出現內存不夠session使用的情況。大型網站並不適用。
2.session綁定
此方法可以通過利用負載均衡的源地址Hash算法實現，負載均衡服務器總是將屬於同一ip的請求分發到同一臺服務器，這是負載均衡服務器必須在http協議層上工作，這樣可以將同一ip打到固定的服務器，保證服務器獲取，這種方法也被稱作會話黏滯。
但是這種方案顯然不符合高可用的特性，一旦一臺服務器宕機，那麼該機器的session信息就會丟失。
3.利用cookie記錄session
早期企業通常使用的一種方法，將會話session記錄在客戶端，每次請求將session放在請求中發送給服務器，服務器處理完請求後將修改後的session響應給客戶端。
這種方式的缺點：session大小收到cookie大小的限制，能記錄的信息有限；每次請求響應都需要傳輸cookie，影響性能；當用戶關閉cookie，訪問會錯誤。但是cookie簡單易用、可用性高、支持服務器線性伸縮，大部分應用的session信息又比較小，實際上許多網站或多或少的使用cookie進行session會話記錄。
4.session服務器
通過session服務器可以做到：可用性高、伸縮性好、性能較優、信息大小沒有限制等有點。利用獨立部署session服務器（集羣）統一管理session，應用每次讀寫session都訪問session服務器，可以理解爲共享一個服務器---session服務器。這種將服務器的狀態分離的方式，分爲無狀態應用服務器和有狀態的session服務器，對這兩種服務器的不同特性需要分別設計架構。
在有狀態的session服務器實現方式中：比較簡單的方式是利用分佈式緩存、數據庫等，在這些產品的基礎上進行包裝，使其符合session的存儲和訪問要求。如果業務場景對session管理要求較高，比如利用session服務器集成單點登錄（sso）、用戶服務等功能，則需要開發專門的session服務平臺。
高可用的服務
可以複用的服務模塊爲業務產品提供基礎公共服務，大型網站的複用服務通常獨立分佈式部署，被具體應用遠程調用。可複用的服務通常也是一種無狀態服務，因此可以使用負載均衡的失效轉移策略實現高可用的服務。具體實踐還有幾種高可用的服務策略。
1.服務分級管理。
運維上將服務器進行分級管理，核心應用和服務優先使用更好的硬件，響應速度也格紋迅速。例如：用戶即使付款比能不能評價商品更重要，所以在整個系統中服務也是分層的。
在服務部署上也進行必要的隔離，避免故障的連鎖反應。低優先級服務通過啓動不同的線程或者不同的虛擬機進行隔離，而高優先級的服務器則需要部署在不同的物理機上，核心服務和數據甚至需要部署在不同的低於的數據中心。也就是說越高級的服務考慮的事情也就越多，甚至要考慮很多不可抗力發生後依然不正系統的高可用（海嘯、地震之類）。
2.超時設置。
因爲有時會發生服務器宕機、現成死鎖等原因，導致應用對服務端的調用失去響應，導致用戶訪問長時間無響應，同時還佔用資源，不利於訪問請求及時轉移到正常服務器上。這是會設置服務調用的超時時間，一旦超時，通信框架會拋出異常，應用程序根據服務調度策略，可以選擇繼續重試或將請求轉移到提供相同服務的其他服務器上。
3.異步調用
有些應用對服務的調用通過消息隊列等異步方式完成，避免一個服務失敗導致整個應用請求事變的情況。例如用戶註冊操作需要調用三個服務，將用戶信息寫入數據庫、發送註冊成功系統郵件、給用戶開通對應權限。如果採用同步服務調用，郵件系統發生錯誤而無法開通對應權限，最終導致用戶註冊失敗。但是採用異步的調用方式，應用程序將用戶註冊信息發送到消息隊列後立即返回給用戶註冊成功的信息，而用戶信息寫入數據庫、發送郵件、開通權限之間並不會因爲郵件系統的錯誤而導致註冊失敗，只是用戶收到註冊郵件的時間稍晚一點。
但不是所有的服務都適用於異步調用的方式，對於獲取用戶信息等調用，若果採用異步方式調用會延長響應時間、得不償失。對於那些必須確認服務調用成功才能進行下一步操作的服務也不可以使用異步的方式。只有服務之間沒有先後關係、生產者消費者關係時才適合用異步調用的方式。
4.服務降級（保證核心功能的正常使用，在峯值時需要對服務進行降級）
當服務訪問處於峯值時，可能因爲大量的併發調用而性能下降，嚴重時服務器可能宕機。爲了保證核心應用和功能的正常運行，需要對服務進行降級。降級有兩種手段：拒絕服務和關閉服務。
拒絕服務：1.拒絕低優先級服務的調用，減少調用併發數，確保核心應用的正常使用；2.隨機拒絕部分請求，解決資源讓另一部分清酒得以成功，避免要死大家一起上的情況。對於隨機拒絕服務：有些用戶不可使用但是周圍的人可以使用，自己重新請求就可以使用，這種用戶體驗會好一些，讓用戶產生可能時網絡不好導致的錯覺。
關閉服務：關閉部分不重要的服務，或者服務內關閉部分不重要的功能，從而節約系統開銷，爲重要的服務讓出資源。
5.冪等性設計
應用調用服務失敗，系統會調用請求重新發送到其他服務器，但是這個失敗可能是一個虛假的失敗，比如疑問網絡延遲等原因，導致服務已經處理成功、但是系統沒有收到響應，這是應用重新提交請求就會導致服務的重複調用。
服務的重複調用是無法避免的，應用層也不必考慮服務是否真的失敗，只要沒有得到響應，就可以認定爲訪問失敗，並重試調用服務。因此在服務層就要確保服務：在一次調用和重複調用的結果相同，即服務具有冪等性。
有些服務具有天然的冪等性，比如用戶性別的更改，不論設置多少次，男性依然爲男性，年齡也可以做類似的設想，但是如果時轉賬的操作，那麼問題就會複雜，需要通過交易編號等信息進行服務調用有效期校驗，只有有效的操作才能繼續執行。
大量內容來自於李智慧老師的《大型網站技術架構》，侵權請聯繫我刪除。如果有不對的對方也歡迎大家之初，感謝大家。