高性能網站架構方案

高性能網站架構方案，本文談了七點網站架構方案，用以優化網站響應時間，實現大型網站技術架構方案。不管是電子商務或者其餘網站且可以使用。
1、優化網站響應時間的架構方案：
    網站能不能留的住用戶，一方面是看內容，另外一方面是看響應時間。一般有如下幾個方式來下降網站響應時間：
    一、減小HTTP請求。包括合併css和javascript。減小圖片數量，好比利用css的偏移技術來在一個圖片中選擇不一樣的位置內容。利用瀏覽器的Cache功能，咱們能夠在頭中聲明是否被瀏覽器緩存。
    二、動態內容靜態化。好比永久生成HTML文件。生成靜態文件並設定生存時間，到期後查詢新的動態內容進行替換。
    三、優化數據庫。數據庫的性能對於項目總體性能中是重中之重。設計良好的Mysql比亂糟糟的Mysql性能高出N個數量級，更別論再引入NOSQL了，好比Redis，MongoDB。
    四、使用負載均衡。將請求合理的分發到更多服務器。
    五、使用緩存。把花費時間和資源成本高昂的計算結果取出緩存起來，避免重複計算。好比在Mysql前面擋一層Memcached。好比生成一個文件，使用的時候include進來。再好比PHP中的OPCACHE等。

2、壓力測試的架構方案：
    吞吐率是指單位時間內處理的請求數，單位reqs/s。最大吞吐率是指單位時間內可以處理的最大請求出。模擬足夠多的人數和併發請求來測試最大吞吐率的方法叫作壓力測試。好比Apache自帶的ab（Apache Bench）。ab的參數不少，經常使用的有請求數（-n），併發用戶數（-c），超時時間（-t），長鏈接（-k），附件一個Cookie（-c name=value）

$ab -c 10 -n 1000 http://localhost/

3、長鏈接的架構方案： 每次請求都須要TCP的三次握手，握手完比表示鏈接正式聯通，以後再發送數據。那麼，把N個請求，就須要3N次握手，傳遞N次數據，獲得N次響應，總共5N。若是把N個請求合成一個請求，就是3次握手，1次傳遞數據，1次返回響應，共5次。可是，有時候咱們須要上一次響應的返回結果來發送新一輪的請求，在這個時候，合併請求並很差實現，這就須要長鏈接。使用起來很簡單，在頭中包含以下：

Connection: Keep-Alive

客戶端和服務器端均可以設置長鏈接的最大時間，當二者不統一時以小的一方爲準。開啓長鏈接後進行壓力測試：

$ab -c 10 -n 1000 http://localhost/

發現提高不止三五倍。本機是提高了8倍的性能。 4、提升Mysql的響應速度的架構方案： Handlerocker是日本的一位架構師開發。Mysql的一種插件。Handlerocker實現了繞過Mysql的SQL解析層。在Mysql5.1以上版本可使用，詳情能夠查看Mysql手冊。這裏就不在闡述。 5、Mysql主從複製的架構方案： 在分佈式部署中，1臺主庫，N臺從庫。主庫只寫，從庫只查。主庫從庫數據須要實現統一，這就是主從複製。優勢是： 一、從庫備份時，主庫能夠繼續處理更新。 二、優化響應時間。 三、增長健壯性。主庫掛了能夠切換到從庫做爲備份。主從複製的實現過程有三步，1個在主庫，2個在從庫： 一、主庫服務器將用戶對數據庫更新的操做以二進制格式保存到Binary Log日誌文件。而後Binlog Dump線程將Binary Log日誌文件傳輸給從庫服務器。  二、從庫服務器經過一個I/O線程將主庫服務器的Binary Log日誌文件中的更新操做複製到一個叫作Relay Log中的中繼日誌文件中。 三、從庫服務器經過另外一個SQL線程Relay Log中繼日誌文件中的操做依次在本地執行，從而實現主從數據庫之間數據的同步。 本篇只是簡單的列出方案，詳細的配置和實現步驟將在另外一篇中寫到。 6、代理的架構方案： 讀取內存的速度是讀取硬盤的100000-1000000倍。把訪問過的頁面緩存在內存中，下次直接從內存中讀取，能夠有效加速。 一、傳統代理。客戶端發送請求給代理服務器，代理服務器向WEB服務器取到數據並返回給瀏覽器。代理服務器就是一個有大的存儲空間的Cache。 二、反向代理。和傳統代理原理相似，只是使用對象不一樣。傳統代理的使用對象是客戶端，反向代理的使用對象是服務器。用戶經過反向代理訪問Web服務器，Web服務器是隱藏起來的。不過用戶不關心這些，權把代理服務器看成真實的Web服務器。反向代理有Vamish。 7、異步計算的架構方案： 比較耗時的好比將用戶上傳的文件分發到多臺機器，好比裁剪圖片，視頻轉碼等。可使用異步方案。讓用戶無須等待計算結束而是先行返回結果。表明產品有和Memcache同一家的Gearman。關於Gearman的使用能夠查看PHP手冊。