针对大并发下SPRINGBOOT+DUBBOX问题排查总结

本文主要是介绍针对大并发下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问题排查总结的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！