Aresxue

真实原因是使用了事务，这要求实现单应用内的分布式事务，可以依赖 JTA 去做，比如 Atomikos 、Bitronix 都是不错的开源的 JTA 实现，我这边是实现了一个 DynamicTransactional 注解，多数据源的事务使用我这个注解，依赖注解的切面里使用 JTA(这里我用的是 seata)维护了多数据源下的分布式事务

泛型擦除会擦除到类的上界，普通的对象的上界就是 Object ，一般是拿不到的，如果 method 里有声明可以依赖 ParameterizedType 去获取，不然就取里面的对象的类型，如果还是空的那 jvm 就感知不到了，需要你手动设一个上界或者传进去

提供点思路
1.动态调用分析，依赖全链路监控系统，如 skywalking 、pinpoint ，有了这个之后你的方法被哪些服务调用甚至流量都能够计算出来
2.静态调用分析，在打包过程中对最终打包的 jar 的 class 进行静态分析（核心就是记录方法签名），这样就能够知道一个 rpc 方法被哪里所调用，缺点是代码里写了但是实际中可能已经不再使用这种情形无法分析，优点是成本较小，对上层业务 0 感知
3.全文代码检索，类似 kooder 这种全局代码检索，直接输入类的全名就能看到调用的地方，同样对上层业务 0 感知，且能覆盖全部分支，而非仅运行时的版本，缺点是如果是三方合作拿不到源码的话就比较难搞，相比之下 1 和 2 只需要一个部署的 jar 包

@wbd31 这个核心参数一般都会修改的，使之更契合自己的业务，比如阿里的 adb ，应该说官方默认的是 1s 。

refresh=wait_for 还是别加了。。，默认 1s 刷新还是能够满足伪实时诉求的，加了之后对整个 es 的负荷更多反而更加影响性能，用 canal 的话就作为一个 binlog 的采集器好了，自带的 adapter 限制和 bug 太多了。。我这边都是 canal 集群->RocketMQ 集群->多 java 应用进程->ES 集群，慢在哪一步也更好分析，目前你这样感觉要筛查下 binlog 自身的延时，还有 es 的写入频率可能要做适当的调整

要看预估数据量喽，第一种 in 在 name 超大的情况下会造成 sql 语句超过 max_allowed_packet, 而且不利于做缓存优化，还有可能因为单次数据量过大撑爆，第二种就是单次连接只查一条数据过于浪费，可以折中一下， 分析下 name 的 Cardinality, 然后一批 name 过来将其拆分为几个小集合，单个集合按照 cardinality 的预估最终维持查出的数据量单次在指定大小(如 1000)左右，然后在内存里拼接数据, select 语句的开销除了 query 还有 fetch 和 transport, 多线程去做一批的查询最后汇总一般比大结果集单次查询会快上一些。最后说一句如果不是 p0 级接口且有性能诉求不要进行上述优化。。。

全升级了吧，最偷懒也是最省事的方法，反正版本号也不会用完。想严谨点各个模块独立版本号一定要把子版本号放在一起管理，不然子模块一多就是场灾难，deploy 正式版时也有可能会造成一定的困扰

正常水位 500tps，峰值 1500 左右，压测 1w+

单一系统的，接口监控系统（线上线下）和全链路请求追踪系统其实都已经有了，现在是想做业务回归，因为项目在重构且变化比较快。十分感谢您的耐心