海量數據 限定 微博 https 2.3 tst 日誌分析 如何 ive

目錄： 場景及解決方法解讀 認識負載 數據跟蹤 腦圖、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大神多年經驗總結分享