大型網站核心架構要素 之二(細解網站的高性能架構)

1、不一樣視角下的網站高性能指標，以及其優化

一、開發人員的視角

開發人員關注的主要是應用程序自己及其相關子系統的性能，包括響應延遲、系統吞吐量、併發處理能力、系統穩定性等技術指標。優化網站性能的主要手段包括 使用緩存加速數據讀取，使用集羣提升吞吐能力，使用異步消息加快請求響應及實現削峯，使用代碼優化手段改善網站性能。

二、運維人員視角

運維人員更關注基礎設施性能和資源利用率，如網絡運營商的寬帶能力、服務器硬件的配置、數據中心網絡架構、服務器和網絡帶寬的資源利用率等。主要優化手段有建設優化骨幹網、使用高性價比定製服務器、利用虛擬化技術優化資源利用等

2、性能測試指標

一、響應時間 

 打開一個網站  幾秒

在數據庫中查詢一條記錄(有索引)  十幾毫秒

機械磁盤一次尋址定位  4毫秒

從機械磁盤順序讀取1MB數據 2毫秒

從SSD磁盤順序讀取1MB數據  0.3毫秒

從遠程分佈式緩存Redis讀取一個數據  0.5毫秒

從內存中讀取1MB數據 十幾微秒

JAVA程序本地方法調用 幾微秒

網絡傳輸2KB數據 1微秒

二、併發數

名詞解釋，指的是系統可以同時處理請求的數目，這個數字也反映了系統的負載特性。對於網站而言，併發數即網站併發用戶數，指同時提交請求的用戶數目。

網站系統用戶數》》網站在線用戶數》》網站併發數

三、吞吐量

指單位時間內系統處理的請求數量，體現系統的總體處理能力。對於網站，能夠用 「請求數/秒」 或者是「頁面數/秒」來衡量，也能夠用 「訪問人數/天」 。TPS （每秒事務數）是吞吐量的一個經常使用量化指標，此外還有HPS（每秒HTTP請求數）、QPS（每秒查詢數）

四、性能計數器

它是描述服務器或操做系統性能的一些數據指標。包括System Load、對象與線程數、內存使用、CPU使用、磁盤與網絡IO等指標。這些指標也是系統監控的重要參數，對這些值設置報警閥值，當監控系統發現性能計數器超過閥值時，就向運維和開發人員報警

3、性能優化

一、前端性能優化

a、減小HTTP請求數目，圖片合併，JS合併，CSS合併 aJax合併

b、使用瀏覽器緩存 主要是緩存一些靜態資源 CSS JS Logo 圖標 等 能夠經過設置HTTP中Cache-Control和Expires的屬性，可設定瀏覽器緩存，幾天 甚至幾個月

在某些時候，靜態文件資源變化須要及時應用到客戶端瀏覽器，這種狀況能夠經過改變文件名實現。

c、啓用壓縮

一些文本文件壓縮率高達 80% 啓用壓縮能夠有效減小HTTP傳輸的數據量，不只下降帶寬還減小傳輸時間。（反作用是 壓縮對服務器的CPU形成壓力）

d、Css放在頁面最上面、JS 放在頁面最下面

瀏覽器會在下載完全部CSS後對頁面進行渲染，而JS正好相反，瀏覽器在加載JS的同時 會當即執行JS，有可能會堵塞整個頁面，形成頁面顯示緩慢所以JS 最好放最下面，CSS放頁面上面

e、減小cookie傳輸

一方面，Cookie包含在每次請求和響應中，太大的Cookie會嚴重影響數據傳輸。另外一方面 對於某些靜態資源的訪問 如CSS,SCRIPT等，發送Cookie沒有意義，能夠考慮靜態資源使用獨立域名訪問，避免請求靜態資源時發送Cookie

二、CDN加速

CDN 的本質仍然是一個緩存，並且將數據緩存在離用戶最近的地方，使用戶以最快速度得到數據，即所謂網絡訪問第一跳

因爲CDN不熟在網絡運營商的機房，這些運營商有事終端網絡的服網絡服務提供商，所以用戶請求路由的第一跳就到達了CDN服務器，當CDN中存在瀏覽器請求的資源時，直接從CDN返回給瀏覽器，最短路徑返回響應，加快用戶訪問速度，減小數據中心負載壓力。這個技能能夠極大的改善網頁打開速度

三、反向代理

傳統代理服務器位於瀏覽器的一側，代理瀏覽器將HTTP請求發送到互聯網上，而反向代理服務器位於網站機房一側，代理網站Web服務器接收HTTP請求，而後將請求轉發給後端的WEB服務器，至關於一個網絡安全屏障。此外，還能夠將熱點緩存內容保存於Web服務器上，減輕後端壓力。同時，反向代理還能夠實現負載均衡，改善整個網站高併發能力

4、應用服務器性能優化

一、分佈式緩存

網站性能優化第必定律：優先考慮使用緩存優化性能

緩存的基本原理，緩存是指將數據存儲在相對較高訪問速度的存儲介質中，以供系統處理。一方面緩存訪問速度快，能夠減小數據訪問的時間，另外一方面若是緩存的數據是通過計算處理獲得的，那麼被緩存的數據無需重複計算便可直接使用。

緩存的本質是一個內存Hash表，在網站應用中，數據緩存以一對Key,Value的形式存儲在內存Hash表中，Hash表數據讀寫的時間複雜度爲O(1)。

緩存主要用來存放那些讀寫比很高、不多變化的數據，如商品的類目信息，熱門詞的搜索列表信息，熱門商品信息等。

二、合理使用緩存

不合理使用緩存非但不能提升系統的性能還會成爲系統的累贅，甚至風險。實踐中緩存濫用的情景家常便飯，這樣很差哦

a、頻繁修改的數據，若是緩存中保存的數據,就會在數據寫入緩存後，應用還來不及讀取緩存，數據就已經失效的情形，徒增系統負擔。通常來講，數據的讀寫比在2:1以上，即寫入一次緩存，在數據更新前至少讀取兩次，緩存纔有意義。

b、沒有熱點的訪問，緩存使用內存做爲存儲，內存資源寶貴而有限，不可能將全部數據都緩存起來，只能將最新訪問的數據緩存起來，而將歷史數據清理出緩存。若是應用系統訪問數據沒有熱點，不遵循二八定律，即大部分數據訪問並無集中在小部分數據上，那麼緩存就沒有意義，由於大部分數據尚未被再次訪問就已經被擠出緩存了

c、數據不一致與髒讀，通常會對緩存數據設置失效時間，一旦超過失效時間，就要從數據庫中從新加載，所以應用要容忍必定時間的數據不一致，如賣家已經編輯了商品屬性，可是須要過一段時間才能被買家看到

d、緩存可用性，緩存是爲提升數據讀取性能的，緩存數據丟失或者緩存不可用不會影響到應用程序的處理--它能夠從數據庫直接獲取數據。可是當緩存沒法正常工做時，全部壓力都要集中到數據庫中，若是數據庫沒法承受突如其來的壓力，整個系統就崩了。經過 主從緩存，一臺崩了，另外一臺啓動，能夠解決問題。可是這種設計有違緩存的初衷，緩存不該該被當作一個可靠的數據源來使用，經過分佈式緩存，將數據分散在多臺服務器中，即便一臺緩存服務器崩了，也只是缺失了部分數據，重啓後，再從數據庫恢復便可

e、緩存預熱，緩存中存放的是熱點數據，熱點數據又是緩存系統利用LRU（最近醉酒未用算法） 對不斷訪問的數據篩選淘汰出來，

f、緩存穿透，若是由於不恰當的業務、或者惡意攻擊持續高併發地請求某個不存在的數據，因爲緩存沒有保存該數據，全部請求都會落到數據庫上，會對數據庫形成很大壓力，甚至崩潰。一個簡單的策略是將不存在的數據也緩存起來，設置爲null

g、分佈式緩存架構，分佈式緩存不熟在多個服務器組成的急羣衆，以集羣方式提供緩存服務，其架構方式有兩種，一種是以Memcache爲表明的不互相通訊的分佈式緩存，經過必定的hash算法，來分配某個緩存應該存放的地點，服務器之間不進行通訊，這樣的緩存集羣能夠很容易實現擴容。

h、多利用異步操做。使用消息隊裏將調用異步化，可改善網站的擴展性。好比記日誌，作一些計算等操做，放後臺作，先將數據返回給用戶，這個仍是要看業務需求，有必定限制，不是什麼業務均可以這麼作的

i、使用集羣，memcache redis

j、代碼優化，資源複用，線程池（redis/mysql鏈接池）

k、存儲性能優化，即：硬件性能提高，不少，好比 硬盤，機械硬盤->固態硬盤 有些服務器須要更好的CPU

總結：網站性能優化技術是在網站性能遇到問題的解決方案。而網站性能問題不少事在用戶高併發訪問時產生的，因此網站性能優化的主要工做時改善高併發用戶訪問狀況下的網站響應速度。