咱們說的高并發(fā)是什么？
上面的界說顯著不是咱們一般所言的并發(fā)，在互聯(lián)網(wǎng)年代，所講的并發(fā)、高并發(fā)，一般是指并發(fā)拜訪。也就是在某個時刻點，有多少個拜訪一起到來一般假如一個體系的日PV在千萬以上，有可能是一個高并發(fā)的體系，可是有的公司完全不走技能道路，全賴機器堆，這不在咱們的評論規(guī)模。
高并發(fā)的問題，咱們詳細該關懷什么？
QPS：每秒鐘懇求或許查詢的數(shù)量，在互聯(lián)網(wǎng)范疇，指每秒呼應懇求數(shù)(指HTTP懇求)
吞吐量：單位時刻內(nèi)處理的懇求數(shù)量(一般由QPS與并發(fā)數(shù)決議)
呼應時刻：從懇求發(fā)出到收到呼應花費的時刻，例如體系處理一個HTTP懇求需求100ms，這個100ms就是體系的呼應時刻
PV：歸納閱讀量(Page View)，即頁面閱讀量或許點擊量，一個訪客在24小時內(nèi)拜訪的頁面數(shù)量，同一個人閱讀你的網(wǎng)站同一頁面，只記作一次PV
UV：獨立拜訪(UniQue Visitor)，即必定時刻規(guī)模內(nèi)相同訪客屢次拜訪網(wǎng)站，只核算為1個獨立訪客
帶寬：核算帶寬巨細需重視兩個目標，峰值流量和頁面的均勻巨細
日網(wǎng)站帶寬=PV/計算時刻(換算到秒)*均勻頁面巨細(單位KB)*8
峰值一般是均勻值的倍數(shù)，依據(jù)實踐情況來定
QPS不等于并發(fā)銜接數(shù)
QPS是每秒HTTP懇求數(shù)量，并發(fā)銜接數(shù)是體系一起處理的懇求數(shù)量
(總PV數(shù)*80%)/(6小時秒數(shù)*20%)=峰值每秒懇求數(shù)(QPS)
80%的拜訪量會集在20%的時刻?。?！
QPS到達極限，各種情況如何處理？
跟著QPS的增加，每個階段需求依據(jù)實踐情況來進行優(yōu)化，優(yōu)化的計劃也與硬件條件、網(wǎng)絡帶寬休戚相關。
QPS到達50
能夠稱之為小型網(wǎng)站，一般的效勞器就能夠敷衍
QPS到達100
假定聯(lián)系型數(shù)據(jù)庫的每次懇求在0.01秒完結
假定單頁面只要一個SQL查詢，那么100QPS意味這1秒鐘完結100次懇求，可是此刻咱們并不能確保數(shù)據(jù)庫查詢能完結100次
計劃：數(shù)據(jù)庫緩存層、數(shù)據(jù)庫的負載均衡
QPS到達800
假定咱們運用百兆帶寬，意味著網(wǎng)站出口的實踐帶寬是8M左右
假定每個頁面只要10k，在這個并發(fā)條件下，百兆帶寬現(xiàn)已吃完
計劃：CDN加快、負載均衡
QPS到達1000
假定運用Memcache緩存數(shù)據(jù)庫查詢數(shù)據(jù)，每個頁面臨Memcache的懇求遠大于直接對DB的懇求
Memcache的失望并發(fā)數(shù)在2W左右，但有可能在之前內(nèi)網(wǎng)帶寬現(xiàn)已吃光，表現(xiàn)出不安穩(wěn)
計劃：靜態(tài)HTML緩存
QPS到達2000
這個級別下，文件體系拜訪鎖都成為災禍
計劃：做事務別離，散布式存儲
#三種高并發(fā)處理計劃#
一、數(shù)據(jù)庫緩存層的優(yōu)化
什么是數(shù)據(jù)庫緩存？
MySQL等一些常見的聯(lián)系型數(shù)據(jù)庫的數(shù)據(jù)都存儲在磁盤中，在高并發(fā)場景下，事務運用對MySQL發(fā)生的增、刪、改、查的操作形成巨大的I/O開支和查詢壓力，這無疑對數(shù)據(jù)庫和效勞器都是一種巨大的壓力，為了處理此類問題，緩存數(shù)據(jù)的概念應運而生
為什么是要運用緩存？
緩存數(shù)據(jù)是為了讓客戶端很少甚至不拜訪數(shù)據(jù)庫效勞器進行數(shù)據(jù)的查詢，高并發(fā)下，能最大程度的下降對數(shù)據(jù)庫效勞器的拜訪壓力極大地處理數(shù)據(jù)庫效勞器的壓力
進步運用數(shù)據(jù)的呼應速度
用戶懇求-->數(shù)據(jù)查詢-->銜接數(shù)據(jù)庫效勞器并查詢數(shù)據(jù)-->將數(shù)據(jù)緩存起來(HTML、內(nèi)存、JSON、序列化數(shù)據(jù))-->顯現(xiàn)給客戶端
用戶再次懇求或許新用戶拜訪-->數(shù)據(jù)查詢-->直接從緩存中獲取數(shù)據(jù)-->顯現(xiàn)給客戶端
二、CDN加快
什么是CDN？
CDN的全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡，盡可能避開互聯(lián)網(wǎng)上有可能影響數(shù)據(jù)傳輸速度和安穩(wěn)性的瓶頸和環(huán)節(jié)，使內(nèi)容傳輸?shù)母?、更安穩(wěn)
在網(wǎng)絡遍地放置節(jié)點效勞器所構成的在現(xiàn)有的互聯(lián)網(wǎng)根底之上的一層智能虛擬網(wǎng)絡
CDN體系能夠實時地依據(jù)網(wǎng)絡流量和各節(jié)點的銜接、負載情況以及到用戶的間隔和呼應時刻等歸納信息將用戶的懇求從頭導向離用戶最近的效勞節(jié)點上
運用CDN的優(yōu)勢？
本地Cache加快，進步了企業(yè)站點(特別含有很多圖片和靜態(tài)頁面站點)的拜訪速度
跨運營商的網(wǎng)絡加快，確保不同網(wǎng)絡的用戶都得到杰出的拜訪質量
長途拜訪用戶依據(jù)DNS負載均衡技能智能主動挑選Cache效勞器
主動生成效勞器的長途Mirror(鏡像)cache效勞器，長途用戶拜訪時從cache效勞器上讀取數(shù)據(jù)，削減長途拜訪的帶寬，分管網(wǎng)絡流量，減輕原站點WEB效勞器負載等功用
廣泛散布的CDN節(jié)點加上節(jié)點之間的智能冗余機制，能夠有效地防止黑客侵略
三、Web效勞器的負載均衡、懇求分發(fā)
七層負載均衡的完成
根據(jù)URL等運用信息的負載均衡
Nginx的proxy是它一個很強壯的功用，完成了7層負載均衡
Nginx完成的長處
功用強壯，功能杰出，運轉安穩(wěn)
裝備簡略靈敏
能夠主動除掉作業(yè)不正常的后端效勞器
上傳文件運用異步形式
支撐多種分配戰(zhàn)略，能夠分配權重，分配方法靈敏
Nginx負載均衡
內(nèi)置戰(zhàn)略，擴展戰(zhàn)略
內(nèi)置戰(zhàn)略：IP Hash、加權輪詢
擴展戰(zhàn)略：fair戰(zhàn)略、通用hash、一致性hash
加權輪詢戰(zhàn)略
首先將懇求都分給高權重的機器，直到該機器的權值降到了比其他機器低，才開端將懇求分給下一個高權重的機器
當一切后端機器都down掉時，Nginx會立行將一切機器的標志位清成初始狀況，以防止形成一切的機器都處于timeout的狀況
IP Hash戰(zhàn)略
Nginx內(nèi)置的另一個負載均衡的戰(zhàn)略，流程和輪詢很相似，僅僅七種的算法和詳細的戰(zhàn)略有些改變
IP Hash算法是一種變相的輪詢算法
