㈠ 用thinkphp 開發萬人在線的聊天室性能跟得上么
當你打算做聊天室的時候你可以自己看看如何解決以下問題：
數據的傳輸（如何及時把收到的數據傳輸給別人）
資料庫的處理（對於數據的操作，萬人在線的聊天室數據量產生肯定很大，那麼怎麼保證資料庫能扛得下去）
web伺服器是否有能力對抗那麼大的並發數量
伺服器的帶寬是否能支撐下去
以上四點是基於B/S架構必有的問題，如果並非B/S架構那麼後端也沒必要使用PHP吧？
第一點、可以使用websocket進行解決，但缺點是不能支持舊版本的瀏覽器
（如果需要支持可以使用AJAX輪詢進行處理，但會加大伺服器壓力）
第二點、可以增加緩存層，所有數據先進緩存，然後一定時間把緩存寫入資料庫。前提是需要內存足夠大
（或者可以使用資料庫中間件進行讀寫分離，或者直接分表處理）
第三點、再對WEB伺服器優化後你能做的只有創建集群，用幾台機去緩解壓力
第四點、買帶寬
說白了，沒有一定的金錢做為支持的背景下thinkphp和c做出來的性能相差不大，因為瓶頸並不在它那
㈡ 緩存策略的選擇
適合緩存的內容
1. 不變的圖像襲啟，如logo，圖標等
2. js、css靜態文件
3. 可下載的內容，媒體文件
適合協商緩存
1. HTML文件
2. 經常替換的圖片
3. 經常修改的js、css文件，js、css文件的載入可以加入文件的簽名來拒絕緩存，如『index.css?簽名』，『index.簽名.js』
不建議緩存的內容
1. 用戶隱私等敏感數據
2. 經常改變的API數據介面
NGINX配置緩存策略
本地緩存配置
1. add_header指令：添加狀態碼為2XX和3XX的響應頭信息，設置代碼add_header name value [always];，可以設置Pragma、Expires、Cache-Control，可以繼承
2. expires指令：通知瀏覽器過期時長，設置代碼expires time;
3. Etag指令：指定簽名，設置代碼etag on|off，默認on
前端代碼和資源壓縮
優勢
1. 讓資源文件更小，加快文件在網路中的傳輸，讓網頁更快的展現，降低帶寬和流量的開銷
壓縮方式
1. js、css、圖片、html代碼的壓縮
2. gzip壓縮
gzip配置
gzip on|off; #是否開啟gzipgzip_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協議版本
gzip_proxied #設置請求者代理伺服器，該如何緩存內容
gzip_types text/plain application/xml image/png #對哪些類型的文件壓縮，如txt、xml、css
gzip_vary on|off #是否傳輸gzip壓縮標志
CDN加速
定義
1. CDN的全稱content delivery network，內容分發網路
2. 盡可能避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定
3. 在網路各處放置節點伺服器所構成的有的互聯網基礎之上的一層智能虛擬網路
4. CDN系統能夠實現地根據網路流量和各節點的連接、負載狀況以及到用戶距離和響應時間等綜合信息將用戶的請求重新告禪洞導向離用戶最近的服務節點上
優勢
1. 本地cache加速，提高了企業站點（尤其含有大量圖片和靜態頁面站點）的訪問速度
2. 跨運營商的網路加速，保證不同網路的用戶都能得到良好的訪問質量
3. 遠程訪問用戶根據DNS負載均衡技術只能選擇cache伺服器
4. 自動生成伺服器襪枯的遠程Mirror（鏡像）cache伺服器，遠程用戶訪問時從cache伺服器上讀取數據，減少遠程訪問的帶寬、分擔網路流量、減輕原站點web伺服器負載等功能
5. 廣泛分布的cdn節點加上節點之間的智能冗餘機制，可以有效地預防黑客入侵
工作原理
1. 用戶發起請求
2. 智能DNS的解析（根據IP判斷地理位置、接入網類型、選擇路由最短和負載最輕的伺服器）
3. 取得緩存伺服器ip
4. 把內容返回給用戶（如果緩存中有，沒有就執行5、6、7）
5. 向源站發起請求
6. 將結果返回給用戶
7. 將結果存入緩存伺服器
適用場景
1. 站點或者應用中大量靜態資源的加速分發，例如css、js、圖片和HTML
2. 大文件下載
3. 直播網站
獨立圖片伺服器
必要性
1. 分擔web伺服器的I/O負載，將耗費資源的圖片伺服器分離出來，提高伺服器的性能和穩定性
2. 能夠專門對圖片伺服器進行優化，為圖片伺服器設置針對性的緩存方案，減少帶寬成本，提高訪問速度
3. 提高網站的可擴展性，通過增加圖片伺服器，提高圖片吞吐能力
採用獨立域名
原因：
1. 同一域名下瀏覽器的並發連接數有限制，突破瀏覽器連接數的限制
2. 由於cookie的原因，對緩存不利，大部分web cache都只緩存不帶cookie的請求，導致每次的圖片請求都不能命中cache
如何圖片上傳和同步
1. NFS共享方式
2. 利用FTP同步
動態語言靜態化
將現有的PHP等動態語言的邏輯代碼生成為靜態的HTML文件，用戶訪問動態腳本重定向到靜態HTML文件的過程。對實時性要求不高
原因：
1. 動態腳本通過會做邏輯計算和數據查詢，訪問量越大，伺服器壓力越大
2. 訪問量大時可能會造成CPU負載過高，資料庫伺服器壓力過大
3. 靜態化可以減低邏輯處理壓力，降低資料庫伺服器查詢壓力
實現方法
1. 使用模板引擎
2. 利用ob系列函數
需要獲取swoole、workerman、TP、laravel、vue、Linux、redis以及性能優化，並發項目實戰，微服務 架構方面的資料，可以私信我哦
㈢ 京東活動系統--億級流量架構應對之術
京東活動系統 是一個可在線編輯、實時編輯更新和發布新活動，並對外提供頁面訪問服務的系統。其高時效性、靈活性等特徵，極受青睞，已發展成京東幾個重要流量入口之一。近幾次大促，系統所承載的pv已經達到數億級。隨著京東業務的高速發展，京東活動系統的壓力會越來越大。急需要一個更高效，穩定的系統架構，來支持業務的高速發展。本文主要對活動頁面瀏覽方面的性能，進行探討。
活動頁面瀏覽性能提升的難點：
1. 活動與活動之間差異很大，不像商品頁有固定的模式。每個頁面能抽取的公共部分有限，可復用性差。
2. 活動頁面內容多樣，業務繁多。依賴大量外部業務介面，數據很難做到閉環。外部介面的性能，以及穩定性，嚴重製約了活動頁的渲染速度、穩定性。
經過多年在該系統下的開發實踐，提出「頁面渲染、瀏覽非同步化」的思想，並以此為指導，對該系統進行架構升級改造。通過近幾個月的運行，各方面性能都有顯著提升。在分享"新架構"之前，先看看我們現有web系統的架構現狀。
以京東活動系統架構的演變為例，這里沒有畫出具體的業務邏輯，只是簡單的描述下架構：
2.第二步，一般是在消耗性能的地方加緩存，這里對部分查庫操作加redis緩存
3.對頁面進行整頁redis緩存：由於活動頁面內容繁多，渲染一次頁面的成本是很高。這里可以考慮把渲染好的活動內容整頁緩存起來，下次請求到來時，如果緩存中有值，直接獲取緩存返回。
以上是系統應用服務層面架構演進的，簡單示意。為了減少應用伺服器的壓力，可以在應用伺服器前面，加cdn和nginx的proxy_caxhe，降低回源率。
4.整體架構（老）
除了前3步講的「瀏覽服務」，老架構還做了其他兩個大的優化：「介面服務」、靜態服務
1.訪問請求，首先到達瀏覽服務，把整個頁面框架返回給瀏覽器（有cdn、nginx、redis等各級緩存）。
2.對於實時數據（如秒殺）、個性化數據（如登陸、個人坐標），採用前端實時介面調用，前端介面服務。
3.靜態服務：靜態資源分離，所有靜態js、css訪問靜態服務。
要點：瀏覽服務、介面服務分離。頁面固定不變部分走瀏覽服務，實時變化、個性化採用前端介面服務實現。
介面服務：分兩類，直接讀redis緩存、調用外部介面。這里可以對直接讀redis的介面採用nginx+lua進行優化（ openresty ），不做詳細講解。 本次分享主要對「瀏覽服務」架構
在講新架構之前先看看新老架構下的新能對比
擊穿cdn緩存、nginx緩存，回源到應用伺服器的流量大約為20%-40%之間，這里的性能對比，只針對回源到應用伺服器的部分。
2015雙十一， 瀏覽方法tp99如下：（物理機）
Tp99 1000ms左右，且抖動幅度很大，內存使用近70%，cpu 45%左右。
1000ms內沒有緩存，有阻塞甚至掛掉的風險。
2.新架構瀏覽服務新能
本次2016 618採用新架構支持，瀏覽tp99如下（分app端活動和pc端活動）：
移動活動瀏覽tp99穩定在8ms, pc活動瀏覽tp99 穩定在15ms左右。全天幾乎一條直線，沒有性能抖動。
新架構支持，伺服器（docker）cpu性能如下
cpu消耗一直平穩在1%，幾乎沒有抖動。
對比結果：新架構tp99從1000ms降低到 15ms，cpu消耗從45%降低到1%，新架構性能得到質的提升。
why!!!
下面我們就來揭開新架構的面紗。
1. 頁面瀏覽，頁面渲染 非同步化
再來看之前的瀏覽服務架構，20%-40%的頁面請求會重新渲染頁面，渲染需要重新計算、查詢、創建對象等導致 cpu、內存消耗增加，tp99性能下降。
如果能保證每次請求都能獲取到redis整頁緩存，這些性能問題就都不存在了。
即：頁面瀏覽，與頁面渲染 非同步。
理想情況下，如果頁面數據變動可以通過 手動觸發渲染（頁面發布新內容）、外部數據變化通過監聽mq 自動觸發渲染。
但是有些外部介面不支持mq、或者無法使用mq，比如活動頁面置入的某個商品，這個商品名稱變化。
為了解決這個問題，view工程每隔指定時間，向engine發起重新渲染請求-最新內容放入redis。下一次請求到來時即可獲取到新內容。由於活動很多，也不能確定哪些活動在被訪問，所以不建議使用timer。通過加一個緩存key來實現，處理邏輯如下：
好處就是，只對有訪問的活動定時重新發起渲染。
整理架構（不包含業務）：
view工程職責 ：
a.直接從緩存或者硬碟中獲取靜態html返回，如果沒有返回錯誤頁面。（文件系統的存取性能比較低，超過 100ms級別，這里沒有使用）
b.根據緩存key2是否過期，判斷是否向engine重新發起渲染。（如果，你的項目外面介面都支持mq，這個 功能就不需要了）
engine工程職責 ：渲染活動頁面，把結果放到 硬碟、redis。
publish工程、mq 職責 ：頁面發生變化，向engine重新發起渲染。 具體的頁面邏輯，這里不做講解
Engine工程的工作 就是當頁面內容發生變化時，重新渲染頁面，並將整頁內容放到redis，或者推送到硬碟。
View工程的工作，就是根據鏈接從redis中獲取頁面內容返回。
3.view 工程架構 ( 硬碟 版)
兩個版本對比
a.Redis版
優點：接入簡單、 性能好，尤其是在大量頁面情況下，沒有性能抖動 。單個docker tps達到 700。
缺點：嚴重依賴京東redis服務，如果redis服務出現問題，所有頁面都無法訪問。
b.硬碟版
優點：不依賴任何其他外部服務，只要應用服務不掛、網路正常 就可以對外穩定服務。
在頁面數量不大的情況下，性能優越。單個docker tps達到 2000。
缺點：在頁面數據量大的情況下（系統的所有活動頁有xx個G左右），磁碟io消耗增加（這里採用的java io，如果採用nginx+lua，io消耗應該會控制在10%以內）。
解決方案：
a. 對所有頁面訪問和存儲 採用url hash方式，所有頁面均勻分配到各個應用伺服器上。
b. 採用nginx+lua 利用nginx的非同步io，代替java io。
現在通過nginx+lua做應用服務，所具有的高並發處理能力、高性能、高穩定性已經越來越受青睞。通過上述講解，view工程沒有任何業務邏輯。可以很輕易的就可以用lua實現，從redis或者硬碟獲取頁面，實現更高效的web服務。如果想學習Java工程化、高性能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java進階qun：694549689，裡面有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家。
1.具有1-5工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加。
2.在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加。
3.如果沒有工作經驗，但基礎非常扎實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的可以加。
通過測試對比，view工程讀本地硬碟的速度，比讀redis還要快（同一個頁面，讀redis是15ms，硬碟是8ms）。所以終極版架構我選擇用硬碟，redis做備份，硬碟讀不到時在讀redis。
這里前置機的url hash是自己實現的邏輯，engine工程採用同樣的規則推送到view伺服器硬碟即可，具體邏輯這里不細講。後面有時間再單獨做一次分享。
優點：具備硬碟版的全部優點，同時去掉tomcat，直接利用nginx高並發能力，以及io處理能力。各項性能、以及穩定性達到最優。
缺點：1、硬碟壞掉，影響訪問。2.方法監控，以及日誌列印，需使用lua腳本重寫。
無論是redis版、硬碟版、openresty+硬碟版，基礎都是頁面瀏覽與頁面渲染非同步化。
優勢：
1、所有業務邏輯都剝離到engine工程，新view工程理論上永遠無需上線。
2、災備多樣化（redis、硬碟、文件系統），且更加簡單，外部介面或者服務出現問題後，切斷engine工程渲染，不再更新redis和硬碟即可。
3、新view工程，與業務邏輯完全隔離，不依賴外部介面和服務，大促期間，即便外部介面出現新能問題，或者有外部服務掛掉，絲毫不影響view工程正常訪問。
4、性能提升上百倍，從1000ms提升到10ms左右。詳見前面的性能截圖。
5、穩定性：只要view伺服器的網路還正常，可以做到理論上用不掛機。
6、大幅度節省伺服器資源，按此架構，4+20+30=54個docker足以支持10億級pv。（4個nginx proxy_cache、20個view，30個engine）
從事開發已有近10載，一直就像寄生蟲一樣吸取著網路上的資源。前段時間受「張開濤」大神所託，對活動系統新架構做了一次簡單整理分享給大家，希望能給大家帶來一絲幫助。第一次在網上做分享，難免有些沒有考慮周全的地方，以後會慢慢的多分享一些自己的心得，大家一起成長。最後再來點心靈雞湯。。。
㈣ 如何搭建億級並發的系統架構
想設計億萬級高並發架構，你要先知道高並發是什麼？
面對流量高峰，不同的企業是如何通過技術手段解決高並發難題的呢?
0、引言
軟體系統有三個追求：高性能、高並發、高可用，俗稱三高。三者既有區別也有聯系，門門道道很多，全面討論需要三天三夜，本篇討論高並發。
高並發（High Concurrency）。並發是操作系統領域的一個概念，指的是一段時間內多任務流交替執行的現象，後來這個概念被泛化，高並發用來指大流量、高請求的業務情景，比如春運搶票，電商雙十一，秒殺大促等場景。
很多程序員每天忙著搬磚，平時接觸不到高並發，哪天受不了跑去面試，還常常會被面試官犀利的高並發問題直接KO，其實吧，高並發系統也不高深，我保證任何一個智商在線的看過這篇文章後，都能戰勝恐懼，重拾生活的信心。
本文先介紹高並發系統的度量指標，然後講述高並發系統的設計思路，再梳理高並發的關鍵技術，最後結合作者的經驗做一些延伸探討。
1、高並發的度量指標
既然是高並發系統，那並發一定要高，不然就名不副實。並發的指標一般有QPS、TPS、IOPS，這幾個指標都是可歸為系統吞吐率，QPS越高系統能hold住的請求數越多，但光關注這幾個指標不夠，我們還需要關注RT，即響應時間，也就是從發出request到收到response的時延，這個指標跟吞吐往往是此消彼長的，我們追求的是一定時延下的高吞吐。
比如有100萬次請求，99萬次請求都在10毫秒內響應，其他次數10秒才響應，平均時延不高，但時延高的用戶受不了，所以，就有了TP90/TP99指標，這個指標不是求平均，而是把時延從小到大排序，取排名90%/99%的時延，這個指標越大，對慢請求越敏感。
除此之外，有時候，我們也會關注可用性指標，這可歸到穩定性。
一般而言，用戶感知友好的高並發系統，時延應該控制在250毫秒以內。
什麼樣的系統才能稱為高並發？這個不好回答，因為它取決於系統或者業務的類型。不過我可以告訴你一些眾所周知的指標，這樣能幫助你下次在跟人扯淡的時候稍微靠點兒譜，不至於貽笑大方。
通常，資料庫單機每秒也就能抗住幾千這個量級，而做邏輯處理的服務單台每秒抗幾萬、甚至幾十萬都有可能，而消息隊列等中間件單機每秒處理個幾萬沒問題，所以我們經常聽到每秒處理數百萬、數千萬的消息中間件集群，而像阿某的API網關，每日百億請求也有可能。
2、高並發的設計思路
高並發的設計思路有兩個方向：
垂直方向擴展，也叫豎向擴展
水平方向擴展，也叫橫向擴展
垂直方向：提升單機能力
提升單機處理能力又可分為硬體和軟體兩個方面：
硬體方向，很好理解，花錢升級機器，更多核更高主頻更大存儲空間更多帶寬
軟體方向，包括用各快的數據結構，改進架構，應用多線程、協程，以及上性能優化各種手段，但這玩意兒天花板低，就像提升個人產出一樣，996、007、最多24 X 7。
水平方向：分布式集群
為了解決分布式系統的復雜性問題，一般會用到架構分層和服務拆分，通過分層做隔離，通過微服務解耦。
這個理論上沒有上限，只要做好層次和服務劃分，加機器擴容就能滿足需求，但實際上並非如此，一方面分布式會增加系統復雜性，另一方面集群規模上去之後，也會引入一堆AIOps、服務發現、服務治理的新問題。
因為垂直向的限制，所以，我們通常更關注水平擴展，高並發系統的實施也主要圍繞水平方向展開。
3、高並發的關鍵技術
玩具式的網路服務程序，用戶可以直連伺服器，甚至不需要資料庫，直接寫磁碟文件。但春運購票系統顯然不能這么做，它肯定扛不住這個壓力，那一般的高並發系統是怎麼做呢？比如某寶這樣的正經系統是怎麼處理高並發的呢？
其實大的思路都差不多，層次劃分 + 功能劃分。可以把層次劃分理解為水平方向的劃分，而功能劃分理解為垂直方向的劃分。
首先，用戶不能直連伺服器，要做分布式就要解決「分」的問題，有多個服務實例就需要做負載均衡，有不同服務類型就需要服務發現。
集群化：負載均衡
負載均衡就是把負載（request）均衡分配到不同的服務實例，利用集群的能力去對抗高並發，負載均衡是服務集群化的實施要素，它分3種：
DNS負載均衡，客戶端通過URL發起網路服務請求的時候，會去DNS伺服器做域名解釋，DNS會按一定的策略（比如就近策略）把URL轉換成IP地址，同一個URL會被解釋成不同的IP地址，這便是DNS負載均衡，它是一種粗粒度的負載均衡，它只用URL前半部分，因為DNS負載均衡一般採用就近原則，所以通常能降低時延，但DNS有cache，所以也會更新不及時的問題。
硬體負載均衡，通過布置特殊的負載均衡設備到機房做負載均衡，比如F5，這種設備貴，性能高，可以支撐每秒百萬並發，還能做一些安全防護，比如防火牆。
軟體負載均衡，根據工作在ISO 7層網路模型的層次，可分為四層負載均衡（比如章文嵩博士的LVS）和七層負載均衡（NGINX），軟體負載均衡配置靈活，擴展性強，阿某雲的SLB作為服務對外售賣，Nginx可以對URL的後半部做解釋承擔API網關的職責。
所以，完整的負載均衡鏈路是 client <-> DNS負載均衡 -> F5 -> LVS/SLB -> NGINX
不管選擇哪種LB策略，或者組合LB策略，邏輯上，我們都可以視為負載均衡層，通過添加負載均衡層，我們將負載均勻分散到了後面的服務集群，具備基礎的高並發能力，但這只是萬里長征第一步。
資料庫層面：分庫分表+讀寫分離
前面通過負載均衡解決了無狀態服務的水平擴展問題，但我們的系統不全是無狀態的，後面通常還有有狀態的資料庫，所以解決了前面的問題，存儲有可能成為系統的瓶頸，我們需要對有狀態存儲做分片路由。
資料庫的單機QPS一般不高，也就幾千，顯然滿足不了高並發的要求。
所以，我們需要做分庫分表 + 讀寫分離。
就是把一個庫分成多個庫，部署在多個資料庫服務上，主庫承載寫請求，從庫承載讀請求。從庫可以掛載多個，因為很多場景寫的請求遠少於讀的請求，這樣就把對單個庫的壓力降下來了。
如果寫的請求上升就繼續分庫分表，如果讀的請求上升就掛更多的從庫，但資料庫天生不是很適合高並發，而且資料庫對機器配置的要求一般很高，導致單位服務成本高，所以，這樣加機器抗壓力成本太高，還得另外想招。
讀多寫少：緩存
緩存的理論依據是局部性原理。
一般系統的寫入請求遠少於讀請求，針對寫少讀多的場景，很適合引入緩存集群。
在寫資料庫的時候同時寫一份數據到緩存集群里，然後用緩存集群來承載大部分的讀請求，因為緩存集群很容易做到高性能，所以，這樣的話，通過緩存集群，就可以用更少的機器資源承載更高的並發。
緩存的命中率一般能做到很高，而且速度很快，處理能力也強（單機很容易做到幾萬並發），是理想的解決方案。
CDN本質上就是緩存，被用戶大量訪問的靜態資源緩存在CDN中是目前的通用做法。
緩存也有很多需要謹慎處理的問題：
一致性問題：(a)更新db成功+更新cache失敗 -> 不一致 (b)更新db失敗+更新cache成功 -> 不一致 ©更新db成功+淘汰緩存失敗 -> 不一致
緩存穿透：查詢一定不存在的數據，會穿透緩存直接壓到資料庫，從而導致緩存失去作用，如果有人利用這個漏洞，大量查詢一定不存在的數據，會對資料庫造成壓力，甚至打掛資料庫。解決方案：布隆過濾器 或者 簡單的方案，查詢不存在的key，也把空結果寫入緩存（設置較短的過期淘汰時間），從而降低命失
緩存雪崩：如果大量緩存在一個時刻同時失效，則請求會轉到DB，則對DB形成壓迫，導致雪崩。簡單的解決方案是為緩存失效時間添加隨機值，降低同一時間點失效淘汰緩存數，避免集體失效事件發生
但緩存是針對讀，如果寫的壓力很大，怎麼辦？
高寫入：消息中間件
同理，通過跟主庫加機器，耗費的機器資源是很大的，這個就是資料庫系統的特點所決定的。
相同的資源下，資料庫系統太重太復雜，所以並發承載能力就在幾千/s的量級，所以此時你需要引入別的一些技術。
比如說消息中間件技術，也就是MQ集群，它是非常好的做寫請求非同步化處理，實現削峰填谷的效果。
消息隊列能做解耦，在只需要最終一致性的場景下，很適合用來配合做流控。
假如說，每秒是1萬次寫請求，其中比如5千次請求是必須請求過來立馬寫入資料庫中的，但是另外5千次寫請求是可以允許非同步化等待個幾十秒，甚至幾分鍾後才落入資料庫內的。
那麼此時完全可以引入消息中間件集群，把允許非同步化的每秒5千次請求寫入MQ，然後基於MQ做一個削峰填谷。比如就以平穩的1000/s的速度消費出來然後落入資料庫中即可，此時就會大幅度降低資料庫的寫入壓力。
業界有很多著名的消息中間件，比如ZeroMQ，rabbitMQ，kafka等。
消息隊列本身也跟緩存系統一樣，可以用很少的資源支撐很高的並發請求，用它來支撐部分允許非同步化的高並發寫入是很合適的，比使用資料庫直接支撐那部分高並發請求要減少很多的機器使用量。
避免擠兌：流控
再強大的系統，也怕流量短事件內集中爆發，就像銀行怕擠兌一樣，所以，高並發另一個必不可少的模塊就是流控。
流控的關鍵是流控演算法，有4種常見的流控演算法。
計數器演算法（固定窗口）：計數器演算法是使用計數器在周期內累加訪問次數，當達到設定的限流值時，觸發限流策略，下一個周期開始時，進行清零，重新計數，實現簡單。計數器演算法方式限流對於周期比較長的限流，存在很大的弊端，有嚴重的臨界問題。
滑動窗口演算法：將時間周期分為N個小周期，分別記錄每個小周期內訪問次數，並且根據時間滑動刪除過期的小周期，當滑動窗口的格子劃分的越多，那麼滑動窗口的滾動就越平滑，限流的統計就會越精確。此演算法可以很好的解決固定窗口演算法的臨界問題。
漏桶演算法：訪問請求到達時直接放入漏桶，如當前容量已達到上限（限流值），則進行丟棄（觸發限流策略）。漏桶以固定的速率進行釋放訪問請求（即請求通過），直到漏桶為空。分布式環境下實施難度高。
令牌桶演算法：程序以r（r=時間周期/限流值）的速度向令牌桶中增加令牌，直到令牌桶滿，請求到達時向令牌桶請求令牌，如獲取到令牌則通過請求，否則觸發限流策略。分布式環境下實施難度高。
4、高並發的實踐經驗
接入-邏輯-存儲是經典的互聯網後端分層，但隨著業務規模的提高，邏輯層的復雜度也上升了，所以，針對邏輯層的架構設計也出現很多新的技術和思路，常見的做法包括系統拆分，微服務。
除此之外，也有很多業界的優秀實踐，包括某信伺服器通過協程（無侵入，已開源libco）改造，極大的提高了系統的並發度和穩定性，另外，緩存預熱，預計算，批量讀寫（減少IO），池技術等也廣泛應用在實踐中，有效的提升了系統並發能力。
為了提升並發能力，邏輯後端對請求的處理，一般會用到生產者-消費者多線程模型，即I/O線程負責網路IO，協議編解碼，網路位元組流被解碼後產生的協議對象，會被包裝成task投入到task queue，然後worker線程會從該隊列取出task執行，有些系統會用多進程而非多線程，通過共享存儲，維護2個方向的shm queue，一個input q，一個output q，為了提高並發度，有時候會引入協程，協程是用戶線程態的多執行流，它的切換成本更低，通常有更好的調度效率。
另外，構建漏斗型業務或者系統，從客戶端請求到接入層，到邏輯層，到DB層，層層遞減，過濾掉請求，Fail Fast（盡早發現盡早過濾），嘴大屁眼小，哈哈。
漏斗型系統不僅僅是一個技術模型，它也可以是一個產品思維，配合產品的用戶分流，邏輯分離，可以構建全方位的立體模型。
5、小結
莫讓浮雲遮望眼，除去繁華識真顏。我們不能掌握了大方案，吹完了牛皮，而忽視了編程最本質的東西，掌握最基本最核心的編程能力，比如數據架構和演算法，設計，慣用法，培養技術的審美，也是很重要的，既要致高遠，又要盡精微。