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

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

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

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

看上面的需求不難發(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è)組件的介紹問(wèn)題及解決方案。

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

案例二：云捕需要在插入數(shù)據(jù)的時(shí)候根據(jù)數(shù)據(jù)類(lèi)型實(shí)時(shí)生成一個(gè)類(lèi)型，某日排查問(wèn)題發(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來(lái)實(shí)現(xiàn)分布式鎖后解決問(wèn)題，讀者也可以通過(guò)zookeeper來(lái)實(shí)現(xiàn),請(qǐng)自行g(shù)oogle；

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

    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.

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

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

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

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

分析

解決辦法:使用定制的實(shí)例,設(shè)定隊(duì)列長(zhǎng)度,及拒接策略,為了保證數(shù)據(jù)都能被完整處理,云捕使用的拒絕策略是處理不過(guò)來(lái)時(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ù)處理模塊再?gòu)腒afka集群中提取數(shù)據(jù)排隊(duì)處理.Tomcat三種運(yùn)行模式及使用場(chǎng)景:

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

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

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

Kafka篇：

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

調(diào)整為如下:

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

 解決方案：這個(gè)和kafka brocker設(shè)置有關(guān)，通過(guò)分析發(fā)現(xiàn)一部分上報(bào)的消息體過(guò)大，甚至達(dá)到2M，DBA專(zhuān)家這邊后臺(tái)也沒(méi)有查到任何異常，但是大量的消息發(fā)送失敗。通過(guò)反復(fù)Google后我得到一個(gè)信息：kafka消息體為10K的時(shí)候性能最佳，基于這個(gè)信息，讓DBA同學(xué)幫忙調(diào)整后臺(tái)限制batch的總大小限制，應(yīng)用程序中調(diào)整批量的大小，并拋棄一部分過(guò)大的消息體，調(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)重要,碰到的問(wèn)題也比較多,最近才解決了一個(gè)遺留的老大難問(wèn)題.由于15年的時(shí)候才接觸到redis,使用過(guò)程中姿勢(shì)存在比較大的問(wèn)題.在這里列舉下面幾個(gè)問(wèn)題:
案例一:CPU抖動(dòng),具體可以見(jiàn)DBA同學(xué)的文章 redis cpu 抖動(dòng)問(wèn)題分析  
redis-faina redis性能問(wèn)題診斷利器
案例二:主從不同步,redis內(nèi)存無(wú)法擴(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)營(yíng)經(jīng)驗(yàn)分享請(qǐng)?jiān)L問(wèn)網(wǎng)易云社區(qū)。
文章來(lái)源： 網(wǎng)易云社區(qū)