本文轉自：http://www.cnblogs.com/xrq730/p/4954152.html
前言
最近一直在拜讀兩本書：
1、李智慧老師的《大型網站技術架構 核心原理與案例分析》
2、曾憲傑老師的《大型網站系統與Java中間件實踐》
看了並結合自己目前的工作進行了思考，感覺獲益匪淺、受益良多，自己對大型網站的理解又有了不少的加深，下面分享一下自己的學習筆記。
學習筆記
1、大型網站架構的發展史（加粗就是每一步發展歷程的關鍵）
（1）從一個小網站發展起來，一臺服務器，應用程序、數據庫、文件等所有資源都在一臺服務器上
（2）網站業務的發展，一臺服務器逐漸不能滿足需求，因此要將應用和數據分離，應用和數據分離後使用三臺服務器：應用服務器、文件服務器和數據庫服務器
（3）網站進一步發展，數據庫壓力太大導致訪問延遲，因此使用緩存該改善網站性能（記住，使用緩存是改善網站性能的第一步），網站使用的緩存分爲兩種：緩存在應用服務器上的本地緩存和緩存在專門的分佈式緩存服務器上的遠程緩存
（4）使用緩存，數據庫訪問壓力得到有效緩解，但是在網站訪問高峯期應用服務器還是成爲了整個網站的瓶頸。這種時候要理解，不要企圖去更換更強大的服務器，對大型網站而言，不管多麼強大的服務器，都滿足不了網站持續增長的業務需求，因此可以通過增加服務器的方式改善負載壓力，再通過負載均衡調度服務器，將來自用戶瀏覽器的訪問請求分發到應用服務器集羣中的某臺服務器上
（5）雖然使用緩存可以使大部分數據不走數據庫，但是緩存沒有命中、緩存過期的數據還是會走數據庫，網站達到一定規模之後，數據庫讀寫壓力還是會很大，成爲網站的瓶頸。此時可以使用數據庫讀寫分離來改善數據庫負載壓力，應用服務器寫數據走寫庫，應用服務器讀數據走讀庫，目前大部分主流數據庫都提供主從熱備功能，通過配置兩臺數據庫主從關係，可以將一臺數據庫服務器的數據更新同步到另一臺服務器上
（6）隨着網站業務繼續發展，用戶規模不斷增大，由於中國複雜的網絡環境，不同地區用戶訪問網站時，速度差別也極大。因此可以使用反向代理和CDN，一方面加快用戶訪問速度，另一方面減輕後端服務器的負載壓力，因爲反向代理和CDN的基本原理都是緩存
（7）數據庫經過讀寫分離後，由一臺服務器拆分爲兩臺服務器，但還是不能滿足網站業務量的需求，因此可以使用分佈式數據庫，主要拆分手段是業務分庫，將不同的業務數據部署在不同的物理服務器上
（8）大型網站爲了應對日益複雜的業務場景，可以使用分而治之的手段將整個網站的業務拆分成不同的應用，每個應用獨立部署，可以通過超級鏈建立關係，也可以通過消息隊列進行數據分發
大型網站發展到這裏，基本上大多數的技術問題都得以解決
2、高性能網站的關鍵：控制住併發的量。只要能做到這點，很多棘手的數據問題也就不是什麼問題了
3、不要企圖通過技術解決所有問題，業務的問題也可以通過業務手段去解決
比如12306建立之初，0點售票，網站一下子要承受幾千萬的訪問量，直接導致12306這個網站崩潰，各路專業人士和分專業人士衆說紛紜、出謀劃策。但這僅僅通過技術能解決問題嗎？所以，針對這個需求，12306不僅要改善它的技術架構，也要調整它的業務架構，不要0點售票，在售票方式上引入排隊機制、整點售票改爲分時段售票，併發量控制住了，整個網站的性能就改善了
4、計算機軟件發展的 一個重要目標和驅動力是降低軟件的耦合性，事物之間關係越少，就越少彼此影響，越可以獨立發展
5、異步架構是典型的生產者消費者模式
6、使用異步隊列有幾個好處
（1）提高系統的可用性
（2）加快網站的訪問速度
（3）消除併發訪問高峯
7、網站伸縮性就是指通過不斷向集羣中加入服務器的手段來緩解不斷上升的用戶併發訪問壓力和不斷增長的數據存儲需求
8、衡量架構伸縮性的指標
（1）是否可用多臺服務器架構集羣
（2）是否容易向服務器中添加新的服務器
（3）加入的服務器是否可以提供和原服務器無差別的服務
（4）集羣中容納的總服務器是否有限制
9、反應系統忙閒的重要指標Load
System Load也稱爲Load，即系統負載，指當前正在被CPU執行和等待被CPU執行的線程數之和，，是反映系統忙閒程度的重要指標。多核CPU下，完美情況應該是所有CPU都在用，沒有線程等待處理。Load值低於CPU數目，表示CPU有空閒，資源存在浪費；Load值高於CPU數據，表示進程在等待CPU調度，資源存在浪費
10、瀏覽器訪問優化手段
（1）減少http請求，合併CSS、JS、圖片，不要發起多次http請求去拿這些數據
（2）使用瀏覽器緩存，存儲靜態資源，Cache-Control、Expires、Pragma、Last_Modified都是和緩存的HTTP HEADER
（3）啓用壓縮，有效減低通信傳輸的數據量
（4）CSS放在上面、JS放在下面，因爲JS下載會立即執行，可能阻塞頁面加載速度
（5）減少Cookie傳輸
11、緩存使用的幾點細節
（1）頻繁修改的數據不要寫緩存，一般讀寫比例至少2:1以上纔會做緩存，即一次寫入至少有兩次以上的讀取，像新浪微博這種，熱門微博，一次寫入可能會被讀取數百萬次，那是大大地合算
（2）如果訪問沒有熱點，大部分數據的訪問沒有集中在小部分數據上，那麼做緩存就沒有意義，因爲緩存有失效機制，大部分數據還沒有被再次訪問就被擠出緩存了
（3）容忍一定時間的數據不一致，除非數據更新時立刻通知緩存，不過這也會帶來開銷與事物一致性的問題
（4）使用分佈式緩存集羣以提高緩存可用性
（5）新啓動的緩存沒有任何數據，在重建緩存的過程中，系統性能與數據庫負載都不太好，因此要根據項目、根據業務，將一部分數據在啓動時就加載好，這就是緩存預熱
（6）對緩存做無效參數並設置失效時間，避免不恰當的業務或惡意攻擊頻繁調用接口查詢數據庫，一旦某一個Key值數據庫裏面查不到數據就進入無效緩存，一段時間內再次訪問這個Key值無數據返回
12、消息隊列具有很好的削峯作用（前面提過），不過注意需要適當修改業務流程進行配合
通過異步處理，將短時間高併發產生的事物消息存儲在消息隊列中，從而可以削平高峯期的併發事物。不過要注意點，由於數據寫入消息隊列後立即返回給用戶，數據在後續的業務校驗、寫數據庫等操作可能失敗，因此在使用消息隊列進行業務異步處理後，，需要適當修改業務流程進行配合，如訂單提交之後，訂單數據寫入消息隊列，不能立即返回給用戶訂單提交成功，需要在消息隊列的訂單消費者進程真正處理完該訂單的，甚至商品出庫後，再通過電子郵件或者SMS消息通知用戶訂單成功，避免交易糾紛
13、CDN和反向代理的基本原理都是緩存，區別在於CDN部署在網絡提供商的機房，使用戶在請求網站服務時，可以從距離自己最近的網絡提供商機房獲取數據；反向代理則部署在網站的中心機房，當用戶請求到達中心機房時，首先訪問的是反向代理服務器，如果反向代理服務器中緩存着用戶請求的資源，就將其直接返回給用戶。使用CDN和反向代理的目的是一樣的：
（1）儘早返回速度給用戶，加快用戶訪問網站的速度
（2）減輕後端服務器的負載壓力
14、應用服務器集羣的Session管理
單機環境下，Session可由部署在服務器上的Web容器管理，在使用負載均衡的集羣環境中，由於負載均衡服務器可能會將請求分發到集羣任何一臺應用服務器上，所以保證每次請求依然能夠獲得正確的Session比單機時要複雜得多。集羣環境下，Session管理有以下手段：
1、Session複製
在集羣中的幾臺服務器之間同步Session對象，使得每臺服務器上都保存着所有用戶的Session信息，這樣任何一臺機器宕機都不會導致Session數據的丟失，而服務器使用Session時，也只需要從本機獲取即可。
這種方案雖然簡單，從本機讀取Session信息也很快，但只能使用在集羣規模比較小的情況下。當集羣規模較大時，集羣服務器之間需要大量的通信進行Session複製，佔用服務器和網絡的大量資源，系統不堪負擔。而且由於所有用戶的Session在每臺服務器都有備份，在大量用戶訪問的情況下，甚至會出現服務器內存不夠Session使用的情況。
大型網站的核心應用集羣就是數千臺服務器，同時在線用戶達到數千萬，並不適用這種方案。
2、Session綁定
Session綁定可以利用負載均衡的原地址Hash算法，負載均衡服務器總是將來源於同一IP的請求分發到同一臺服務器。這樣在整個會話期間，用戶所有請求都在同一臺服務器上處理，即Session綁定在某臺特定服務器上，保證Session總能在這臺服務器上獲取，這種方法又被稱爲會話粘滯。
但是Session綁定的方案不符合對系統高可用的需求，因爲一旦某臺服務器宕機，那麼該機器上的Session也就不復存在了，用戶請求切換到其他機器後因爲沒有Session而無法完成業務處理。因此雖然大部分負載均衡服務器都提供原地址負載均衡算法，但很少有網站利用這個算法進行Session管理
3、利用Cookie記錄Session
早期的企業應用使用C/S架構，一種管理Session的方式是將Session記錄在客戶端，每次請求服務器的時候，將Session放在請求中發送給服務器，服務器處理完請求後再將修改過的Session響應給客戶端。網站沒有客戶端，但是可以利用瀏覽器支持的Cookie記錄Session。
利用Cookie記錄Session也有一些缺點：
（1）受到Cookie大小限制，能記錄的信息有限
（2）每次請求和響應都攜帶Cookie，影響性能
（3）如果用戶關閉Cookie，訪問就會不正常
不過因爲Cookie簡單易用且可用性高，支持應用服務器的線性伸縮，而大部分應用需要記錄的Session信息有比較小，因此事實上，許多網站或多 或少都會使用Cookie記錄Session
4、Session服務器
利用獨立部署的Session服務器（集羣）統一管理Session，應用服務器每次讀寫Session時，都訪問Session服務器。
這種解決方案事實上是將應用服務器的狀態分離，分爲無狀態的應用服務器和有狀態的Session服務器，然後針對這兩種服務器的不同特性分別設計其架構。
對於有狀態的Session服務器，一種比較簡單的方法是利用分佈式緩存、數據庫等，在這些產品的基礎上進行包裝，使其符合Session的存儲和訪問要求；如果業務場景對Session管理有比較高的要求，那麼就要利用Session服務集成單點登錄（SSO）、用戶服務等功能，則需要開發專門的Session服務管理平臺。
