1.前期问题分析n n n n
流程改造7月4号上线，上线后导入历史放款指令5万多笔。上线完成发现导标发放款指令比较慢。发现cup高。一直找问题最后发现批量分配启动cup就上去了。定位批量分配有问题，批量分配半个小时启动一次，但是批量分配跑完要1个半小时。处理策略将批量分配该未2个小时。解决了批量被运行几次cpu很高的问题，但是cup还是高。
第二天，第三天，负债系统还是一直出现负载很高。后来找运维将cpu2个该成4个，负载很高没有解决，只是解决了不发负载高邮件。
分析批量分配代码，发现批量分配代码中有一定的问题
1.分页获取数据分配5次，分配不出去，每次获取是一样的。
2.每个资产分配都要创建产品规则大对象。
改造完之后上线了，但是还没有解决分配问题。
7月12号早上，服务器cpu打满了，就把批量分配停止了，但是业务操作还有手动分配，机器负载也很高。而且出现好的错误信息，连接数据库连接不上，kafka消息丢失。
这时分析是不是有慢查询，导致数据库压力了，果然发现有一条慢查询，
这个查询是分配资金方时，查询参数中没有放入要查询的资产id，导致查询了所以的放款指令。
修改代码之后上线，cpu问题解决了。
但是线程数一直很高，将线程日志信息导出了，查询了下 ，有MQ的线程还在执行，找到问题，进件完成和进件退件以前的发消息没有注释掉代码。
注释代码，晚上上线，线程数也恢复正常了。
总结：
1.测试环境数据量不大时，这种问题很难发现 。代码要做性能测试。
2.出现问题时，要关注下慢查询，找运维导出相关的日志文档分析问题，可以快速定位问题。
3.代码编写完成之后，检查下代码查询参数条件。
