针对大并发下SPRINGBOOT+DUBBOX问题排查总结
作者：互联网
揭语：惟精（精纯专一心境）---人心惟危，道心惟微，惟精----借用朱熹格物精神！
摘要：缘自断断续续听同事说生产在运行高峰期前段出现pending状态，一直无暇东顾，总有期望人心（其他人员）会诊断此问题---人心惟危，撰写本篇内容的前一天接到部门核心人的的讯息，需要处理此问题---道心惟微，从而转入惟精状态（历时两天两夜），彻查springboot+dubbox的在微服务下出现的pending状态，导致用户登录不成功，重启之后正常！技术部分写得比较粗略（描述故弄玄虚，涉密等，希有志者关注交流），
诊断过程：
一、排查过程
1、数据库反应
查阅日志，数据库出现FAILD状态的日志与出现pending状态无前后文，时间序列关系--时间、文体空间无关联，剔除数据库反应错误！
2、所有线程池的排查（dubbo线程池、redis线程池、tomcat线程池、zookeeper线程池等等）
线程池的计算=计算机CPU核数*1000（预估数）
修改使用到中间件线程池为预估值*3的安全空间，重新部署系统，历时：20多个小时；
结果：高峰期外网的消费者端服务问题依旧。剔除
3、网络情况（网络交互中瞬时的最大吞吐量）
消费者端---服务提供者，最大字节修改为默认值的3倍左右。
网络流程监控1.7m，正常范围内！
结果：问题依旧。剔除
4、加入调用方法探针：监控（QPS,AVGTIME等）
下图：
总调用情况：测试截图
方法调用监控截图：
历经高峰期后：有了新的生机，但问题依旧。
结论：服务之间网络动波动导致延迟超时调用，线程数居高不下！修改对应的线程池个数后。部署-----不能剔除（socket连接数占用内网环境，导致消息中间件socket服务推送和订阅频率过高）， 服务器网络过载，消息消费滞后，降低推送评率）
5、承4：dubbox的节点重试3次，导致此问题，修改注册方式，等待问题进一步重现！
无量惟精！惟精！惟精！
标签：惟精,调用,SPRINGBOOT,---,并发,DUBBOX,线程,问题,pending 来源： https://www.cnblogs.com/tlcContent/p/15780191.html