随着業務量的上增和系統運作的時長的增加，風控的流程執行服務出現了嚴重的逾時問題，本次優化主要分為三個方面
最近的一次fgc
一.資料庫方面，在優化前每日早上9點高峰期資料庫服務網卡總是爆滿，網卡是前兆網卡，換算成流量是100M/s的，當時的資料庫TPS和QPS如下圖：
網卡監控如下圖：
從網卡流量監控上來看，主要是out占比比較多，說明查詢的資料量傳輸占比比較多，但最後排查這不是主要原因，因為我們資料庫伺服器是1主2從，在通過監控發現，2從節點的in占比在50%左右，說明binlog檔案比較大，然後通過dba進一步排查，發現有以下幾張表insert和update比較頻繁，如下圖：
而且監控磁盤的讀寫IO如下圖：
通過以上圖分析出實施方案，首先是加緩存，減輕資料庫查詢的壓力，其次是排查在insert時看是否有大字段，經過排查發現規則快照表有個大字段類型為：longtext，而且實際存儲的資料為大json,且還挺大的，通過優化這兩點果然奇迹出現了,流量果然降下來了，如下圖：
以上就是資料庫方面的優化
二：應用層方面的優化，剛開始時總報dubbo provide提供端線程池滿了，最後發現有個業務代碼的線程池使用的隊列有點問題，後來我們就修改為：
因為SynchronousQueue這個隊列線上程池數滿時 他會從新啟動一個線程來執行任務，是以我們改為了LinkedBlockingQueue從一定程度上講，可以限制并發的流量，優化完後的效果如下圖：
三：jvm方面的優化，當時線上jvm的配置及調整如下圖：
當時優化效果是從1個小時2次fullGC變為1次fGC,當時調整這個的原因是因為發現每次fgc時年老的都沒滿，但是永久代都快滿了
這次優化完fgc是減少了一半，但是規則執行哪兒還是有逾時的，最後又把規則加載哪兒修改為有變化時在從從新加載重新整理，因為加載規則哪兒是大量的字元串，目前線上是400多條的規則，這樣不停的重新整理産生的結果是ygc也挺頻繁，最後把重新整理這兒改了之後ygc時間減少了一半，具體的對比如下圖：
公司jvm監控截圖如下：
優化之後間隔2天發生了一次fGC，結果發現fgc耗時比較長
優化之前由永久代出發的fgc耗時如圖：