前端时间，遇到一个问题，报错是redis连接池不够。
没搞懂 ，只是dubbuo的redis做资源中心而已。
怎么会连接池不够？甲方不提供任何资料，上上一个供应商留下的一年前的包能运行，新改的代码打出来的包不能运行。
对比了包，也没发现有什么特别的，这是有一个dubbo的包，是被修改过的，上一家特地提醒我们说没区别。
束手无策，请来了一个秃顶大神，大神空手来，看日志，看报错，瞬间就爆发出来了强悍的战斗力。
直接看class的反编译过来的代码，直接找到报错的行数，发现配置文件和class对应不上。
配置文件中有写redis的密码，但class里没有读密码的配置。再看连接池不足，是在校验的时候抛出的，大神说，这是先在redis里放一个值，再取出来，看能不能联通。
现在问题就在于redis连不上，所以校验出错，原因就是这个class里没有读密码的配置，但是报错中给出来的却是连接池的问题。
真相大白了，上上家供应商修改了dubbo的源码，增加了redis校验里支持密码的配置，但是没交接给上家供应商。
上家供应商从来没改过代码，稀里糊涂的交给我们，又误导了我们。
替换成正确的包以后，果然正常了。大神和我们的区别就在于，我们还停留在世界蒙上一层面纱的境界，而大神的眼里没有秘密。
他空手而来，但只要有一台本本连上服务器，他就能征服一切。
在他眼里，各种开源软件和自己编写的业务软件没什么差别，正是有这种多年解决问题，查看源码的经验和习惯，才能快速定位和解决掉问题。
另外，十年前，他就写出来了至今我都觉的最好用的数据库中间件，dal。
思路很简单，很多操作都需要缓存，可否将缓存封装到dal里，让业务调用者并不关心数据到底从缓存中还是从db里来？
缓存被规划成对象级缓存，列表级缓存和键值对缓存，同时对db的使用有了严格的限制。