粗略之見，不對的地方希望大神指教。
說實話工作當中我還真沒碰到過大訪問量的場景，當多就一個秒殺，搶購，發標搶標，訪問量也不大，就那麼幾千幾萬個人，同一時間幾萬個人去秒殺，也用不上負載均衡以及負載均衡後邊的叢集，用了就是高射炮打蚊子，我們也沒有在大廠工作的經驗，就這麼瞎胡亂的寫寫，也是自己百度摸索以及晚上業餘時間搞搞模擬案例，大體總結一下幾點
1.對於開發人員來說 儘量減少請求 因為你可以要知道 有請求就佔用網路頻寬 訪問多了 頻寬佔用的多 那麼網路訪問就會延遲卡頓 如何減少請求呢？總他們不能不讓使用者訪問吧？
a.合併css 啥意思呢？自己去看163網站 他們的css都是寫到html程式碼裡面的 因為你css弄個連線地址不也得去請求嗎 雖然是靜態的 訪問量多了也是佔用頻寬的啊
b.合併背景圖 能用css搞的樣式用css寫 別是不是就上背景圖片 另外可以合併背景圖片 有時候你會發現網上很多網站人家那一張背景圖是很多圖片合成的 也能減少對圖片的訪問 訪問就有頻寬
c.減少mysql查詢 不是不查詢 是儘量減少 能一條sql出來的就一條 當然也不是絕對的哈 一條sql鏈七八張表也不行 相對的 相對的去減少mysql的查詢 去掉不必要的mysql查詢 啥叫不必要的mysql查詢啊 一條sql能查兩個欄位出來 你非得弄兩條sql各自查一個欄位 那不沒事找事嗎？舉個例子而已 開發當中會有很多這種情況發生！
2.對於運維人員來說 開啟nginx的expires功能 設定快取時間 這個和304還不一樣 304雖然也是快取但是還是去請求了伺服器的 前邊的部落格當中我們講過
3.對於運維人員來說 開啟gzip 減小網路傳輸 不信自己去試試 開啟gzip 本身網頁50M 開啟之後也許就10M 網路傳輸體積小了 不也節省頻寬嗎？訪問量大了 不也能提升應用的訪問速度麼！
4.開啟cdn加速 cdn好處大大滴 自己去百度 並且百度cdn針對普通使用者是免費的 除非你流浪上來了 人家是要收你錢滴 天下沒有免費的午餐 這話一點不操蛋！
5.走到這我感覺 就是不可避免的一些請求了 你也就不用想著去減少請求量了 也是迫不得已的辦法
負載均衡+伺服器叢集來支撐 既然響應是不可避免的 我們要做的就是把工作內容平均分配到每臺伺服器上去 最理想的狀態 每臺伺服器的效能都能被充分利用 當然我說的叢集你可以是站點似的叢集也可以是memcache快取叢集或者redis叢集 看你自己的使用場景來定
題外話：叢集當中的伺服器也是有講究的 你得看你想用叢集裡面的伺服器幹啥？
比如mysql我們單獨部署到一套伺服器上 就是儲存嘛 那磁碟得牛逼啊 來塊ssd固態硬碟 跑的快
比如計算不復雜 就是程式多 比如跑16個20個php-fpm程式 那就記憶體大點 來它32G 64G記憶體
比如計算複雜的 演算法較多 那就cpu8核或者更高
更專業那都是專業運維的事了 我們也就不懂嘍！
本作品採用《CC 協議》，轉載必須註明作者和本文連結