隨着業務量的上增和系統運行的時長的增加，風控的流程執行服務出現了嚴重的超時問題，本次優化主要分爲三個方面
一.數據庫方面，在優化前每日早上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耗時如圖：
