摘要：從零開始設(shè)計(jì)開發(fā)一個(gè)日處理數(shù)據(jù)億的大數(shù)據(jù)高并發(fā)實(shí)時(shí)系統(tǒng)，哪些性能問題需要特別注意這里我們一起梳理一下本文中我將以，同學(xué)戲稱的系統(tǒng)網(wǎng)易云捕設(shè)計(jì)開發(fā)實(shí)踐中兩年的時(shí)間里碰到的真實(shí)問題，踩過的坑及解決問題的方法和大家一起討論如何解決這些問題。

本文由作者余寶虹授權(quán)網(wǎng)易云社區(qū)發(fā)布。

從零開始設(shè)計(jì)開發(fā)一個(gè)日處理數(shù)據(jù)8億的大數(shù)據(jù)高并發(fā)實(shí)時(shí)系統(tǒng)，哪些性能問題需要特別注意？這里我們一起梳理一下,本文中我將以PE，SA同學(xué)戲稱的DDOS系統(tǒng)—網(wǎng)易云捕設(shè)計(jì)開發(fā)實(shí)踐中兩年的時(shí)間里碰到的真實(shí)問題，踩過的坑及解決問題的方法和大家一起討論如何解決這些問題。文中不會(huì)大談特談架構(gòu)設(shè)計(jì)，只是會(huì)在提及問題出現(xiàn)的場(chǎng)景及解決方法時(shí)初略帶過，沒有場(chǎng)景的談架構(gòu)設(shè)計(jì)都是耍流氓。本文著重列舉在云捕業(yè)務(wù)場(chǎng)景下我們碰到的一系列性能問題以及解決問題的思路，幫助一部分有類似場(chǎng)景的人少走彎路，拋磚引玉，歡迎各路大神批評(píng)指正。
為了便于讀者輕松的理解后續(xù)的描述，有必要開始之前先熟悉云捕的業(yè)務(wù)場(chǎng)景，我這里簡(jiǎn)明扼要的介紹一下。
有統(tǒng)計(jì)顯示，Crash的出現(xiàn)比率非常高：63%的用戶碰到過移動(dòng)APP crash，在首次啟動(dòng)碰到crash時(shí)，21%的用戶會(huì)卸載App，另外，Crash發(fā)生在使用過程中，70%的用戶會(huì)給予差評(píng)。Crash已經(jīng)成為移動(dòng)App開發(fā)的最大障礙，App開發(fā)中進(jìn)行質(zhì)量跟蹤同樣有很多難以解決的問題：用戶投訴閃退，但卻無法重現(xiàn)；QA投入大量時(shí)間測(cè)試，還是無法解決各類crash問題；Android機(jī)型太多太雜；產(chǎn)品要求快速上線，搭建一個(gè)crash收集平臺(tái)耗時(shí)耗力；使用國外的產(chǎn)品，網(wǎng)絡(luò)不好，崩潰上報(bào)問題很大并且使用其它公司的產(chǎn)品，數(shù)據(jù)安全又難以保證。在此情況下，網(wǎng)易云捕應(yīng)運(yùn)而生了，使命就是為了助力移動(dòng)端的開發(fā)者打造高品質(zhì)APP，精準(zhǔn)捕捉APP的每一次質(zhì)量問題。
為了實(shí)現(xiàn)上述目的，在調(diào)研競(jìng)品后我們發(fā)現(xiàn)云捕需要實(shí)現(xiàn)以下功能：

 1 實(shí)時(shí)展示崩潰、異常、卡頓問題詳情，設(shè)備信息，崩潰卡頓分類；
 2 實(shí)時(shí)準(zhǔn)確統(tǒng)計(jì)分析各類崩潰、異常、卡頓問題次數(shù)、影響人數(shù)，啟動(dòng)人數(shù)，比率等多方位趨勢(shì)圖，實(shí)時(shí)報(bào)警讓用戶全面掌握產(chǎn)品質(zhì)量狀況 ；
 3 實(shí)時(shí)準(zhǔn)確統(tǒng)計(jì)今日問題統(tǒng)計(jì)，今日Top3實(shí)時(shí)展示24小時(shí)Top3問題統(tǒng)計(jì)排序；
 4 實(shí)時(shí)準(zhǔn)確統(tǒng)計(jì)每個(gè)崩潰累計(jì)的類型設(shè)備型號(hào)分布圖，系統(tǒng)版本分布圖；
 5 崩潰、卡頓堆棧實(shí)時(shí)自動(dòng)還原； 
 6 demo實(shí)時(shí)展示；
 7 解決方案實(shí)時(shí)推薦；
 8 用戶自助接入，前期不需要審核；

看上面的需求不難發(fā)現(xiàn)，有幾個(gè)關(guān)鍵詞大數(shù)據(jù)，高并發(fā)，實(shí)時(shí)，準(zhǔn)確。為了很好的實(shí)現(xiàn)這個(gè)需求便有了下面的架構(gòu)設(shè)計(jì)圖：
了解完業(yè)務(wù)場(chǎng)景，看完架構(gòu)設(shè)計(jì)圖，下面的例子就比較好理解了，為了系統(tǒng)性，下面一個(gè)個(gè)組件的介紹問題及解決方案。

DDB篇：
案例一：某周六，數(shù)據(jù)量急劇增加，收到哨兵報(bào)警：Cause: java.sql.SQLException: Get null from pool；
解決方案：首先通過命令show process或者show status查看鏈接數(shù)，檢查數(shù)據(jù)庫連接數(shù)設(shè)置及釋放正常后，問了其它同事也沒有碰到這個(gè)問題， 聯(lián)系DBA同學(xué)修改連接數(shù)后恢復(fù)正常。據(jù)DBA同學(xué)描述現(xiàn)在一個(gè)QS最大可支持1024個(gè)鏈接，可以通過增加QS的數(shù)量來提高鏈接；

案例二：云捕需要在插入數(shù)據(jù)的時(shí)候根據(jù)數(shù)據(jù)類型實(shí)時(shí)生成一個(gè)類型，某日排查問題發(fā)現(xiàn)插入的記錄條數(shù)和DDB節(jié)點(diǎn)數(shù)一致
解決方案：仔細(xì)查閱ddb文檔發(fā)現(xiàn)設(shè)置多節(jié)點(diǎn)ddb設(shè)置UNIQUE key插入不能保證唯一，只能在單節(jié)點(diǎn)的集群上保證唯一性。多節(jié)點(diǎn)集群需要業(yè)務(wù)方自己實(shí)現(xiàn)，利用redis提供的setnx來實(shí)現(xiàn)分布式鎖后解決問題，讀者也可以通過zookeeper來實(shí)現(xiàn),請(qǐng)自行g(shù)oogle；

案例三：數(shù)據(jù)插入延遲比較高
解決方案：1 請(qǐng)DBA同學(xué)升級(jí)DDB硬盤為SSD硬盤；

    2 批量插入替代單條插入，并且批量插入要控制好batch的數(shù)字否則會(huì)出現(xiàn)下面的異常；

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.

可以事先通過控制臺(tái)可以查到部分閾值，查不到的也可以聯(lián)系DBA同學(xué)確認(rèn)一下。

批量插入要控制batch的大小，確保參數(shù)個(gè)數(shù)和消息體大小都在合理的范圍內(nèi)

注意：數(shù)據(jù)庫的再提升性能，畢竟性能在哪里，能不經(jīng)過數(shù)據(jù)庫的就不過，能用緩存扛的就用緩存。往往總是策略來得更有效果，有時(shí)候優(yōu)化不下去了，我們是不是想想換一種思維方式，為了打開一個(gè)瓶子喝水，除了打開瓶子以為，還可以把塞子推進(jìn)去，換種思路有時(shí)候會(huì)海闊天空。

多線程篇：
場(chǎng)景：云捕有兩個(gè)對(duì)外的接口，分別用來接收十億臺(tái)左右的設(shè)備發(fā)上來的崩潰，卡頓，啟動(dòng)數(shù)據(jù)，并發(fā)非常大。
案例一：某日收到哨兵報(bào)警，內(nèi)存使用率100%，上服務(wù)器分析發(fā)現(xiàn)Java堆的eden區(qū)，survivor區(qū)，tenured區(qū) 全部堆滿，接口服務(wù)處于將近癱瘓的狀態(tài)，迅速dump文件后用mat分析發(fā)現(xiàn)隊(duì)列里面塞滿了對(duì)象，但是項(xiàng)目代碼里面沒有明顯的使用隊(duì)列。
最后通過排查發(fā)現(xiàn)是因?yàn)槭褂枚嗑€程時(shí)excutor 內(nèi)部使用了一個(gè)無界隊(duì)列，如果數(shù)據(jù)處理不夠快，大量的數(shù)據(jù)回堆積在內(nèi)存，導(dǎo)致內(nèi)存被撐爆,相關(guān)具體源代碼如下:

分析

解決辦法:使用定制的實(shí)例,設(shè)定隊(duì)列長(zhǎng)度,及拒接策略,為了保證數(shù)據(jù)都能被完整處理,云捕使用的拒絕策略是處理不過來時(shí)利用kafka的可堆積性重新扔回kafka中.

為了保證在重啟實(shí)例時(shí)數(shù)據(jù)不丟失,這里還需要注冊(cè)一個(gè)鉤子到JVM實(shí)現(xiàn)JVM退出前先把本地隊(duì)列中的數(shù)據(jù)消費(fèi)掉.

JVM和Tomcat篇：

 案例：報(bào)警項(xiàng):TomcatCollector,報(bào)警內(nèi)容:currentThreadsBusy數(shù): 2000,currentThreadsBusyMax數(shù):2000
 解決方案:Tomcat默認(rèn)使用BIO模式,調(diào)整為NIO模式.并調(diào)整代碼,加解密,預(yù)處理等等統(tǒng)一移到數(shù)據(jù)處理模塊,接口模塊只負(fù)責(zé)接收數(shù)據(jù),接收數(shù)據(jù)以后啥也不做,直接扔到Kafka集群中,數(shù)據(jù)處理模塊再從Kafka集群中提取數(shù)據(jù)排隊(duì)處理.Tomcat三種運(yùn)行模式及使用場(chǎng)景:

BIO： 同步并阻塞，服務(wù)器實(shí)現(xiàn)模式為一個(gè)連接一個(gè)線程，即客戶端有連接請(qǐng)求時(shí)服務(wù)器端就需要啟動(dòng)一個(gè)線程進(jìn)行處理，如果這個(gè)連接不做任何事情會(huì)造成不必要的線程開銷，當(dāng)然可以通過線程池機(jī)制改善,適用連接數(shù)較小且固定的架構(gòu)，這種方式對(duì)服務(wù)器資源要求比較高，并發(fā)局限于應(yīng)用中。。

NIO：同步非阻塞，服務(wù)器實(shí)現(xiàn)模式為一個(gè)請(qǐng)求一個(gè)線程，即客戶端發(fā)送的連接請(qǐng)求都會(huì)注冊(cè)到多路復(fù)用器上，多路復(fù)用器輪詢到連接有I/O請(qǐng)求時(shí)才啟動(dòng)一個(gè)線程進(jìn)行處理,適用于連接數(shù)目多且連接比較短（輕操作）的架構(gòu)，比如聊天服務(wù)器，并發(fā)局限于應(yīng)用中，編程比較復(fù)雜。

AIO：異步非阻塞，服務(wù)器實(shí)現(xiàn)模式為一個(gè)有效請(qǐng)求一個(gè)線程，客戶端的I/O請(qǐng)求都是由OS先完成了再通知服務(wù)器應(yīng)用去啟動(dòng)線程進(jìn)行處理適用于連接數(shù)目多且連接比較長(zhǎng)（重操作）的架構(gòu)，比如相冊(cè)服務(wù)器，充分調(diào)用OS參與并發(fā)操作，編程比較復(fù)雜。

Kafka篇：

 案例一： 數(shù)據(jù)大幅度增加后部分用戶反饋發(fā)送消息超時(shí)
 ![][6]

調(diào)整為如下:

  解決方案： kafka的QPS據(jù)說最大能達(dá)到百萬級(jí)別的QPS，但是經(jīng)排查問題就出在這里，同步改異步，kafka支持批量發(fā)送數(shù)據(jù)后問題解決。   
 案例二：kafka.common.FailedToSendMessageException: Failed to send messages after 3 tries.

 解決方案：這個(gè)和kafka brocker設(shè)置有關(guān)，通過分析發(fā)現(xiàn)一部分上報(bào)的消息體過大，甚至達(dá)到2M，DBA專家這邊后臺(tái)也沒有查到任何異常，但是大量的消息發(fā)送失敗。通過反復(fù)Google后我得到一個(gè)信息：kafka消息體為10K的時(shí)候性能最佳，基于這個(gè)信息，讓DBA同學(xué)幫忙調(diào)整后臺(tái)限制batch的總大小限制，應(yīng)用程序中調(diào)整批量的大小，并拋棄一部分過大的消息體，調(diào)整以后效果如下。

注意：另外要注意kafka的一個(gè)分區(qū)只能被一個(gè)節(jié)點(diǎn)消費(fèi)，請(qǐng)合理的設(shè)置kafka的節(jié)點(diǎn)數(shù)，當(dāng)節(jié)點(diǎn)數(shù)
Redis篇：
 redis在云捕系統(tǒng)的地位相當(dāng)重要,碰到的問題也比較多,最近才解決了一個(gè)遺留的老大難問題.由于15年的時(shí)候才接觸到redis,使用過程中姿勢(shì)存在比較大的問題.在這里列舉下面幾個(gè)問題:
案例一:CPU抖動(dòng),具體可以見DBA同學(xué)的文章 redis cpu 抖動(dòng)問題分析  
redis-faina redis性能問題診斷利器
案例二:主從不同步,redis內(nèi)存無法擴(kuò)容,內(nèi)存溢出; 

   改造后的效果如下:


ddb連接數(shù)限制：          ddb最大支持500個(gè)連接數(shù)
org.springframework.dao.InvalidDataAccessApiUsageException: READONLY You can"t write against a read only slave.; nested exception is redis.clients.jedis.exceptions.JedisDataException: READONLY You can"t write against a read only slave.

2 rows in set (0.01 sec)
免費(fèi)領(lǐng)取驗(yàn)證碼、內(nèi)容安全、短信發(fā)送、直播點(diǎn)播體驗(yàn)包及云服務(wù)器等套餐
更多網(wǎng)易技術(shù)、產(chǎn)品、運(yùn)營經(jīng)驗(yàn)分享請(qǐng)?jiān)L問網(wǎng)易云社區(qū)。
文章來源： 網(wǎng)易云社區(qū)