后续对A系统做了查询限流，保证并发量在15TPS以内，核心业务服务需要做好查询限流保护，同时也要做好缓存设计。
4、多线程代替单线程
场景：应急定位场景下，A系统调用B系统获取诊断结论，TR超时时间是500ms，对于一个异常ID事件，需要执行多个诊断项服务，并记录诊断流水；每个诊断的耗时大概在100ms以内，随着业务的增长，超过5个诊断项，计算耗时累加到500ms ，这时候服务会出现高峰期短暂不可用。
将这段代码改成异步执行，这样执行诊断的时间是耗时最大的诊断服务
// 提交future任务并发执行
futures = executor.invokeAll(tasks, timeout, timeUnit);
// 遍历读取结果
for (Future<Res> future : futures) {
try {
// 获取结果
Res singleResult = future.get();
if (singleResult != null) {
result.add(singleResult);
}
} catch (Exception e) {
LogUtil.error(e, logger, "并发执行发生异常!,poolName={0}.", threadPoolName);
}
}
5、集群计算代替单机
这里可以使用三层分发，将计算任务分片后执行，Map-Reduce思想，减少单机的计算压力。
方案二：系统IO性能优化1、常见的FullGC解决
系统常见的FullGC问题有很多，先讲一下JVM的垃圾回收机制: Heap区在设计上是分代设计的, 划分为了Eden、Survivor 和 Tenured/Old ，其中Eden区、Survivor（存活）属于年轻代，Tenured/Old区属于老年代或者持久代。一般我们将年轻代发生的GC称为Minor GC，对老年代进行GC称为Major GC，FullGC是对整个堆来说。
内存分配策略：1. 对象优先在Eden区分配 2. 大对象直接进入老年代 3. 长期存活的对象将进入老年代4. 动态对象年龄判定（虚拟机并不会永远地要求对象的年龄都必须达到MaxTenuringThreshold才能晋升老年代，如果Survivor空间中相同年龄的所有对象的大小总和大于Survivor的一半，年龄大于或等于该年龄的对象就可以直接进入老年代）5. 只要老年代的连续空间大于（新生代所有对象的总大小或者历次晋升的平均大小）就会进行minor GC，否则会进行full GC。
系统常见触发FullGC的case:
（1）查询大对象：业务上历史巡检数据需要定期清理，删除策略是每天删除上个月之前的数据(业务上打上软删除标记)，等数据库定时清理任务彻底回收；
某一天修改了删除策略，从“删除上个月之前的数据”改成了“删除上周之前的数据”，因此删除的数据从1000条膨胀到了15万条，数据对象占用了80%以上的内存，直接导致系统的FullGC, 其他任务都有影响；
