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

2.web服務(wù)器： 2.1web日志：打開執(zhí)行時(shí)間監(jiān)控，分析不同動(dòng)態(tài)腳本執(zhí)行頻次及時(shí)間分布，找到時(shí)間長(zhǎng)、頻次高的； 2.2針對(duì)時(shí)間長(zhǎng)、頻次高的程序做埋點(diǎn)分析； 2.3SQL查詢輸出：調(diào)用匯總函數(shù)，分析每秒查詢請(qǐng)求、最多查詢表及SQL、是否同一主鍵大量重復(fù)查詢； 2.4錯(cuò)誤異常日志分析，極大警覺，發(fā)現(xiàn)SQL注入猜測(cè)； 2.5鏈接狀態(tài)監(jiān)控：當(dāng)前web鏈接及消耗的資源，避免請(qǐng)求調(diào)用復(fù)雜框架形成雪崩。
3.內(nèi)存、緩存服務(wù)器： 3.1鏈接狀態(tài)和資源監(jiān)控； 3.2命中率監(jiān)控，命中率不高是設(shè)計(jì)問(wèn)題，浪費(fèi)資源。
4.通用監(jiān)控：內(nèi)存、CPU、磁盤、SWAP、系統(tǒng)資源(最大文件打開數(shù)、最大文件句柄數(shù)、syn連接數(shù))占用監(jiān)控。 5.自恢復(fù)系統(tǒng)：對(duì)技術(shù)不成熟、業(yè)務(wù)發(fā)展迅速平臺(tái)是特別重要的處理思路，較低成本完成可靠服務(wù)，但是后續(xù)也要有跟進(jìn)方案，進(jìn)程為什么阻塞(數(shù)據(jù)庫(kù)鏈接多、webserver鏈接過(guò)多，crontab清理阻塞的)。 6.監(jiān)控系統(tǒng)資源占用：高負(fù)載盡量不要用netstat?-an;埋點(diǎn)分析隨機(jī)值抽取;定位到/dev/shm用內(nèi)存而不是物理IO。 附上總結(jié)圖片，圖形化知識(shí)點(diǎn)，加深理解，祝各位走上自己的"成金之路"。 caoz的公眾號(hào) 參考文檔： 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大神多年经验总结分享...的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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