本文來源於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，帶來過載，可以降級服務，將部分使用者請求頻次低，價值低但是系統開銷不低的功能或者資料臨時阻斷停止響應，確保整體系統的穩定性；如微博過載暫停冷門訂閱，避免全域性崩潰； 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.異常的監控和跟蹤
異常比例不超過萬分之幾可以忽略，而千分之幾就要去研究了。 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的公眾號 參考文件： 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