基于開(kāi)源組件的架構(gòu)如果能實(shí)現(xiàn)性能最優(yōu)化，那就是高潮迭起，掌聲不斷，如果架構(gòu)性能不能最優(yōu)化，那就是爺爺趕牛車，急死孫子。

筆者所在項(xiàng)目的日志綜管平臺(tái)架構(gòu)使用了Flink組件，遇到了實(shí)時(shí)計(jì)算延遲的性能問(wèn)題，下面筆者將和團(tuán)隊(duì)一起解決該性能問(wèn)題的過(guò)程分享如下。

基于flink大數(shù)據(jù)處理能力使日志綜管平臺(tái)具備了業(yè)務(wù)鏈端到端可視化、日志檢索分析秒級(jí)化、業(yè)務(wù)異常檢測(cè)自動(dòng)化、數(shù)據(jù)庫(kù)指標(biāo)拓?fù)鋵?shí)時(shí)化。給自己的項(xiàng)目吹個(gè)牛逼，筆者遇到的頭疼問(wèn)題如下：

每天早上6-8點(diǎn)時(shí)間段Flink計(jì)算業(yè)務(wù)鏈相關(guān)指標(biāo)會(huì)延遲，處理數(shù)據(jù)量由正常每分鐘200w+下降到1w以下，通過(guò)增加服務(wù)器資源，加大并發(fā)數(shù)等常規(guī)手段均未能解決。

如圖所示，flink處理的業(yè)務(wù)鏈數(shù)據(jù)量從某一時(shí)間點(diǎn)突然出現(xiàn)斷崖式下降，數(shù)據(jù)處理積壓越來(lái)嚴(yán)重，flink 任務(wù)背壓較高，同時(shí)指標(biāo)出現(xiàn)延時(shí)生成現(xiàn)象（正常處理延時(shí)1分以內(nèi)）。

1. kafka soruce分析

首先通過(guò)查看flink業(yè)務(wù)鏈處理日志，發(fā)現(xiàn)疑似線索。日志顯示任務(wù)連接上游kafka報(bào)Disconnection連接異常現(xiàn)象。當(dāng)指標(biāo)延時(shí)時(shí)，此錯(cuò)誤信息報(bào)頻率較高，但指標(biāo)不延時(shí)偶爾也會(huì)報(bào)錯(cuò)，是否這就是導(dǎo)致問(wèn)題的罪魁禍?zhǔn)祝扛鶕?jù)這一線索，繼續(xù)刨根問(wèn)底：

分析及措施:

default.api.timeout.ms

session.timeout.ms

request.timeout.ms

fetch.max.wait.ms

fetch.min.bytes

調(diào)整連接參數(shù)后Disconnection連接異常現(xiàn)象未出現(xiàn)，但指標(biāo)延時(shí)現(xiàn)象依然存在。

分析結(jié)論:通過(guò)以上監(jiān)測(cè)與優(yōu)化措施，指標(biāo)生成延遲問(wèn)題仍未解決，排除由Kafka引起指標(biāo)延時(shí)的可能性。

2. checkpoint分析

通過(guò)上述優(yōu)化整改，F(xiàn)link與kafka連接異常問(wèn)題解決，但延遲的問(wèn)題還是存在，革命尚未成功，吾輩仍需繼續(xù)深入分析。經(jīng)比對(duì)多天日志，發(fā)現(xiàn)每次任務(wù)重啟前都有checkpoint失敗，ClosedByInterruptException異?，F(xiàn)象

分析及措施:

分析結(jié)論:雖然對(duì)該可疑目標(biāo)進(jìn)行了tunning，但延遲依舊存在，進(jìn)一步排除了checkpoint失敗導(dǎo)致指標(biāo)延時(shí)的可能性。

3. flink 運(yùn)行狀態(tài)分析

排除以上兩種情況后，繼續(xù)對(duì)flink組件本身的運(yùn)行狀態(tài)做全面綜合深入分析。

分析及措施：

通過(guò)分析程序運(yùn)行狀態(tài)，發(fā)現(xiàn)shsncSpanEventStream pre -> Timestamps/Watermarks 這段邏輯有線程鎖現(xiàn)象:

"AsyncIO-Emitter-Thread (trans stream -> Process -> shsncSpanEventStream pre -> Timestamps/Watermarks (28/72))" #181 daemon prio=5 os_prio=0 tid=0x00007f4da3cf8000 nid=0x1324c waiting for monitor entry [0x00007f4d8bdeb000]

java.lang.Thread.State: BLOCKED (on object monitor)at org.apache.flink.streaming.api.operators.async.Emitter.output(Emitter.java:125)

- waiting to lock <0x0000000610a5b028> (a java.lang.Object)at org.apache.flink.streaming.api.operators.async.Emitter.run(Emitter.java:85)

at java.lang.Thread.run(Thread.java:748)

從任務(wù)背壓圖上看，處理延時(shí)是堵在入口解析及下游水位處理環(huán)節(jié)點(diǎn)邏輯上：

優(yōu)化措施:

• flink共享waterMaker機(jī)制，在數(shù)據(jù)源進(jìn)行waterMaker注冊(cè)，減少邏輯處理N倍；

• 對(duì)應(yīng)用吐過(guò)來(lái)業(yè)務(wù)數(shù)據(jù)SPAN和SPANEVENT進(jìn)行分流處理，提高程序處理速度；

• 增加過(guò)濾數(shù)據(jù)邏輯，過(guò)濾掉無(wú)需做指標(biāo)計(jì)算的數(shù)據(jù)，減少程序數(shù)據(jù)處理量。

• 業(yè)務(wù)鏈flink任務(wù)入redis/es拆分出來(lái)做多帶帶算子進(jìn)行入庫(kù)。

• 任務(wù)并發(fā)數(shù)，調(diào)整為50個(gè)并發(fā)數(shù)，消費(fèi)kafka  topic(topic 100  partition)

  
  

實(shí)施以上優(yōu)化措施后，問(wèn)題依舊，延時(shí)并沒(méi)有得到緩解和解決。由于在上一步為了排除checkpoint原因，關(guān)閉了checkpoint，關(guān)閉check后雖然沒(méi)有解決延時(shí)問(wèn)題，但是由于關(guān)閉了checkpoint程序不會(huì)因?yàn)閏heckpoint失敗而停止，因此得以觀察延時(shí)情況下程序gc和堆棧具體使用情況。

4. gc和堆棧分析

mat分析：

通過(guò)簡(jiǎn)單的jmap命令，發(fā)現(xiàn)很多不正常的類占據(jù)著堆內(nèi)存的前幾名，這些類究竟有什么關(guān)系，誰(shuí)才是罪魁禍?zhǔn)祝恐缓檬钩鑫覀兊慕K極MAT分析大法。

通過(guò)分析導(dǎo)出生成的dump, 整個(gè)dump文件有6.7G,使用32G內(nèi)存的機(jī)器經(jīng)過(guò)10多分鐘的處理，才得到以下分析結(jié)果。

分析報(bào)告顯示ScheduledThreadPoolExecutor對(duì)象持有4.3GB堆內(nèi)存未釋放，堆餅圖中占有97%

點(diǎn)進(jìn)去查看樹(shù)圖,發(fā)現(xiàn)ScheduledThreadPoolExecutor對(duì)象持有4.3GB堆內(nèi)存全部是GenericObjectPool對(duì)象（4.3G，接近1百萬(wàn)個(gè)對(duì)象）

再點(diǎn)擊GenericObjectPool展開(kāi)后發(fā)現(xiàn)：

之前通過(guò)jmap分析排行在前的AtomicLong(排第一，占2.7G)和redisFactory類都是躲藏在GenericObjectPool對(duì)象中的。分析至此，本人的第六擼感告訴我，離事情的真相越來(lái)越近了。與redis連接相關(guān)的GenericObjectPool對(duì)象就是問(wèn)題的真兇，內(nèi)存泄漏的對(duì)象。

1.去掉連接池

看到GenericObjectPool連接池對(duì)象不釋放，首先想到的是連redis的連接池去掉。將flink任務(wù)與redis交互的代碼去掉GenericObjectPool連接池，采用直接獲取redisCluseter對(duì)象方式：

(上圖是初始代碼，JedisCluter保存在GenericObjectPool連接池中)

(去掉GenericObjectPool連接池后只獲取JedisCluster對(duì)象)

結(jié)果：?jiǎn)栴}未緩解，未解決，還得繼續(xù)。

2.連接池加鎖

由于去掉和redis的連接池未解決問(wèn)題，依然生成大量GenericObjectPool對(duì)象不釋放，一個(gè)推測(cè)是并發(fā)原因?qū)е聠卫龥](méi)有生效，生成了很多個(gè)JedisCluster對(duì)象，而JedisCluster對(duì)象包含了連接池。嘗試synchronized加鎖：

結(jié)果：?jiǎn)栴}仍未緩解，仍未解決，還得繼續(xù)。

3. 改redisCluseter對(duì)象為多帶帶變量

上兩步都沒(méi)有進(jìn)展，從頭開(kāi)始分析代碼，代碼分析過(guò)程中發(fā)現(xiàn)flink十多個(gè)任務(wù)都是使用統(tǒng)一的redis初始化方法且只生成單個(gè)redis連接實(shí)例。十多個(gè)flink任務(wù), 每個(gè)flink任務(wù)中又有許多地方需要用到redis連接，redis單例在這里就會(huì)成為瓶頸（數(shù)據(jù)處理不過(guò)來(lái)，進(jìn)而積壓）。于是變單例的redisCluseter對(duì)象為多帶帶變量，每個(gè)用到redis連接的類都生成redisCluseter變量，然后再與redis交互，以此使redis隨Flink的連接數(shù)并發(fā)派生。

整改結(jié)果：?jiǎn)栴}得到階段性解決，之前運(yùn)行一天就出現(xiàn)堆和gc問(wèn)題，整改后穩(wěn)定運(yùn)行三天后又出現(xiàn)同樣問(wèn)題。

4. 去掉異步方法

雖然只穩(wěn)定運(yùn)行三天，但對(duì)筆者和整個(gè)團(tuán)隊(duì)來(lái)說(shuō)，也還是很開(kāi)心的，說(shuō)明我們的方向大概率是對(duì)的。但問(wèn)題復(fù)現(xiàn)，作為四有好青年的IT民工，咱得發(fā)揚(yáng)不怕苦，不怕累的精神繼續(xù)分析排查。這次排查過(guò)程中發(fā)現(xiàn)眾多的GenericObjectPool是由ScheduledThreadPoolExector引用的，ScheduledThreadPoolExector是一個(gè)異步類，再排查flink中的異步方法。找到AsyncDataStream.unorderedWait()是異步寫入redis方法，將其修改為改造后的官方flink-redis連接包，去除異步。

結(jié)果：?jiǎn)栴}解決，堆和gc一直正常

• 業(yè)務(wù)鏈指標(biāo)生成正常: