JavaScript 混淆及反混淆代碼工具
介紹在我們開始學(xué)習(xí)反混淆之前，我們首先要了解一下代碼混淆。如果不了解代碼是如何混淆的，我們可能無法成功對(duì)代碼進(jìn)行反混淆，尤其是使用自定義混淆器對(duì)其進(jìn)行混淆時(shí)。什么是混
先說明下RocketMQ版本， 4.6.0的老版本了。
線下環(huán)境客戶端啟動(dòng)會(huì)頻繁報(bào)錯(cuò)響應(yīng)超時(shí)，導(dǎo)致consumer實(shí)例化失敗，無法啟動(dòng)應(yīng)用。
圖片
確認(rèn)線下環(huán)境RocketMQ集群流量、生產(chǎn)消費(fèi)數(shù)量無異常。
集群gc次數(shù)不多，但是耗時(shí)高。（原本監(jiān)控看板異常數(shù)據(jù)缺失，所以少了前面一段）
圖片
master節(jié)點(diǎn)cpu使用率、load極高。
圖片
升配，4c8g升級(jí)8c32g，擴(kuò)大jvm內(nèi)存。
系統(tǒng)指標(biāo)略有下降，但是客戶端異常沒有明顯改善。
只能進(jìn)一步排查根因，還得上arthas。
thread -n 3查看cpu高的線程在做什么。
發(fā)現(xiàn)兩個(gè)異常線程。
1）一個(gè)線程在執(zhí)行AdminBrokerProcessor.queryTopicConsumerByWho()。
圖片
這個(gè)是查詢Topic的conusmerGroup信息。
比較奇怪的是，這個(gè)請(qǐng)求很頻繁，后來發(fā)現(xiàn)是控制臺(tái)應(yīng)用dashboard有個(gè)定時(shí)任務(wù)，30s查詢一次。
這個(gè)請(qǐng)求的耗時(shí)主要是在數(shù)組的遍歷處理上，說明內(nèi)存中的數(shù)據(jù)非常大。
圖片
而這個(gè)源碼中的offsetTable，就是RocketMQ中保存consumerGroup位點(diǎn)信息的對(duì)象。它的key是topic@group拼接的。
圖片
先臨時(shí)處理，把dashboard應(yīng)用關(guān)閉了，減少請(qǐng)求。但是效果并不明顯。
2）另一個(gè)線程在執(zhí)行定時(shí)任務(wù)ConsumerOffsetManager.persist()。
（線程調(diào)用信息忘記截圖了）
這個(gè)是RocketMQ集群持久化consumerGroup的offset信息的定時(shí)任務(wù)。
圖片
會(huì)將整個(gè)內(nèi)存對(duì)象轉(zhuǎn)化為jsonString寫入磁盤文件中。
這個(gè)內(nèi)存對(duì)象就是前面提到的offsetTable，就是RocketMQ中保存consumerGroup位點(diǎn)信息的對(duì)象。
這里消耗資源多，還是說明我們的內(nèi)存對(duì)象非常大。
因?yàn)槭蔷€下環(huán)境，可靠性要求不高。所以先臨時(shí)處理，把定時(shí)任務(wù)默認(rèn)配置5s改成50s，減少持久化次數(shù)。
效果顯著，機(jī)器cpu、負(fù)載都明顯改善。
好了，現(xiàn)在問題的矛頭都指向了這個(gè)offsetTable，那它到底有多大，為什么這么大？
大對(duì)象的定位，一般來說需要dump看看，不過這個(gè)對(duì)象有點(diǎn)特殊，剛剛也提到了它會(huì)被持久化到文件中，所以直接看文件大小和內(nèi)容就行了。
持久化文件的配置路徑，可以看下啟動(dòng)的conf.properties
storePathRootDir=/usr/local/rocketmq/store1storePathCommitLog=/usr/local/rocketmq/store1/commitlogstorePathConsumerQueue=/usr/local/rocketmq/store1/consumequeuestorePathIndex=/usr/local/rocketmq/store1/index在/usr/local/rocketmq/store1目錄下找到config文件夾的consummerOffset.json文件，44M，amazing~
對(duì)一個(gè)幾十M的對(duì)象頻繁序列化和持久化，加上內(nèi)網(wǎng)磁盤比較差，難怪負(fù)載如此高。
圖片
（這里截圖是當(dāng)時(shí)應(yīng)急時(shí)備份的文件，新的文件目前是414K）
為什么這個(gè)內(nèi)存對(duì)象這么大呢？
查看了下文件內(nèi)容，是RocketMQ中保存consumerGroup位點(diǎn)信息的對(duì)象，它的key是topic@group拼接的。
我們發(fā)現(xiàn)大量奇怪的consumerGroup name，跟一個(gè)topic聯(lián)合產(chǎn)生了幾千個(gè)key。
查看了下內(nèi)部封裝的客戶端代碼，找到了罪魁禍?zhǔn)住?span style="display:none">14928資訊網(wǎng)——每日最新資訊28at.com
圖片
線下環(huán)境會(huì)根據(jù)小環(huán)境（比如自己起的測(cè)試、單測(cè)環(huán)境、CI測(cè)試環(huán)境等）拼接一個(gè)獨(dú)立的consumerGroup name。
在線下，每次CI的測(cè)試環(huán)境名字會(huì)變化，所以導(dǎo)致consumerGroup name數(shù)量急劇膨脹。
問題找到了，直接的解決方式是刪除文件中無用的consumerGroup name，重啟broker進(jìn)行加載。
由于是線下環(huán)境，不需要擔(dān)心位點(diǎn)丟失的問題，同時(shí)當(dāng)客戶端請(qǐng)求時(shí)會(huì)自動(dòng)創(chuàng)建新的位點(diǎn)信息，所以可以考慮直接刪除。
圖片
先停止broker進(jìn)程（否則會(huì)自動(dòng)落盤內(nèi)存數(shù)據(jù)，創(chuàng)建新的文件），然后重命名相關(guān)文件（用于備份回滾），重新啟動(dòng)broker進(jìn)程，讀取空文件加載空對(duì)象。
重啟后，各個(gè)客戶端在請(qǐng)求集群時(shí)，會(huì)自動(dòng)創(chuàng)建訂閱關(guān)系和消費(fèi)位點(diǎn)記錄，負(fù)載略有升高，然后就恢復(fù)到較低的負(fù)載水位了。
24h的監(jiān)控顯示，優(yōu)化效果顯著，整個(gè)機(jī)器負(fù)載降低，請(qǐng)求讀寫耗時(shí)也顯著降低。
圖片
注意：保存訂閱關(guān)系的subscriptionGroup.json也存在同樣consumerGroup過多導(dǎo)致膨脹的問題，同樣的原因和優(yōu)化方式。默認(rèn)訂閱關(guān)系也是會(huì)自動(dòng)創(chuàng)建的。這里就不展開贅述了。
如果類似的問題出在線上怎么辦？
事后來看，類似問題是能夠提前避免的，主要考慮兩個(gè)措施：
本文鏈接：http://www.tebozhan.com/showinfo-26-67353-0.html消費(fèi)者太多！RocketMQ又炸了！
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)