本文來源于caoz夢囈公眾號高并發(fā)專輯，以圖形化、松耦合的方式，對互聯(lián)網(wǎng)高并發(fā)問題做了詳細解讀與分析，“技術(shù)在短期內(nèi)被高估，而在長期中又被低估”，而不同的場景和人員成本又導致了巨頭的方案可能并不適合創(chuàng)業(yè)公司，那么如何保證高并發(fā)問題不成為創(chuàng)業(yè)路上的攔路虎，是每一個全棧工程師、資深系統(tǒng)工程師、有理想的程序員必備的技能，希望本文助您尋找屬于自己的“成金之路”，發(fā)亮發(fā)光。 目錄： 場景及解決方法解讀 認識負載 數(shù)據(jù)跟蹤 腦圖、caoz大神公眾號分享 參考資料 秉承知其然及其所以然的思路，以撥蟬拔絲的思維，一一解讀各個技巧的使用場景： a.網(wǎng)絡(luò)通道+前臺控制 原因：在當前浮躁社會的大前提下，用戶點擊一個按鈕如果3s內(nèi)沒有反應，基本都會再次刷新，那么因為你網(wǎng)絡(luò)通道不順，原本可以正常得到數(shù)據(jù)，現(xiàn)在卻因為延遲造成后臺請求量倍增；而當用戶因為沒有數(shù)據(jù)而瘋狂刷新時，你應該在前臺有控制，比如“3秒間隔才能重新點擊一個按鈕、或者讓用戶可以瘋狂點但是不發(fā)送請求（好像360曾經(jīng)做過這個）”，控制用戶不良操作。 方案：后臺必須支持雙網(wǎng)雙通，保證南電信、北網(wǎng)通雙邊部署，玩過對戰(zhàn)游戲的同學，應該都還記得，當初都是分電信專區(qū)和網(wǎng)通專區(qū)；同時在成本可以接受的范圍內(nèi)，盡量上CDN加速。 b.負載均衡 這個無須多說，但是科普下技術(shù)原理，主要難點是環(huán)上節(jié)點分布均衡與節(jié)點處理請求數(shù)均衡： 使用一致性Hash，全滿狀態(tài)時是長度為2^32(由Hash函數(shù)返回值類型決定)的環(huán)，服務(wù)器節(jié)點按名稱Hash值放到環(huán)中，Web請求分配時根據(jù)IP?Hash或者URL Hash值，路由到在環(huán)中距離最近的服務(wù)器上，進行請求應答。 1.服務(wù)器Hash值環(huán)用紅黑樹存儲，且需要用CRC32_HASH、FNV1_32_HASH、KETAMA_HASH保證服務(wù)器Hash值均勻分布在0到2^32之間，java.util.String的hashCode()則不行；? 2.為保證單臺服務(wù)器上處理請求數(shù)的均衡性，則需要將一個物理服務(wù)器虛擬為n個虛擬節(jié)點(172.16.6.1:1\172.16.6.1:2...)，對所有的虛擬節(jié)點構(gòu)造環(huán)，以將一個實點拆為多個均勻分布代理點的方式，來保證請求分配的均衡性。 c.緩存、數(shù)據(jù)庫、數(shù)據(jù)總線同步異步處理： 1.緩存 其起源于CPU與Memory Bank數(shù)據(jù)高速處理，將熱數(shù)據(jù)保存進LRU隊列中，提高CPU處理速度； 而此處的緩存則是對數(shù)據(jù)庫中高頻、小字段進行緩存，保證50%的命中率才值得緩存IO開銷。 2.數(shù)據(jù)庫 i.單表 查詢慢時，基本由于過濾條件太多造成，使用聯(lián)合索引加速過濾。索引使用樹形結(jié)構(gòu)，時間復雜度大概為lgN，log(10億)=9，查詢10億數(shù)據(jù)只需9次單位操作時間，如果索引使用不上，則得先把所有數(shù)據(jù)查詢出來，然后放到內(nèi)存里，內(nèi)存放不下，還得部分存儲到磁盤里，最后再進行過濾。 另外，控制單次查詢數(shù)據(jù)條數(shù)，從源頭上進行流量控制，和地鐵限流一個套路；另外，超級大的分頁也不用考慮，Google、baidu、taobao搜索結(jié)果都沒有超過100頁的。 ii.多表關(guān)聯(lián)表查詢太慢 參見MySQL百萬級、千萬級數(shù)據(jù)多表關(guān)聯(lián)SQL語句調(diào)優(yōu)詳細的對多表關(guān)聯(lián)的索引使用進行了分析。 iii.海量數(shù)據(jù) 此業(yè)務(wù)邏輯只能用單表處理，比如用戶表登陸狀態(tài)表、游戲操作記錄表。 另，還可進行分表、分庫，這塊比較復雜，請自行參考參考資料a。 3.數(shù)據(jù)總線同步、異步處理： 這里說數(shù)據(jù)總線，因為目前數(shù)據(jù)處理基本都是松耦合，以消息驅(qū)動，如京東用的kafka、超級靈活性的Rabbitmq、淘寶的metaq： 如果是非核心的非實時性業(yè)務(wù)，比如排名與PageView數(shù)、lastact，可以定時驅(qū)動更新緩存隊列：對于排名與PageView數(shù)，，匯總隊列中所有消息，統(tǒng)一更新處理；對于lastact，則取最新的狀態(tài)，進行更新即可； 同步實時處理時，盡可能的合并操作邏輯，多個操作一條SQL更新(基于同一主鍵查詢、更新的比例多)。 c.從需求層面裁剪 一款好的產(chǎn)品必定讓一部分尖叫，另一部分離開的產(chǎn)品；那么在需求層面進行裁剪，以較低的成本滿足絕大多數(shù)人的使用，是非常合適的。 1.搜索大翻頁的問題，百度、淘寶、Google查詢結(jié)果限定在100頁內(nèi)，來避免使用count(1)計算總條數(shù)；
2.雪崩效應處理：緩存扛不住將負載傳遞給DB，帶來過載，可以降級服務(wù)，將部分用戶請求頻次低，價值低但是系統(tǒng)開銷不低的功能或者數(shù)據(jù)臨時阻斷停止響應，確保整體系統(tǒng)的穩(wěn)定性；如微博過載暫停冷門訂閱，避免全局崩潰； 3.寫主庫、讀從庫的"主從庫數(shù)據(jù)同步問題"，提示用戶延遲處理(操作完后后，提示3s自動返回)，體驗略有不好也不會有非常大的困擾。 解決高并發(fā)要有思維寬度，能功能、使用、設(shè)計、數(shù)據(jù)庫、緩存、OS各個層面去思考及其解決方法，深入的剖析的各個場景；同時針對高并發(fā)也要有一定的技術(shù)深度，比如nio、epoll、java.util.concurrent包各類高效鎖、無鎖操作，具備解決高并發(fā)的技術(shù)深度；但是離“成金之路”還有兩個重要的點——高負載怎么定義及跟蹤 a.定義： 1.構(gòu)成：?CPU/內(nèi)存開銷，都有哪些進程和服務(wù)占用，SWAP分區(qū)大，IO必然低；?IO開銷，服務(wù)讀寫頻率；
2.增長趨勢?線性增加、指數(shù)增加(無索引遍歷)、收斂增加(支撐性最好)；
3.系統(tǒng)閥值(CPU/IO/Mem不高但是請求一次)請求超越了OS閥值：如syn-flood連接占滿，https超時太長導致https超過最大值；mysql鏈接越界；
4.峰谷的規(guī)律和預測?原因分析；
5.異常的監(jiān)控和跟蹤?異常比例不超過萬分之幾可以忽略，而千分之幾就要去研究了。 b.跟蹤 1.數(shù)據(jù)服務(wù)器： 1.1每分鐘cron記錄CPU監(jiān)控，連接超過閥值256時記錄，不用root用戶(root用戶比普通用戶多一個連接，連接占滿時用此鏈接進行排錯)； 1.2binlog分析：寫入更新的日志，復制到線下機器mysqldump分析：每秒數(shù)據(jù)更新請求、更新請求最多的表、最多更新請求SQL格式、短時間大量重復主鍵更新； 1.3慢查詢?nèi)罩痉治?#xff0c;explain

2.web服務(wù)器： 2.1web日志：打開執(zhí)行時間監(jiān)控，分析不同動態(tài)腳本執(zhí)行頻次及時間分布，找到時間長、頻次高的； 2.2針對時間長、頻次高的程序做埋點分析； 2.3SQL查詢輸出：調(diào)用匯總函數(shù)，分析每秒查詢請求、最多查詢表及SQL、是否同一主鍵大量重復查詢； 2.4錯誤異常日志分析，極大警覺，發(fā)現(xiàn)SQL注入猜測； 2.5鏈接狀態(tài)監(jiān)控：當前web鏈接及消耗的資源，避免請求調(diào)用復雜框架形成雪崩。
3.內(nèi)存、緩存服務(wù)器： 3.1鏈接狀態(tài)和資源監(jiān)控； 3.2命中率監(jiān)控，命中率不高是設(shè)計問題，浪費資源。
4.通用監(jiān)控：內(nèi)存、CPU、磁盤、SWAP、系統(tǒng)資源(最大文件打開數(shù)、最大文件句柄數(shù)、syn連接數(shù))占用監(jiān)控。 5.自恢復系統(tǒng)：對技術(shù)不成熟、業(yè)務(wù)發(fā)展迅速平臺是特別重要的處理思路，較低成本完成可靠服務(wù)，但是后續(xù)也要有跟進方案，進程為什么阻塞(數(shù)據(jù)庫鏈接多、webserver鏈接過多，crontab清理阻塞的)。 6.監(jiān)控系統(tǒng)資源占用：高負載盡量不要用netstat?-an;埋點分析隨機值抽取;定位到/dev/shm用內(nèi)存而不是物理IO。 附上總結(jié)圖片，圖形化知識點，加深理解，祝各位走上自己的"成金之路"。 caoz的公眾號 參考文檔： a.http://mp.weixin.qq.com/s__biz=MzI0MjA1Mjg2Ng==&mid=401465959&idx=1&sn=8d2116f8d238ccd208160d23f44dbb2c&mpshare=1&scene=1&srcid=0303IcaeoLiMDrg0FZuBZCjG#rd? b.http://www.cnblogs.com/xrq730/p/5186728.html? c.https://yq.aliyun.com/articles/59701? d.http://www.cnblogs.com/uttu/archive/2013/02/07/2908685.html?

轉(zhuǎn)載于:https://www.cnblogs.com/uttu/p/6513918.html

總結(jié)

以上是生活随笔為你收集整理的每一个程序员都应该知道的高并发处理技巧、创业公司如何解决高并发问题、互联网高并发问题解决思路、caoz大神多年经验总结分享...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。