掌握性能優化的相關知(zhī)識，特備對于大(dà)型網站大(dà)流量的應用至關重要，今天主要分(fēn)享大(dà)型網站性能優化内容

應用服務器性能優化

應用服務器就是處理網站業務的服務器，網站的業務代碼都部署在這裏，是網站開(kāi)發最複雜(zá)，變化最多的地方，優化手段主要有緩存、集群和異步等。

網站性能優化第一(yī)定律：優先考慮使用緩存優化性能。

緩存的本質是一(yī)個内存Hash表，網站應用中(zhōng)，數據緩存以一(yī)對Key,Value的形式存儲在内存Hash表中(zhōng)。緩存主要用來存放(fàng)那些讀寫比很高、很少變化的數據。

二八定律：80%的訪問落在20%的數據上

使用緩存需要注意的問題：

把頻(pín)繁修改的數據放(fàng)入緩存。容易出現數據寫入緩存後，應用還來不及讀取緩存，數據就已經失效的情形，徒增系統負擔。一(yī)般來說，數據的讀寫比在2:1以上，緩存才有意義。

沒有熱點的訪問。 緩存使用的内存資(zī)源非常寶貴，隻能将最新訪問的數據緩存起來，而把曆史數據清理出緩存。即緩存資(zī)源應該留給20%的熱點數據。

數據不一(yī)緻與髒讀。 一(yī)般會對緩存設置失效時間，超過失效時間，就要從數據庫重新加載。因此應用要忍受一(yī)定時間的數據不一(yī)緻。另一(yī)種策略是數據更新時立即更新緩存，不過這也會帶來更多的系統開(kāi)銷和事務一(yī)緻性的問題。

緩存可用性。 業務發展到一(yī)定階段時，緩存會承擔大(dà)部分(fēn)數據訪問的壓力，數據庫已經習慣了有緩存的日子，所以當緩存服務器崩潰時，數據庫會因爲完全不能承受如此大(dà)的壓力而宕機，進而導緻整個網站不可用。這種情況被稱作緩存雪崩，發生(shēng)這種故障，甚至不能簡單地重啓緩存服務器和數據庫服務器來恢複網站訪問。解決方式：1、緩存熱備（當某台服務器宕機時，将緩存訪問切換到熱備服務器上。）；2、緩存服務器集群。

緩存預熱。 緩存中(zhōng)存放(fàng)的是熱點數據，熱點數據是緩存系統用LRU對不斷訪問的數據篩選出來的，這個過程需要較長的時間。新啓動的緩存系統沒有任何數據，此時系統的性能和數據庫負載都不太好。因此可以選擇在啓動緩存是就把熱點數據預加載好。

緩存穿透。 因爲不恰當的業務或惡意攻擊，持續高并發地訪問某一(yī)個不存在的數據，如果緩存不保存該數據，就會有大(dà)量的請求壓力落在數據庫上。簡單的解決方式是把請求的不存在的數據也放(fàng)進緩存，其value是null。

對應可以考慮的分(fēn)布式緩存有memcached、redis，降低對數據庫的讀操作。

數據庫SQL性能優化

最後就是考慮數據庫端的性能優化，如果訪問量巨大(dà)，除了sql優化外(wài)，還會涉及到分(fēn)庫分(fēn)表、讀寫分(fēn)離(lí)、利用數據庫中(zhōng)間件來解決(下(xià)面架構師系列有講)，這裏就不再重複。

1.對查詢進行優化，要盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。

2.應盡量避免在 where 子句中(zhōng)對字段進行 null 值判斷，否則将導緻引擎放(fàng)棄使用索引而進行全表掃描，如：

select id from t where num is null
3.應盡量避免在 where 子句中(zhōng)使用 != 或 <> 操作符，否則将引擎放(fàng)棄使用索引而進行全表掃描。

4.應盡量避免在 where 子句中(zhōng)使用 or 來連接條件，如果一(yī)個字段有索引，一(yī)個字段沒有索引，将導緻引擎放(fàng)棄使用索引而進行全表掃描。

5.in和 not in 也要慎用，否則會導緻全表掃描，如：

select id from t where num in(1,2,3)
對于連續的數值，能用 between就不要用 in 了：

select id from t where num between 1 and 3
6.對于多張大(dà)數據量（這裏幾百條就算大(dà)了）的表JOIN，要先分(fēn)頁再JOIN，否則邏輯讀會很高。

7.索引并不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因爲 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體(tǐ)情況而定。一(yī)個表的索引數最好不要超過6個，若太多則應考慮一(yī)些不常使用到的列上建的索引是否有 必要。

8.盡量使用數字型字段，若隻含數值信息的字段盡量不要設計爲字符型，這會降低查詢和連接的性能，并會增加存儲開(kāi)銷。這是因爲引擎在處理查詢和連 接時會逐個比較字符串中(zhōng)每一(yī)個字符，而對于數字型而言隻需要比較一(yī)次就夠了。

9.盡量避免向客戶端返回大(dà)數據量，若數據量過大(dà)，應該考慮相應需求是否合理。

10.盡量避免大(dà)事務操作，提高系統并發能力。

Web前端性能優化

Web前端指網站業務邏輯需要優化，包括：

1.浏覽器加載

2.網站視圖模型

3.圖片服務

4.CDN服務等

主要優化手段有優化浏覽器訪問，使用反向代理，CDN等。

1.浏覽器訪問優化

(1)減少http請求

HTTP協議是無狀态的應用層協議，意味着每次HTTP請求都需要簡曆通信鏈路，進行數據傳輸，而在服務器端，每個HTTP都需要啓動獨立的線程去(qù)處理，這些通信和服務的開(kāi)銷都很昂貴，減少HTTP請求的數目可有效提高訪問性能。

減少HTTP請求的主要手段是:

合并CSS，以及壓縮CSS大(dà)小(xiǎo)

合并JavaScript，以及壓縮JS大(dà)小(xiǎo)

合并圖片

将浏覽器一(yī)次訪問需要的JavaScript,CSS合并成一(yī)個文件，這樣浏覽器就隻需要一(yī)次請求。多張圖片合并成一(yī)張，如果每張圖片都有不同的超鏈接，可通過CSS偏移響應鼠标點擊操作，構造不同的URL。

(2)使用浏覽器緩存

對一(yī)個網站而言，CSS,JavaScript,Logo,圖标等這些靜态資(zī)源文件更新的頻(pín)率都比較低，而這些文件又(yòu)幾乎是每次HTTP請求都需要的，如果将這些文件緩存在浏覽器中(zhōng)，可以極好地改善性能。通過設置HTTP頭中(zhōng)Cache-Control和Expires屬性，可設定浏覽器緩存，緩存時間可以是數天甚至是幾個月。有時候，靜态資(zī)源文件變化需要及時應用到客戶端浏覽器，這種情況可以通過改變文件名實現，比如一(yī)般會在JavaScript後面加上一(yī)個版本号，使浏覽器刷新修改的文件。

(3)啓用壓縮

在服務器端對文件進行壓縮，在浏覽器端對文件解壓縮，可有效較少通信傳輸的數據量。文本文件的壓縮效率科大(dà)80%以上。

(4)CSS放(fàng)在頁面最上面，JavaScript放(fàng)在頁面最下(xià)面

浏覽器會在下(xià)載完全部CSS之後對整個頁面進行渲染，因此最好的做法是将CSS放(fàng)在頁面最上面，讓浏覽器盡快下(xià)載CSS。JS則想法，浏覽器在加載JS後立即執行，有可能會阻塞整個頁面，造成頁面顯示緩慢(màn)，因此JS最好放(fàng)在頁面最下(xià)面。

(5)減少Cookie傳輸

一(yī)方面，Cookie包含在每次請求和響應中(zhōng)，太大(dà)的Cookie會嚴重影響數據傳輸，因此哪些數據需要寫入Cookie需要慎重考慮，盡量減少Cookie中(zhōng)傳輸的數據量。另一(yī)方面，對于某些靜态資(zī)源的訪問，如CSS,JS等，發送Cookie沒有意義，可以考慮靜态資(zī)源使用獨立域名訪問，避免請求靜态資(zī)源時發送Cookie，減少Cookie傳輸的次數。

2.CDN加速

CDN(Content Distribute Network,内存分(fēn)發網絡)的本質上仍然是一(yī)個緩存，而且将數據緩存在離(lí)用戶最近的地方，是用戶以最快速度獲取數據，即所謂網絡訪問第一(yī)跳。

CDN一(yī)般緩存的是靜态資(zī)源，如圖片，文件，CSS，Script腳本，靜态網頁等，但是這些文件訪問頻(pín)率很高，将其緩存在CDN可極大(dà)改善網頁的打開(kāi)速度。

3.反向代理

傳統代理服務器位于浏覽器一(yī)側，代理浏覽器将HTTP請求發送到互聯網上，而反向代理服務器位于網站機房一(yī)側，代理網站Web服務器接收HTTP請求。和傳統代理服務器可以保護浏覽器安全一(yī)樣，反向代理服務器也具有保護網站安全的作用，來自互聯網的訪問請求必須經過代理服務器，相當于在Web服務器和可能的網絡攻擊之間建立了一(yī)個屏障。

除了安全功能，代理服務器也可以通過配置緩存功能加速Web請求，當用戶第一(yī)次訪問靜态内容的時候，靜态内容就被緩存在反向代理服務器上，這樣當其他用戶訪問該靜态内容的時候，就可以直接從反向代理服務器返回，加速Web請求響應速度，減輕服務器負載要。