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