高并發(fā)解決方案 超詳細?。?！

高并發(fā)解決方案


1. 高并發(fā)和大流量解決方案

高并發(fā)解決方案案例

　　流量優(yōu)化：防盜鏈處理

　　前端優(yōu)化：減少HTTP請求，合并css或js，添加異步請求，啟用瀏覽器緩存和文件壓縮，CDN加速，建立獨立圖片服務器，

　　服務端優(yōu)化：頁面靜態(tài)化，并發(fā)處理，隊列處理

　　數據庫優(yōu)化：數據庫緩存，分庫分表，分區(qū)操作，讀寫分離，負載均衡

　　web服務器優(yōu)化：負載均衡，nginx反向代理，7,4層LVS軟件

2.?web資源防盜鏈

????????盜鏈：在自己的頁面上展示一些并不在自己服務器上的內容，獲得他人服務器上的資源地址，繞過別人的資源展示頁面，直接在自己的頁面上向最終用戶提供此內容，常見的是小站盜用大站的圖片，音樂，視頻，軟件等資源，通過盜鏈的方法可以減輕自己服務器的負擔，因為真實的空間和流量均是來自別人的服務器

　　防盜鏈：防止別人通過一些技術手段繞過本站的資源展示頁面，盜用本站的資源，讓繞開本站資源展示頁面的資源鏈接失效，可以大大減輕服務器及帶寬的壓力

　　工作原理：通過請求頭中的referer或者簽名，網站可以檢測目標網頁訪問的來源網頁，如果是資源文件，則可以跟蹤到顯示它的網頁地址，一旦檢測到來源不是本站即進行阻止或者返回制定的頁面，通過計算簽名的方式，判斷請求是否合法，如果合法則顯示，否則返回錯誤信息

實現方法：referer：nginx模塊ngx_http_referer_module用于阻擋來源非法的域名請求，nginx指令valid_referers none | blocked | server_names | string...，none表示referer來源頭部為空的情況，blocked表示referer來源頭部不為空，但是里面的值被代理或者防火墻刪除了，這些值都不以http://或者https://開頭，server_names表示referer來源頭部包含當前的server_names，全局變量$invalid_referer。不能徹底防范，只能提高門檻。也可以針對目錄進行防盜鏈。

//在nginx的conf中配置

location ~.*\.(gif|jpg|png|flv|swf|rar|zip)$

{

? ? valid_referers none blocked zi.com *.zi.com;

? ? if($invalid_referer)

? ? {

? ? ? ? #return 403;rewrite ^/ http://www.zi.com/403.jpg;? ? }? ?

}

傳統(tǒng)防盜鏈遇到的問題：偽造referer：可以使用加密簽名解決

　　加密簽名：使用第三方模塊HttpAccessKeyModule實現Nginx防盜鏈。accesskey?on|off?模塊開關，accesskey_hashmethod?md5|sha-1?簽名加密方式，accesskey_arg GET參數名稱，accesskey_signature?加密規(guī)則，在nginx的conf中設置

location ~.*\.(gif|jpg|png|flv|swf|rar|zip)$

{

? ? accesskey on;

? ? accesskey_hashmethod md5;

? ? accesskey_arg sign;

? ? accesskey_signature "jason$remote_addr";

}';

3.?減少HTTP請求次數

性能黃金法則：只有10%-20%的最終用戶響應時間花在接收請求的HTML文檔上，剩下的80%-90%時間花在HTML文檔所引用的所有組件(img，script，css，flash等)進行的HTTP請求上。

　　如何改善：改善響應時間的最簡單途徑就是減少組件的數量，并由此減少HTTP請求的數量

　　HTTP連接產生的開銷：域名解析--TCP連接--發(fā)送請求--等待--下載資源--解析時間

　　疑問：DNS緩存，查找DNS緩存也需要時間，多個緩存就要查找多次有可能緩存會被清除；Keep-Alive，HTTP1.1協(xié)議規(guī)定請求只能串行發(fā)送，前面的一個請求完成才能開始下個請求

減少HTTP請求的方式：

? ???????圖片地圖：允許在一個圖片上關聯多個URL，目標URL的選擇取決于用戶單擊了圖片上的哪個位置，以位置信息定位超鏈接，把HTTP請求減少為一個，可以保證設計的完整性和功能的齊全性，使用map和area標簽；

<img usemap="#map" src="/map.gif?t=111">

<map name="map">

<area shape="rect" coords="0,0,30,30" href=... title=""> ...?

?</map>

???????CSS Sprites：CSS精靈，通過使用合并圖片，通過指定css的background-image和background-position來顯示元素。圖片地圖與css精靈的響應時間基本上相同，但比使用各自獨立圖片的方式要快50%以上

　　合并腳本和樣式表：使用外部的js和css文件引用的方式，因為這要比直接寫在頁面中性能要更好一點；獨立的一個js比用多個js文件組成的頁面載入要快38%；把多個腳本合并為一個腳本，把多個樣式表合并為一個樣式表

　　圖片使用base64編碼減少頁面請求數：采用base64的編碼方式將圖片直接嵌入到網頁中，而不是從外部載入

4.?瀏覽器緩存和數據壓縮優(yōu)化? ----

HTTP緩存機制：如果請求成功會有三種情況：200?from?cache：直接從本地緩存中獲取相應，最快速，最省流量，因為根本沒有向服務器進行請求；304?not?modified：協(xié)商緩存，瀏覽器在本地沒有命中的情況下請求頭中發(fā)送一定的校驗數據到服務端，如果服務端數據沒有改變?yōu)g覽器從本地緩存響應，返回304，快速，發(fā)送的數據很少，只返回一些基本的響應頭信息，數據量很小，不發(fā)送實際響應體；200 OK：以上兩種緩存全部失敗，服務器返回完整響應，沒有用到緩存，相對最慢。

　　瀏覽器認為本地緩存可以使用，不會去請求服務端。相關header：pragma：HTTP1.0時代的遺留產物，該字段被設置為no-cache時，會告知瀏覽器禁用本地緩存，即每次都向服務器發(fā)送請求；expires：HTTP1.0時代用來啟用本地緩存的字段，瀏覽器與服務器的時間無法保持一致，如果時間差距大，就會影響緩存結果；cache-control：HTTP1.1針對expires時間不一致的解決方案，告知瀏覽器緩存過期的時間間隔而不是時刻，即使具體時間不一致，也不影響緩存的管理；可以設置的值：no-store：禁止瀏覽器緩存響應；no-cache：不允許直接使用本地緩存，先發(fā)起請求和服務器協(xié)商；max-age=delta-seconds：告知瀏覽器該響應本地緩存有效的最長期限，以秒為單位；優(yōu)先級：pragma >cache-control >?expires。當瀏覽器沒有命中本地緩存，如本地緩存過期或者響應中聲明不允許直接使用本地緩存，那么瀏覽器肯定會發(fā)起服務端請求；

　　服務端會驗證數據是否修改，如果沒有通知瀏覽器使用本地緩存。相關header：last-modified：通知瀏覽器資源的最后修改時間；if-modified-since：得到資源的最后修改時間后，會將這個信息通過它提交到服務器做檢查，如果沒有修改，返回304狀態(tài)碼；ETag：HTTP1.1推出，文件的指紋標識符，如果文件內容修改，指紋會改變；if-none-match：本地緩存失效，會攜帶此值去請求服務端，服務端判斷該資源是否改變，如果沒有改變，直接使用本地緩存，返回304

　　緩存策略的選擇：適合緩存的內容：不變的圖像，如logo，圖標等，js，css靜態(tài)文件，可下載的內容，媒體文件；建議使用協(xié)商緩存：html文件，經常替換的圖片，經常修改的js，css文件，js和css文件的加載可以加入文件的簽名來拒絕緩存，如a.css?簽名或a.簽名.js；不建議緩存的內容：用戶隱私等敏感數據，經常改變的api數據接口

nginx配置緩存策略：

本地緩存配置：add_header指令：添加狀態(tài)碼為2xx和3xx的響應頭信息，add_header?name?value [always];，可以設置Pragma/Expires/Cache-Control，可以繼承；expires指令：通知瀏覽器過期時長，expires?time;，為負值時表示Cache-Control: no-cache;，當為正或者0時，就表示Cache-Control: max-age=指定的時間;；當為max時，Cache-Control設置到10年；

協(xié)商緩存相關配置：Etag指令：指定簽名；etag?on|off;，默認是on

　　前端代碼和資源的壓縮：讓資源文件更小，加快文件在網絡中的傳輸，讓網頁更快的展現，降低帶寬和流量開銷；壓縮方式：js，css，圖片，html代碼的壓縮，Gzip壓縮。js代碼壓縮：一般是去掉多余的空格和回車，替換長變量名，簡化一些代碼寫法等，代碼壓縮工具很多UglifyJS(壓縮，語法檢查，美化代碼，代碼縮減，轉化)、YUI Compressor(來自yahoo，只有壓縮功能)、Closure Compiler(來自google，功能和UglifyJS類似，壓縮的方式不一樣)，有在線工具tool.css-js.com，應用程序，編輯器插件。css代碼壓縮：原理和js壓縮原理類似，同樣是去除空白符，注釋并且優(yōu)化一些css語義規(guī)則等，壓縮工具CSS Compressor(可以選擇模式)。html代碼壓縮：不建議使用代碼壓縮，有時會破壞代碼結構，可以使用Gzip壓縮，當然也可以使用htmlcompressor工具，不過轉換后一定要檢查代碼結構。img壓縮：一般圖片在web系統(tǒng)的比重都比較大，壓縮工具：tinypng，JpegMini，ImageOptim。Gzip壓縮：配置nginx服務，gzip?on|off，gzip_buffers 32 4K|16 8K #緩沖(在內存中緩存幾塊？每塊多大)，gzip_comp_level [1-9] #推薦6?壓縮級別(級別越高，壓的越小，越浪費CPU計算資源)，gzip_disable #正則匹配UA?什么樣的uri不進行gzip，gzip_min_length 200 #開始壓縮的最小長度，gzip_http_version 1.0|1.1 #開始壓縮的http協(xié)議版本，gzip_proxied #設置請求者代理服務器，該如何緩存內容，gzip_types?text/plain applocation/xml #對哪些類型的文件用壓縮，gzip_vary on|off #是否傳輸gzip壓縮標志。其他工具：自動化構建工具Grunt。

5. CDN加速

????CDN：Content Delivery Network，內容分發(fā)網絡，盡可能避開互聯網上有可能影響數據傳輸速度和穩(wěn)定性的瓶頸和環(huán)節(jié)，使內容傳輸的更快更穩(wěn)定；在網絡各處放置節(jié)點服務器所構成的在現有的互聯網基礎之上的一層智能虛擬網絡；CDN系統(tǒng)能夠實時的根據網絡流量和各節(jié)點的連接，負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求重新導向離用戶最近的服務節(jié)點上。本地cache加速，提高了企業(yè)站點(尤其含有大量img和靜態(tài)頁面站點)的訪問速度；跨運營商的網絡加速，保證不同網絡的用戶都得到良好的訪問質量；遠程訪問用戶根據DNS負載均衡技術智能自動選擇cache服務器；自動生成服務器的遠程Mirror?cache服務器，遠程用戶訪問時從cache服務器上讀數據，減少遠程訪問的帶寬，分擔網絡流量，減輕原站點web服務器負載等功能；廣泛分布的CDN節(jié)點加上節(jié)點之間的只能智能冗余機制，可以有效的預防黑客入侵

　　CDN的工作原理：傳統(tǒng)訪問：用戶在瀏覽器輸入域名發(fā)起請求--解析域名獲取服務器IP地址--根據IP地址找到對應的服務器--服務器響應并返回數據；使用CDN訪問：用戶發(fā)起請求--智能DNS的解析(根據IP判斷地理位置，接入網類型，選擇路由最短和負載最輕的服務器)--取得緩存服務器IP--把內容返回給用戶(如果緩存中有)--向源站發(fā)起請求--將結果返回給用戶--將結果存入緩存服務器

　　CDN適用場景：站點或者應用中大量靜態(tài)資源的加速分發(fā)，如css，js，img和html；大文件下載；直播網站等

　　CDN的實現：BAT等都有提供CDN服務，可用LVS做4層負載均衡；可用nginx，Varnish，Squid，Apache TrafficServer做7層負載均衡和cache；使用squid反向代理，或者nginx等的反向代理

6. 建立獨立的圖片服務器

????????獨立的必要性：分擔web服務器的I/O負載-將耗費資源的圖片服務分離出來，提高服務器的性能和穩(wěn)定性；能夠專門的圖片服務器進行優(yōu)化-為圖片服務設置有針對性的緩存方案，減少帶寬成本，提高訪問速度；提高網站的可擴展性-通過增加圖片服務器，提高圖片吞吐能力

　　采用獨立域名：原因：同一域名下瀏覽器的并發(fā)連接數有限制，突破瀏覽器連接數的限制；由于cookie的原因，對緩存不利，大部分web?cache都只緩存不帶cookie的請求，導致每次的圖片請求都不能命中cache

　　獨立后的問題：如何進行圖片上傳和圖片同步：NFS共享方式；利用FTP同步

7.?動態(tài)語言靜態(tài)化

　　將現有PHP等動態(tài)語言的邏輯代碼生成為靜態(tài)HTML文件，用戶訪問動態(tài)腳本重定向到靜態(tài)HTML文件的過程。對實時性要求不高的頁面比較適合。原因：動態(tài)腳本通常會做邏輯計算和數據查詢，訪問量越大，服務器壓力越大；訪問量大時可能會造成CPU負載過高，數據庫服務器壓力過大；靜態(tài)化可以降低邏輯處理壓力，降低數據庫服務器查詢壓力

靜態(tài)化的實現方式：

????????使用模板引擎：可以使用smarty的緩存機制生成靜態(tài)HTML緩存文件；$smarty->cache-dir = $ROOT."/cache";//緩存目錄，$smarty->caching=true;//是否開啟緩存，$smarty->cache_lifetime="3600";//緩存時間，$smarty->display(string?template[, string cache_id[, string compile_id]]);，$smarty->clear_all_cache();//清除所有緩存，$smarty->clear_cache('a.html');//清除指定的緩存，$smarty->clear_cache('a.html', $art_id);//清除同一個模板下的指定緩存號的緩存

????????利用ob系列的函數：ob_start()：打開輸出控制緩沖，ob_ge_contents()：返回輸出緩沖區(qū)內容，ob_clean()：清空輸出緩沖區(qū)，ob_end_flush()：沖刷出(送出)輸出緩沖區(qū)內容并關閉緩沖，可以判斷文件的inode修改時間，判斷是否過期使用filectime函數

8. 動態(tài)語言層的并發(fā)處理

????????進程：計算機中的程序關于某數據集合上的一次運行活動，是系統(tǒng)進行資源分配和調度的基本單位，是操作數據結構的基礎，是一個“執(zhí)行中的程序”；進程的三態(tài)模型：多道程序系統(tǒng)中，進程在處理器上交替運行，狀態(tài)不斷的發(fā)生變化；運行：當一個進程在處理機上運行時，稱該進程處于運行狀態(tài)，處于此狀態(tài)的進程的數目小于等于處理器的數目，對于單處理機系統(tǒng)，處于運行狀態(tài)的進程只有一個，在沒有其他進程可以執(zhí)行時(如所有進程都在阻塞狀態(tài))，通常會自動執(zhí)行系統(tǒng)的空閑進程；就緒：當一個進程獲得了除處理機以外的一切所需資源，一旦得到處理機即可運行，則稱此進程處于就緒狀態(tài)，就緒進程可以按多個優(yōu)先級來劃分隊列，如當一個進程由于時間片用完而進入就緒狀態(tài)時，排入低優(yōu)先級隊列，當進程由I/O操作完成而進入就緒狀態(tài)時，排入高優(yōu)先級隊列；阻塞：也稱為等待或睡眠狀態(tài)，一個進程正在等待某一事件發(fā)生(如請求I/O而等待I/O完成等)而暫時停止運行，這時即使把處理機分配給進程也無法運行；進程的五態(tài)模型：對于一個實際的系統(tǒng)，進程的狀態(tài)及其轉換更為復雜，新建態(tài)：對應于進程剛剛被創(chuàng)建時沒有被提交的狀態(tài)，并等待系統(tǒng)完成創(chuàng)建進程的所有必要信息；活躍就緒/靜止就緒：進程在主存并且可被調度的狀態(tài)/指進程被對換到輔存時的就緒狀態(tài)，是不能被直接調度的狀態(tài)，只有當主存中沒有活躍就緒態(tài)進程，或者是掛起就緒態(tài)進程具有更高的優(yōu)先級，系統(tǒng)將把掛起就緒態(tài)進程調回主存并轉換為活躍就緒；運行，活躍阻塞/靜止阻塞：指進程已在主存，一旦等待的時間產生便進入活躍就緒狀態(tài)/進程對換到輔存時的阻塞狀態(tài)，一旦等待的事件產生便進入靜止就緒狀態(tài)；終止態(tài)：進程已結束運行，回收除進程控制塊之外的其他資源，并讓其他進程從進程控制塊中收集有關信息；由于用戶的并發(fā)請求，為每一個請求都創(chuàng)建一個進程顯然是行不通的，從系統(tǒng)資源開銷方面或是響應用戶請求的效率方面來看，因此線程的概念被引進。

　　線程：有時被稱為輕量級進程，是程序執(zhí)行流的最小單元。是進程中的一個實體，是被系統(tǒng)獨立調度和分派的基本單位，自己不擁有系統(tǒng)資源，只擁有一點在運行中必不可少的資源但它可與同屬一個進程的其它進程共享進程所擁有的全部資源。一個線程可以創(chuàng)建和撤銷另一個線程，同一進程中的多個線程之間可以并發(fā)執(zhí)行。線程是程序中一個單一的順序控制流程，進程內一個相對獨立的、可調度的執(zhí)行單元，是系統(tǒng)獨立調度和分派CPU的基本單位指運行中的程序的調度單位。在單個程序中同時運行多個線程完成不同的工作成為多線程。每一個程序都至少有一個線程，若程序只有一個線程，那就是程序本身。線程的狀態(tài)：就緒：線程具備運行的所有條件，邏輯上可以運行，在等待處理機；運行：線程占有處理機正在運行；阻塞：線程在等待一個事件(如某個信號量)，邏輯上不可執(zhí)行。?

　　協(xié)程：是一種用戶態(tài)的輕量級線程，調度完全由用戶控制；協(xié)程擁有自己的寄存器上下文和棧；協(xié)程調度切換時，將寄存器上下文和棧保存到其他地方，在切回來的時候，恢復先前保存的寄存器上下文和棧，直接操作棧則基本沒有內核切換的開銷，可以不加鎖的訪問全局變量，所以上下文的切換非?？?。

　　進程和線程的區(qū)別：線程是進程內的一個執(zhí)行單元，進程內至少有一個線程，共享進程的地址空間，而進程有自己獨立的地址空間；進程是資源分配和擁有的單元，同一個進程內的線程共享進程的資源；線程是處理器調度的基本單位，但進程不是；二者均可并發(fā)執(zhí)行；每個獨立的線程有一個程序運行的入口，順序執(zhí)行序列和程序的出口，但是線程不能夠獨立執(zhí)行，必須依存在應用程序中，由應用程序提供多個線程執(zhí)行控制

　　線程和協(xié)程的區(qū)別：一個線程可以多個協(xié)程，一個進程也可以單獨擁有多個協(xié)程；進程線程都是同步機制，而協(xié)程則是異步；協(xié)程能保留上一次調用時的狀態(tài)，每次過程重入時，就相當于進入上一次調用的狀態(tài)。?

　　多進程：同一時間里，同一個計算機系統(tǒng)中如果允許兩個或兩個以上的進程處于運行狀態(tài)；多開一個進程，多分配一份資源，進程間通訊不方便；

　　多線程：線程就是把一個進程分為很多片，每一片都可以是一個獨立的流程，與多進程的區(qū)別是只會使用一個進程的資源，線程間可以直接通信；

　　同步阻塞：多進程：最早的服務器端程序都是通過多進程，多線程來解決并發(fā)I/O的問題；一個請求創(chuàng)建一個進程，然后子進程進入循環(huán)同步阻塞地與客戶端連接進行交互，收發(fā)處理數據；多線程：線程中可以直接向某一個客戶端連接發(fā)送數據；步驟：創(chuàng)建一個socket，進入while循環(huán)，阻塞在進程accept操作上，等待客戶端連接進入，主進程在多進程模型下通過fork創(chuàng)建子進程，多線程模型下可以創(chuàng)建子線程，子進程/線程創(chuàng)建成功后進入while循環(huán)，阻塞在recv調用上，等待客戶端向服務器發(fā)送數據，收到數據后服務器程序進行處理然后使用send向客戶端發(fā)送響應，當客戶端連接關閉時，子進程/線程退出并銷毀所有資源。主進程/線程會回收掉此子進程/線程；缺點：這種模型嚴重依賴進程的數量解決并發(fā)問題，啟動大量進程會帶來額外的進程調度消耗

　　異步非阻塞：現在各種高并發(fā)異步IO的服務器程序都是基于epoll(無限數量連接，無需輪詢)實現的。IO復用異步非阻塞程序使用經典的Reactor模型，Reactor顧名思義就是反應堆的意思，它本身不處理任何數據收發(fā)，只是可以監(jiān)視一個socket句柄的事件變化。Reactor模型：Add：添加一個socket到Reactor，Set：修改socket對應的事件，如可讀可寫，Del：從Reactor中移除，Callback：事件發(fā)生后回調指定的函數。Nginx：多線程Reactor，swoole：多線程Reactor+多進程Worker

　　PHP的swoole擴展：PHP的異步，并行，高性能網絡通信引擎，使用純c語言編寫，提供了PHP語言的異步多線程服務器，異步TCP/UDP網絡客戶端，異步mysql，異步redis，數據庫連接池，asynctask，消息隊列，毫秒定時器，異步文件讀寫，異步DNS查詢；除了異步IO的支持之外，swoole為PHP多進程的模式設計了多個并發(fā)數據結構和IPC通信機制，可以大大簡化多進程并發(fā)編程的工作；swoole2.0支持了類似Go語言的協(xié)程，可以使用完全同步的代碼實現異步程序

　　消息隊列：用戶注冊后，需要發(fā)注冊郵件和注冊短信；串行方式：將注冊信息寫入數據庫成功后，發(fā)送注冊郵件，再發(fā)送注冊短信；并行方式：將注冊信息寫入數據庫成功后，發(fā)送注冊郵件的同時，發(fā)送注冊短信；消息隊列方式：將注冊信息寫入數據庫成功后，將成功信息寫入隊列，此時直接返回成功給用戶，寫入隊列的時間非常短，可以忽略不計，然后異步發(fā)送郵件和短信。應用解耦：場景說明：用戶下單后，訂單系統(tǒng)需要通知庫存系統(tǒng)。假如庫存系統(tǒng)無法訪問，則訂單減庫存將失敗，從而導致訂單失??；訂單系統(tǒng)與庫存系統(tǒng)耦合；引用隊列：用戶下單后，訂單系統(tǒng)完成持久化處理，將消息寫入消息隊列，返回用戶訂單下單成功，訂閱下單的消息，采用拉/推的方式，獲取下單信息，庫存系統(tǒng)根據下單信息，進行庫存操作。流量削峰：應用場景：秒殺活動，流量瞬時激增，服務器壓力大。用戶發(fā)起請求，服務器接收后，先寫入消息隊列，假如消息隊列長度超過最大值，則直接報錯或提示用戶，后續(xù)程序讀取消息隊列再做處理，控制請求量，緩解高流量。日志處理：應用場景：解決大量日志的傳輸。日志采集程序將程序寫入消息隊列，然后通過日志處理程序的訂閱消費日志。消息通訊：應用場景：聊天室。多個客戶端訂閱同一主題，進行消息發(fā)布和接收。常見消息隊列產品：Kafka，ActiveMQ，ZeroMQ，RabbitMQ，Redis等

　　接口的并發(fā)請求：curl_multi_init

9.?數據庫緩存層的優(yōu)化

????mysql等一些常見的關系型數據庫的數據都存儲在磁盤當中，在高并發(fā)場景下，業(yè)務應用對mysql產生的增刪改查的操作造成的巨大的IO開銷和查詢壓力，這無疑對數據庫和服務器都是一種巨大的壓力，為了解決此類問題，緩存數據的概念應運而生。極大的解決數據庫服務器的壓力，提高應用數據的響應速度。常見的緩存形式：內存緩存，文件緩存。

　　緩存數據是為了讓客戶端很少甚至不訪問數據庫服務器進行數據的查詢，高并發(fā)下，能最大程度的降低對數據庫服務器的訪問壓力。默認情況下：用戶請求->數據查詢->連接數據庫服務器并查詢數據->將數據緩存起來(html，內存，json，序列化數據)->顯示給客戶端；用戶再次請求或者新用戶訪問->數據查詢->直接從緩存中獲取數據->顯示給客戶端

　　mysql的查詢緩存：query_cache_type：查詢緩存類型，有0,1,2三個取值，0則不使用查詢緩存，1表示始終使用查詢緩存，2表示按需使用查詢緩存。query_cache_type為1時，亦可關閉查詢緩存，SELECT SQL_NO_CACHE * FROM?my_table WHERE?condition。query_cache_type為2時，可按需使用查詢緩存，SELECT SQL_CACHE * FROM?my_table WHERE?condition。query_cache_size：默認情況下為0，表示為查詢緩存預留的內存為0，則無法使用查詢緩存。SET GLOBAL?query_cache_size = 134217728。查詢緩存可以看做是SQL文本和查詢結果的映射。第二次查詢的SQL和第一次查詢的SQL完全相同，則會使用緩存。SHOW STATUS LIKE 'Qcache_hits';?查看命中次數。表的結構或數據發(fā)生改變時，查詢緩存中的數據不再有效。清理緩存：FLUSH QUERY CACHE; //清理查詢緩存內存碎片，RESET QUERY CACHE; //從查詢緩存中移出所有查詢，FLUSH TABLES; //關閉所有打開的表，同時該操作將會清空查詢緩存中的內容

　　使用memcache緩存查詢數據：對于大型站點，如果沒有中間緩存層，當流量打入數據庫層時，即便有之前的幾層為我們擋住一部分流量，但是在大并發(fā)的情況下，還是會有大量請求涌入數據庫層，這樣對于數據庫服務器的壓力沖擊很大，響應速度也會下降，因此添加中間緩存層很有必要。memcache是一套分布式的高速緩存系統(tǒng)，由livejournal的bradfitzpatrick開發(fā)，但目前被許多網站使用以提升網站的訪問速度，尤其對于一些大型的，需要頻繁訪問數據庫的網站訪問速度提升效果十分顯著。

　　memcache工作原理：是一個高性能的分布式的內存對象緩存系統(tǒng)，通過在內存里維護一個統(tǒng)一的巨大的hash表，能夠用來存儲各種格式的數據，包括圖像，視頻，文件以及數據庫檢索的結果等，簡單的說就是將數據調用到內存，然后從內存中讀取，從而大大提高讀取速度。

　　memcache工作流程：先檢查客戶端的請求數據是否在memcache中，如有，直接把請求數據返回，不再對數據庫進行任何操作；如果請求的數據不在memcache中，就去查數據庫，把從數據庫中獲取的數據返回給客戶端，同時把數據緩存一份到memcache中。

　　memcache方法：獲?。篻et(key)?設置：set(key, val, expire)?刪除：delete(key)

　　通用緩存機制：用查詢的方法名+參數作為查詢時的key?value對中的key值

　　使用redis緩存查詢數據：與memcache的區(qū)別：性能相差不大，redis在2.0版本后增加了自己的VM特性，突破物理內存的限制，memcache可以修改最大可用內存，采用LRU算法；redis依賴客戶端來實現分布式讀寫，memcache本身沒有數據冗余機制；redis支持快照，AOF，依賴快照進行持久化，aof增強了可靠性的同時，對性能有所影響，memcache不支持持久化，通常做緩存，提升性能；memcache在并發(fā)場景下，用cas保證一致性，redis事務支持比較弱，只能保證事務中的每個操作連續(xù)執(zhí)行；redis支持多種類的數據類型；redis用于數據量較小的高性能操作和運算上，memcache用于在動態(tài)系統(tǒng)中減少數據庫負載，提升性能，適合做緩存，提高性能

　　緩存其他數據：session：session_set_save_handler

10.?mysql數據庫層的優(yōu)化

????優(yōu)化方向：數據表數據類型優(yōu)化，索引優(yōu)化，sql語句優(yōu)化，存儲引擎的優(yōu)化，數據表結構設計的優(yōu)化，數據庫服務器架構的優(yōu)化

　　數據表數據類型優(yōu)化：字段使用什么樣的數據類型更合適，性能更快，tinyint、smallint、bigint，考慮空間和范圍的問題；char、varchar，存儲字符串長度是否固定；enum，特定固定的分類可以使用enum存儲，效率更快；IP地址的存儲，ip2long()，使用整型存儲IP地址

　　索引的優(yōu)化：建立合適的索引，索引在什么場景下效率最高，索引的創(chuàng)建原則：不是越多越好，在合適的字段上創(chuàng)建合適的索引，復合索引的前綴原則，like查詢%的問題，全表掃描優(yōu)化，or條件索引使用情況，字符串類型索引失效的問題

　　sql語句的優(yōu)化：優(yōu)化查詢過程中的數據訪問，優(yōu)化長難句、特定類型的查詢語句。使用limit，返回列不用*，變復雜為簡單，切分查詢，分解關聯查詢，優(yōu)化count()，優(yōu)化關聯查詢，優(yōu)化子查詢，優(yōu)化group?by和distinct，優(yōu)化limit和union

　　存儲引擎的優(yōu)化：盡量使用innoDB存儲引擎

　　數據表結構設計的優(yōu)化：分區(qū)操作，通過特定的策略對數據表進行物理拆分，對用戶透明，partition?by；分庫分表，水平拆分，垂直拆分

　　數據庫架構的優(yōu)化：主從復制，讀寫分離，雙主熱備，binlog日志，中繼日志，主從庫binlog的交換，事件傳輸；負載均衡，通過LVS的三種基本模式實現負載均衡，mycat數據庫中間件實現負載均衡

11.?web服務器的負載均衡

????七層負載均衡的實現：基于URL等應用層信息的負載均衡，nginx的proxy是它一個很強大的功能，實現了7層負載均衡，功能強大，性能卓越，運行穩(wěn)定，配置簡單靈活，能夠自動剔除工作不正常的后端服務器，上傳文件使用異步模式，支持多種分配策略，可以分配權重，分配方式靈活。

nginx負載均衡：內置策略：IP Hash，加權輪詢；擴展策略：fair策略，通用hash，一致性hash

加權輪詢：首先將請求都分給高權重的機器，直到該機器的權值降到了比其他機器低，才開始將請求分給下一個高權重的機器，當所有后端機器都down掉時，nginx會立即將所有機器的標志位清成初始狀態(tài)，以避免造成所有的機器都處在timeout的狀態(tài)；IP Hash：流程和輪詢很類似，只是其中的算法和具體的策略有些變化，算法是一種變相的輪詢算法；fair：根據后端服務器的響應時間判斷負載情況，從中選出負載最輕的機器進行分流；通用hash，一致性hash：通用hash比較簡單，可以以nginx內置的變量為key進行hash，一致性hash采用了nginx內置的一致性hash環(huán)，支持memcache

　　nginx配置：

http { upstream cluster{

#ip_hash;? ? ? ? server srv1 weight=1;? ? ? ? server srv2;? ? ? ? server srv3;? ?

?}? ??

?server {? ? ? ? listen 80;? ? ? ? location / {? ? ? ? ? ? proxy_pass http://cluster;? ? ? ? }? ??

}??

?}

四層負載均衡的實現：通過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。LVS實現服務器集群負載均衡有三種方式，NAT，DR和TUN。

轉載自博客園? 博客園??高并發(fā)解決方案

最后編輯于 ：
?著作權歸作者所有,轉載或內容合作請聯系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發(fā)布，文章內容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

友情鏈接更多精彩內容