我们那个项目，刚上的时候，简直就是噩梦。老板拍板说要用新的架构，结果并发量稍微上来一点，系统就跟老年人爬楼梯似的，喘得厉害，直接卡死。我们团队七八个人，连着熬了好几个通宵，眼睛都红了，大家把代码翻来覆去看了快十遍，就是没找到哪儿有问题。每个人都盯着自己的模块，比如A说我内存没泄露，B说我业务逻辑完美，都在互相踢皮球。
我们一直错看了哪里？
当时我们把所有的重点都放在了“线索1”上，也就是业务逻辑和新加的缓存层。大家都觉得肯定是新的缓存没配置或者哪段代码写得太烂，导致CPU爆了。我们做了无数次的压测，调整了缓存的过期时间，甚至把一些核心算法都重写了一遍，一点用都没有。高峰期一到，报警声就响个不停，搞得我晚上睡觉都做梦在听报警。那段时间，真是人不像人，鬼不像鬼。
我为啥对这事记得这么清楚？当时就是因为这个系统稳定不下来，年底奖金直接泡汤了。我老婆等着那笔钱去交首付，结果一分钱没有。当时我气得差点把键盘砸了，跟领导吵了一架，领导直接把我调去了个不重要的维护岗，意思是让我冷静一下。结果，冷静下来还真就冷静出问题了。
发现“2号线索”的过程
被调去维护岗后，手头事情少了，我就有空去翻那些平时没人看的系统底层日志。以前我们都是看应用日志，只关心业务跑没跑通。这回我把目光瞄准了网络层和数据库连接池那块儿，那是真正的脏活累活，没人愿意看。
我翻了半个月，几乎把所有连接建立和销毁的记录都捋了一遍。我发现一个特别诡异的事，在系统刚启动的时候，连接池表现得很正常，但是只要一遇到流量冲击，连接数就会在极短时间内飙升，然后又快速回落。这说明我们的连接池设定有问题，它不是平滑的，而是像弹簧一样，一压就弹，快速建立和销毁，资源全耗在连接的切换上了。
这就是真正的“2号线索”：数据库连接池的最小闲置连接数（Min Idle）配置得太低了！
大家都盯着代码优化，却忽略了基础设施的配置。我们之前设的最小闲置连接数是5，最大连接数是500。在低流量的时候，5个够用。但高流量突发时，系统需要瞬间新建几百个连接来应对，这个建立新连接的过程是要时间的，而且资源消耗巨大，导致请求队列堆积，用户体验就是卡顿甚至超时。
快速解决，扭转乾坤
我没敢直接在主系统上改。我找了块测试环境，把最小闲置连接数从5直接拉到了150。我把同样的压测跑上去，这回系统稳得一匹。并发量瞬间上来的时候，因为有150个闲置连接随时待命，系统根本不需要浪费时间去建立新的连接，直接拿来用就行。
- 我们调高了最小闲置连接数，系统不再频繁建立和销毁连接。
- 我们清除了以前因为连接建立慢导致的请求堆积。
- 我们实现了系统吞吐量翻倍，CPU占用率下降了40%。
我拿着这个测试报告去找领导，领导一开始还不信，觉得这么简单一个配置怎么可能解决这么大的问题？等他看到生产环境调整后，系统稳定如山，他立马给我道歉，让我回核心开发组。原来那个接替我的同事，因为压力太大，已经自己辞职跑路了。
从那以后，我才明白，有时候快速解开谜题的关键，不是那些复杂的高级优化，而是那些最基础、最不起眼的基础配置。这就是为啥我一直强调要看底层日志。这回发现，不仅帮我拿回了奖金，还让我职业生涯上了一个台阶。每次接新项目，我第一件事就是拉起底层配置，检查那些没人关心的“2号线索”。
