［吳慶祥 凌?。?/p>

1 引言

隨著大數(shù)據(jù)及云計(jì)算相關(guān)技術(shù)的發(fā)展，語音及短信詐騙的手段層出不窮，全民反詐已是當(dāng)今社會(huì)發(fā)展的共識(shí)。為了更好地保障用戶語音、短信業(yè)務(wù)個(gè)人信息安全，保障個(gè)人財(cái)產(chǎn)不受非法侵害，廣東電信部署了一套防詐騙系統(tǒng)，該系統(tǒng)部署相關(guān)的攔截策略，根據(jù)策略實(shí)施號(hào)碼攔截、閃信提醒等功能，一方面將詐騙號(hào)碼列黑限制使用，一方面針對(duì)嫌疑號(hào)碼設(shè)置短消息提醒功能[1]，業(yè)務(wù)號(hào)碼及短消息限制的雙重舉措不僅可以確保反詐策略實(shí)施的高可靠性，更能很好的體現(xiàn)網(wǎng)絡(luò)服務(wù)的可感知性。

2 原因分析

2.1 系統(tǒng)結(jié)構(gòu)

防詐系統(tǒng)硬件部署包括DELL 服務(wù)器、交換機(jī)、防火墻，服務(wù)器連接到交換機(jī)上，實(shí)現(xiàn)二層互通，防火墻做為整套系統(tǒng)的統(tǒng)一出口；軟件部署方面，系統(tǒng)搭建了hadoop集群，mysql 數(shù)據(jù)庫、采集接口程序、web 服務(wù)等組件。根據(jù)業(yè)務(wù)特性在系統(tǒng)上部署相關(guān)的攔截策略，滿足業(yè)務(wù)不斷發(fā)展的需要。

2.2 原理分析

攔截策略是根據(jù)日常反詐需求制定的實(shí)施手段，該策略通過Hadoop 集群發(fā)布至多個(gè)主機(jī)，GC（Garbage Collection，jvm 垃圾回收）為Hadoop 集群進(jìn)行jvm 垃圾回收回收的基礎(chǔ)設(shè)施[2]，GC 的存在保證整個(gè)集群運(yùn)行的穩(wěn)定，一般策略部署完成需要35分鐘左右，基本原理如圖1所示。

圖1 策略部署原理圖

攔截策略正常部署的前提是Hadoop 集群運(yùn)行正常，Hadoop 集群由多個(gè)節(jié)點(diǎn)組成，每個(gè)節(jié)點(diǎn)上運(yùn)行著多個(gè)組件角色以及數(shù)據(jù)處理任務(wù)，集群下聯(lián)多個(gè)主機(jī)，當(dāng)前網(wǎng)絡(luò)現(xiàn)狀一般是上百個(gè)主機(jī)。由于業(yè)務(wù)量增加，集群的數(shù)據(jù)量也在不斷增加，當(dāng)集群數(shù)據(jù)量達(dá)到一定規(guī)模后，GC 的配置將無法滿足集群的業(yè)務(wù)需求[2,3]，導(dǎo)致集群出現(xiàn)了多個(gè)問題，包括任務(wù)執(zhí)行緩慢、組件角色異常等，輕則集群變慢，重則集群服務(wù)不可用。

2.3 根因分析

目前在日常網(wǎng)絡(luò)巡檢過程在發(fā)現(xiàn)攔截策略部署耗時(shí)超過35 分鐘，有時(shí)甚至耗時(shí)超過55 分鐘，嚴(yán)重影響日常反詐攔截及指標(biāo)考核工作需求，如圖2 所示。

圖2 攔截策略耗時(shí)

進(jìn)一步在后臺(tái)進(jìn)行分析，發(fā)現(xiàn)集群業(yè)務(wù)程序在高峰時(shí)段里執(zhí)行耗時(shí)異常告警，時(shí)長超過指標(biāo)閾值等異常事件，在管理界面監(jiān)控發(fā)現(xiàn)異常事件是因集群部分主機(jī)存在策略分發(fā)及部署延遲導(dǎo)致，因主機(jī)出現(xiàn)部署異常存在隨機(jī)性，排除主機(jī)問題導(dǎo)致異常，然后針對(duì)GC 參數(shù)進(jìn)行排查，發(fā)現(xiàn)集群中存在名為“NodeManager 的Java 堆棧大?。ㄗ止?jié)）”的參數(shù)默認(rèn)設(shè)置為1GB，而現(xiàn)在的運(yùn)行閾值已遠(yuǎn)超1GB，導(dǎo)致了任務(wù)執(zhí)行出現(xiàn)緩慢、從而導(dǎo)致集群角色部署策略異常，根因分析流程如圖3 所示。

圖3 根因分析

3 方案設(shè)計(jì)

方案在設(shè)計(jì)與實(shí)施過程中以現(xiàn)網(wǎng)運(yùn)行穩(wěn)定為基準(zhǔn)，主要從垃圾回收方式對(duì)系統(tǒng)的影響程度、參數(shù)設(shè)置合理性、堆棧內(nèi)存大小設(shè)置對(duì)集群的穩(wěn)定性三方面考量，從現(xiàn)階段節(jié)點(diǎn)資源、業(yè)務(wù)需求和性能優(yōu)化等關(guān)鍵因素出發(fā)，主要目的是為了更好地滿足業(yè)務(wù)需求。

3.1 關(guān)鍵技術(shù)

（1）GC

GC 是指Java 程序本身發(fā)現(xiàn)并收集無用的內(nèi)存。它是一種自動(dòng)內(nèi)存管理形式，不需要程序員釋放內(nèi)存，Java 中出于對(duì)安全性考慮、減少內(nèi)存泄露、減少程序員工作量而設(shè)定了GC 機(jī)制。當(dāng)代主流虛擬機(jī)（Hotspot VM）的垃圾回收都采用“分代回收”的算法?！胺执厥铡笔轻槍?duì)不同生命周期的對(duì)象可以采取不同的回收方式，以便提高回收效率。如圖4 所示，JVM 內(nèi)存主要由新生代、老年代、永久代構(gòu)成[3]。

圖4 JVN 內(nèi)存構(gòu)成

大多數(shù)對(duì)象在新生代中被創(chuàng)建，新生代內(nèi)又分3 個(gè)區(qū)：一個(gè)Eden 區(qū)，兩個(gè)Survivor 區(qū)（一般而言），大部分對(duì)象在Eden 區(qū)中生成，當(dāng)Eden 區(qū)滿時(shí)，還存活的對(duì)象將被復(fù)制到兩個(gè)Survivor 區(qū)，在新生代中經(jīng)歷了N 次垃圾回收后仍然存活的對(duì)象，就會(huì)被放到老年代，永久代主要要存放元數(shù)據(jù)，例如Class、Method 的元信息，與垃圾回收要回收的Java 對(duì)象關(guān)系不大[3,4]。相對(duì)于新生代和老年代來說，該區(qū)域的劃分對(duì)垃圾回收影響比較小[3,5]。

（2）參數(shù)設(shè)置

對(duì)于GC 頻繁以及延遲的問題，需要通過收集GC 信息，結(jié)合系統(tǒng)需求，確定整改方案，然后選用合適的GC回收器、重新設(shè)置內(nèi)存比例、調(diào)整JVM 參數(shù)等方法進(jìn)行優(yōu)化。

由于Hadoop 中的NodeManager 角色是一個(gè)非常重要的組件，它負(fù)責(zé)管理集群中的節(jié)點(diǎn)資源，包括內(nèi)存、CPU、磁盤等。其中，堆棧內(nèi)存大小是影響NodeManager性能的一個(gè)重要因素[3]。所以針對(duì)NodeManager 角色的堆棧內(nèi)存大小的調(diào)整需要進(jìn)行合理的思考和優(yōu)化[4]。集群中Java 堆棧大?。ㄗ止?jié)）的參數(shù)設(shè)置如圖5 所示。

圖5 堆棧大小設(shè)置

（3）堆棧內(nèi)存設(shè)置

堆棧內(nèi)存是指Java 虛擬機(jī)中用于存儲(chǔ)對(duì)象的一塊內(nèi)存區(qū)域，它的大小取決于JVM 的參數(shù)配置。在Hadoop 中，NodeManager 的堆棧內(nèi)存大小會(huì)影響到NodeManager 的性能，因此需要進(jìn)行合理的配置和調(diào)整。在現(xiàn)網(wǎng)業(yè)務(wù)部署時(shí)主要從兩個(gè)方面考慮。

節(jié)點(diǎn)資源：在調(diào)整NodeManager 的堆棧內(nèi)存大小時(shí)，需要考慮節(jié)點(diǎn)的實(shí)際資源情況，包括內(nèi)存、CPU、磁盤等。如果節(jié)點(diǎn)的內(nèi)存資源很少，那么堆棧內(nèi)存的大小就需要適當(dāng)調(diào)小，否則會(huì)影響到NodeManager 的性能。

業(yè)務(wù)需求：在調(diào)整NodeManager 的堆棧內(nèi)存大小時(shí)，還需要根據(jù)業(yè)務(wù)需求進(jìn)行調(diào)整。如果業(yè)務(wù)需要更高的并發(fā)性和處理速度，那么可以適當(dāng)增加NodeManager 的堆棧內(nèi)存大小，以提高其性能。但是需要注意，堆棧內(nèi)存的大小不能無限制地增加，否則會(huì)影響到集群的穩(wěn)定性。

在調(diào)整NodeManager 的堆棧內(nèi)存大小后，需要進(jìn)行性能測(cè)試和優(yōu)化，以確保NodeManager 的性能和穩(wěn)定性。例如，可以使用Hadoop 自帶的性能測(cè)試工具，對(duì)Node-Manager 的性能進(jìn)行測(cè)試和優(yōu)化，提高其效率和穩(wěn)定性。

3.2 方案制定

本方案目的是通過巡檢以及風(fēng)險(xiǎn)管控，提前識(shí)別出集群存在NodeManager 角色的GC 延遲可能引起任務(wù)執(zhí)行延遲，導(dǎo)致業(yè)務(wù)指標(biāo)受影響的風(fēng)險(xiǎn)點(diǎn)，實(shí)施大數(shù)據(jù)集群（Yarn集群）關(guān)于NodeManager 的Java 堆棧大小的參數(shù)的優(yōu)化改造，以修復(fù)集群故障，從而排除可能影響集群運(yùn)行的風(fēng)險(xiǎn)，提高整個(gè)集群的任務(wù)執(zhí)行效率，提高整個(gè)系統(tǒng)的穩(wěn)定性。

3.2.1 方案選擇

在日常業(yè)務(wù)維護(hù)中，涉及GC 配置共有兩個(gè)部分，分別是“集群默認(rèn)GC 設(shè)置”，“節(jié)點(diǎn)GC 設(shè)置”，一個(gè)集群包含N 個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)的優(yōu)先級(jí)高于集群，如果節(jié)點(diǎn)設(shè)置值和集群默認(rèn)設(shè)置值不一樣，以節(jié)點(diǎn)為準(zhǔn)；如節(jié)點(diǎn)不單獨(dú)設(shè)置GC 值，直接調(diào)用集群的GC 設(shè)置值。當(dāng)前GC 采用系統(tǒng)設(shè)計(jì)的默認(rèn)配置，集群配置為1G，大部分節(jié)點(diǎn)配置為2G，有4 個(gè)節(jié)點(diǎn)為1G，在進(jìn)行參數(shù)設(shè)置時(shí)可以直接調(diào)整集群參數(shù)，也可以調(diào)整節(jié)點(diǎn)參數(shù)，為此可有多種方案進(jìn)行選擇，如表1 所示[3,5]。

表1 GC 參數(shù)調(diào)整方案選擇表

結(jié)合日常工作需要，從維持系統(tǒng)穩(wěn)定，滿足業(yè)務(wù)需求角度出發(fā)，目前選擇方案四作為本次參數(shù)調(diào)整的方案，關(guān)于方案四的局限性目前評(píng)估為小概率事件，在后續(xù)工作中保持觀察即可。

3.2.2 方案參數(shù)設(shè)置

集群的數(shù)據(jù)量在達(dá)到當(dāng)前規(guī)模后，部分角色（例如NodeManager）的JVM 的配置無法滿足集群的業(yè)務(wù)需求，導(dǎo)致集群出現(xiàn)了多個(gè)問題，包括任務(wù)執(zhí)行緩慢、組件角色異常、GC 延遲等[6]。針對(duì)以上問題，結(jié)合實(shí)際的業(yè)務(wù)情況進(jìn)行合理的JVM 參數(shù)配置，提高集群性能。

目前的節(jié)點(diǎn)GC 已出現(xiàn)嚴(yán)重告警，使用率已遠(yuǎn)超閾值，如圖6 所示。表明目前參數(shù)設(shè)置已無法滿足當(dāng)前業(yè)務(wù)需求，需要進(jìn)行數(shù)量調(diào)整。

圖6 節(jié)點(diǎn)GC 告警圖

堆棧的大小調(diào)整根據(jù)系統(tǒng)的架構(gòu)來參考，由于異常主機(jī)（OS62、OS89、OS100、OS102 等）來源于默認(rèn)組（NodeManager Default Group，1 GB），本次調(diào)整針對(duì)默認(rèn)組、45 組的配置進(jìn)行更改，參考值則參照其他組（如nodeManager(OS42)，2 GB）進(jìn)行配置即可，如圖7 所示。

圖7 GC 參數(shù)調(diào)整配置

目前系統(tǒng)的架構(gòu)設(shè)置復(fù)核圖7 的第二個(gè)參考設(shè)置，將集群中受影響的節(jié)點(diǎn)的NodeManager角色的“NodeManager的Java 堆棧大小”由默認(rèn)的1 G 調(diào)大為2 G，如圖8 所示。

圖8 參數(shù)設(shè)置參考

4 方案實(shí)施

4.1 調(diào)整節(jié)點(diǎn)GC 參數(shù)值

將集群中受影響的節(jié)點(diǎn)的NodeManager 角色的“NodeManager 的Java 堆棧大小”由默認(rèn)的1 G 調(diào)大為2 G，如圖9 所示。

圖9 調(diào)整參數(shù)

參數(shù)值設(shè)置完成后保存更改，并再次查詢確認(rèn)參數(shù)值已完成調(diào)整，如圖10 所示。

圖10 保存參數(shù)設(shè)置

參數(shù)調(diào)整后重啟Yarn集群的所有NodeManager角色，如圖11 所示。

圖11 重啟完成參數(shù)調(diào)整

4.2 方案實(shí)施后驗(yàn)證觀察

按照上述方案設(shè)計(jì)調(diào)整堆棧大小，觀察系統(tǒng)運(yùn)行的告警、性能是否正常，觀察指標(biāo)情況[3]。

查看告警已自動(dòng)清除，如圖12 所示。

圖12 方案實(shí)施后告警

查看系統(tǒng)攔截程序耗時(shí)前后對(duì)比，業(yè)務(wù)高峰時(shí)段中單個(gè)周期的運(yùn)行時(shí)長由原先的超過50 分鐘縮短至35 分鐘以內(nèi)，如圖13 所示。

圖13 方案實(shí)施前后策略部署耗時(shí)長對(duì)比

觀察一周指標(biāo)均正常，如圖14所示。

圖14 一周指標(biāo)觀察圖

綜上所述，方案實(shí)施后各組件角色狀態(tài)均正常，告警自動(dòng)清除，集群執(zhí)行攔截策略任務(wù)不再緩慢，且沒有出現(xiàn)其他異常報(bào)錯(cuò)，集群的穩(wěn)定性得到顯著提高；系統(tǒng)攔截程序耗時(shí)已恢復(fù)正常，攔截反詐業(yè)務(wù)的耗時(shí)明顯改善，觀察一周指標(biāo)無異常。綜上可知，該方案設(shè)置合理可靠，有效地解決了攔截策略部署耗時(shí)長的問題，并且提高了系統(tǒng)的運(yùn)行穩(wěn)定性，表明方案實(shí)施有效。

5 總結(jié)

本方案對(duì)hadoop 集群組件進(jìn)行優(yōu)化，通過調(diào)整YARN 集群 NodeManager 角色的 Java 堆棧大小配置改變GC 延遲，以解決防詐系統(tǒng)業(yè)務(wù)程序策略攔截耗時(shí)過長問題，經(jīng)驗(yàn)證分析方案設(shè)計(jì)合理，方案實(shí)施有效可控，本方

案可以提高集群的性能和穩(wěn)定性，有效提高任務(wù)執(zhí)行效率，滿足日常業(yè)務(wù)發(fā)展需求。