项目场景：
设备报警记录存储在redis里面，需要频繁访问redis取出报警时间对比，在项目运行一段时间后报错
无法发送命令！尝试增加“nettyThreads”和/或连接池大小设置节点源：NodeSource
Unable to send command! Try to increase 'nettyThreads' and/or connection pool size settings Node source: NodeSource
看报错信息类似是连接池大小的问题
Redisson RedisTimeOutException异常排查
但是我的本身就是同步的方法get然后就从get方面去入手
开始debug
添加了日志后发现有业务代码有逻辑问题 频繁的去获取redis的get方法
把业务代码注释掉之后就正常了
突然发现自己好傻逼，因为业务代码也是本人写的 可能因为之前数据量不多没有出现这个bug所以没有发现，当数据量一多的话就出现了这样的问题。
总结
我觉得从这个案例中收获了两点感悟：
- 现象并不那么可靠，不能头痛医头脚痛医脚。
- 先从怀疑自己的代码开始。
第一点，应该是个常识了，医生诊断的例子充分说明了这点。 第二点，为什么要先从怀疑自己代码开始呢，简单来说就是应用的业务代码通常是测试和验证最不充分的代码。 业务应用依赖的环境不论是硬件（主机、网络、交换机）的还是软件的（操作系统、JVM、三方库）这些通常都比业务代码 经过更多地测试和广泛地应用验证，所以要先从怀疑自己开始，除非有非常明确地证据指向其他方面， 个人经验大部分时候这都是找到问题的最短路径。
下次出现问题还是第一时间debug吧，去修改业务代码了。。。。。。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
