随着业务量的上增和系统运行的时长的增加，风控的流程执行服务出现了严重的超时问题，本次优化主要分为三个方面
一.数据库方面，在优化前每日早上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耗时如图：
