資訊專欄INFORMATION COLUMN
摘要：從零開始設計開發一個日處理數據億的大數據高并發實時系統，哪些性能問題需要特別注意這里我們一起梳理一下本文中我將以，同學戲稱的系統網易云捕設計開發實踐中兩年的時間里碰到的真實問題，踩過的坑及解決問題的方法和大家一起討論如何解決這些問題。
本文由作者余寶虹授權網易云社區發布。
從零開始設計開發一個日處理數據8億的大數據高并發實時系統，哪些性能問題需要特別注意？這里我們一起梳理一下,本文中我將以PE，SA同學戲稱的DDOS系統—網易云捕設計開發實踐中兩年的時間里碰到的真實問題，踩過的坑及解決問題的方法和大家一起討論如何解決這些問題。文中不會大談特談架構設計，只是會在提及問題出現的場景及解決方法時初略帶過，沒有場景的談架構設計都是耍流氓。本文著重列舉在云捕業務場景下我們碰到的一系列性能問題以及解決問題的思路，幫助一部分有類似場景的人少走彎路，拋磚引玉，歡迎各路大神批評指正。
為了便于讀者輕松的理解后續的描述，有必要開始之前先熟悉云捕的業務場景，我這里簡明扼要的介紹一下。
有統計顯示，Crash的出現比率非常高：63%的用戶碰到過移動APP crash，在首次啟動碰到crash時，21%的用戶會卸載App，另外，Crash發生在使用過程中，70%的用戶會給予差評。Crash已經成為移動App開發的最大障礙，App開發中進行質量跟蹤同樣有很多難以解決的問題：用戶投訴閃退，但卻無法重現；QA投入大量時間測試，還是無法解決各類crash問題；Android機型太多太雜；產品要求快速上線，搭建一個crash收集平臺耗時耗力；使用國外的產品，網絡不好，崩潰上報問題很大并且使用其它公司的產品，數據安全又難以保證。在此情況下，網易云捕應運而生了，使命就是為了助力移動端的開發者打造高品質APP，精準捕捉APP的每一次質量問題。
為了實現上述目的，在調研競品后我們發現云捕需要實現以下功能：
1 實時展示崩潰、異常、卡頓問題詳情，設備信息，崩潰卡頓分類； 2 實時準確統計分析各類崩潰、異常、卡頓問題次數、影響人數，啟動人數，比率等多方位趨勢圖，實時報警讓用戶全面掌握產品質量狀況 ； 3 實時準確統計今日問題統計，今日Top3實時展示24小時Top3問題統計排序； 4 實時準確統計每個崩潰累計的類型設備型號分布圖，系統版本分布圖； 5 崩潰、卡頓堆棧實時自動還原； 6 demo實時展示； 7 解決方案實時推薦； 8 用戶自助接入，前期不需要審核；
看上面的需求不難發現，有幾個關鍵詞大數據，高并發，實時，準確。為了很好的實現這個需求便有了下面的架構設計圖：
了解完業務場景，看完架構設計圖，下面的例子就比較好理解了，為了系統性，下面一個個組件的介紹問題及解決方案。
DDB篇：
案例一：某周六，數據量急劇增加，收到哨兵報警：Cause: java.sql.SQLException: Get null from pool；
解決方案：首先通過命令show process或者show status查看鏈接數，檢查數據庫連接數設置及釋放正常后，問了其它同事也沒有碰到這個問題， 聯系DBA同學修改連接數后恢復正常。據DBA同學描述現在一個QS最大可支持1024個鏈接，可以通過增加QS的數量來提高鏈接；
案例二：云捕需要在插入數據的時候根據數據類型實時生成一個類型，某日排查問題發現插入的記錄條數和DDB節點數一致
解決方案：仔細查閱ddb文檔發現設置多節點ddb設置UNIQUE key插入不能保證唯一，只能在單節點的集群上保證唯一性。多節點集群需要業務方自己實現，利用redis提供的setnx來實現分布式鎖后解決問題，讀者也可以通過zookeeper來實現,請自行google；
案例三：數據插入延遲比較高
解決方案：1 請DBA同學升級DDB硬盤為SSD硬盤；
2 批量插入替代單條插入，并且批量插入要控制好batch的數字否則會出現下面的異常；
Cause: java.sql.SQLException: condition number is: 1124, exceed max value:1024 或者Cause: com.mysql.jdbc.PacketTooBigException: Packet for query is too large (26124567 > 16777216). You can change this value on the server by setting the max_allowed_packet" variable.
可以事先通過控制臺可以查到部分閾值，查不到的也可以聯系DBA同學確認一下。
批量插入要控制batch的大小，確保參數個數和消息體大小都在合理的范圍內
注意：數據庫的再提升性能，畢竟性能在哪里，能不經過數據庫的就不過，能用緩存扛的就用緩存。往往總是策略來得更有效果，有時候優化不下去了，我們是不是想想換一種思維方式，為了打開一個瓶子喝水，除了打開瓶子以為，還可以把塞子推進去，換種思路有時候會海闊天空。
多線程篇：
場景：云捕有兩個對外的接口，分別用來接收十億臺左右的設備發上來的崩潰，卡頓，啟動數據，并發非常大。
案例一：某日收到哨兵報警，內存使用率100%，上服務器分析發現Java堆的eden區，survivor區，tenured區 全部堆滿，接口服務處于將近癱瘓的狀態，迅速dump文件后用mat分析發現隊列里面塞滿了對象，但是項目代碼里面沒有明顯的使用隊列。
最后通過排查發現是因為使用多線程時excutor 內部使用了一個無界隊列，如果數據處理不夠快，大量的數據回堆積在內存，導致內存被撐爆,相關具體源代碼如下:
分析
解決辦法:使用定制的實例,設定隊列長度,及拒接策略,為了保證數據都能被完整處理,云捕使用的拒絕策略是處理不過來時利用kafka的可堆積性重新扔回kafka中.
為了保證在重啟實例時數據不丟失,這里還需要注冊一個鉤子到JVM實現JVM退出前先把本地隊列中的數據消費掉.
JVM和Tomcat篇：
案例：報警項:TomcatCollector,報警內容:currentThreadsBusy數: 2000,currentThreadsBusyMax數:2000 解決方案:Tomcat默認使用BIO模式,調整為NIO模式.并調整代碼,加解密,預處理等等統一移到數據處理模塊,接口模塊只負責接收數據,接收數據以后啥也不做,直接扔到Kafka集群中,數據處理模塊再從Kafka集群中提取數據排隊處理.Tomcat三種運行模式及使用場景:
BIO： 同步并阻塞，服務器實現模式為一個連接一個線程，即客戶端有連接請求時服務器端就需要啟動一個線程進行處理，如果這個連接不做任何事情會造成不必要的線程開銷，當然可以通過線程池機制改善,適用連接數較小且固定的架構，這種方式對服務器資源要求比較高，并發局限于應用中。。
NIO：同步非阻塞，服務器實現模式為一個請求一個線程，即客戶端發送的連接請求都會注冊到多路復用器上，多路復用器輪詢到連接有I/O請求時才啟動一個線程進行處理,適用于連接數目多且連接比較短（輕操作）的架構，比如聊天服務器，并發局限于應用中，編程比較復雜。
AIO：異步非阻塞，服務器實現模式為一個有效請求一個線程，客戶端的I/O請求都是由OS先完成了再通知服務器應用去啟動線程進行處理適用于連接數目多且連接比較長（重操作）的架構，比如相冊服務器，充分調用OS參與并發操作，編程比較復雜。
Kafka篇：
案例一： 數據大幅度增加后部分用戶反饋發送消息超時 ![][6]
調整為如下:
解決方案： kafka的QPS據說最大能達到百萬級別的QPS，但是經排查問題就出在這里，同步改異步，kafka支持批量發送數據后問題解決。 案例二：kafka.common.FailedToSendMessageException: Failed to send messages after 3 tries.
解決方案：這個和kafka brocker設置有關，通過分析發現一部分上報的消息體過大，甚至達到2M，DBA專家這邊后臺也沒有查到任何異常，但是大量的消息發送失敗。通過反復Google后我得到一個信息：kafka消息體為10K的時候性能最佳，基于這個信息，讓DBA同學幫忙調整后臺限制batch的總大小限制，應用程序中調整批量的大小，并拋棄一部分過大的消息體，調整以后效果如下。
