大家好，今天小编来为大家解答致命代码！小小的循环，可能会让服务器崩溃这个问题，很多人还不知道，现在让我们一起来看看吧！

事情是这样的。上周的一天早上，阿凡高高兴兴地去上班了。刚到座位，还没吃早餐，就收到了运维老总发来的企业微信，说他有一个服务A，nginx日志急剧增加。一下子从平时的每天133M增加到了29G。看到这里，我突然想起前一天已经发布了一个版本。早餐吃不下了，赶紧拿着电脑跑到运维组去排查问题。

首先找到服务A对应的nginx日志，通过命令tail -f xxx.log查看日志数据。发现日志中输出最多的就是调用获取配置信息的接口。这个接口是一个非常简单的接口，它从数据库中加载数据并存储到缓存中，然后提供给外界访问的接口。本身没有业务逻辑。确定接口后，通过nginx日志可以看到请求全部来自于一个核心服务B。

[[334366]]

至此，基本可以断定B服务的逻辑存在问题，并且问题的方向已经确定。我找到了B服务中调用这个接口的地方，一共有两个地方。每五分钟调用一次以进行内存缓存。这一段的逻辑一直都在，不会有问题；另一个是它是自定义的Prometheus 指标集合。 Prometheus 每15 秒收集一次数据。仔细想想，问题肯定就出在这里。

看了一下逻辑，这段代码是一个自定义的指标集合，用于收集Grafana上的相应数据。恰巧Prometheus在生产中每15秒拉一次数据，加上生产环境数据量比较大。大了，这段代码中调用接口的逻辑是循环写的，导致每15秒触发一次循环。每次循环数据量较大，每次都会调用接口，而服务B还是多实例部署，导致接口调用次数剧增，引发了这起“杀人罪”。

一旦问题定位，解决办法就比较简单了。接口调用从循环体移到外部。该计划进行了一些更改。变更完成后，合并代码，添加标签，升级其中一台服务器进行观察。发布后，整个接口的调用次数下降了。观察了一段时间，全网没有任何异常。

复盘对这个问题做了回顾，事故本身并没有造成业务异常，还好发现得早，否则每天产生的大量日志迟早会占满磁盘空间，引发问题。经过深入审查，我发现连接到Prometheus的自定义指标实际上没有实际使用价值。这篇文章的逻辑在很多版本中都有改变，但没有最终版本。不知道哪个版本会用到这个代码。已提交。这也反映出我们的版本规划存在问题。许多需求经常被更改和插入。没有严格遵循版本也是造成这个问题的一个重要原因。

我还想提醒大家，开发和发布一定要严格遵循版本迭代。不然哪天我也踏入这样的陷阱，那就更尴尬了。

工作中难免会出现错误，但有些错误可以犯，有些错误不能犯。每个程序员都会写出错误。写bug问题不大，但能否及时解决才是关键。对于真正影响在线业务的错误，时间就是金钱。你多花一分钟的时间就意味着你损失一分钟的钱。有时候一分钟的钱不多，有时候一分钟的钱就够关掉一家公司了。

所以每个程序员都应该尊重网络。

关于本次致命代码！小小的循环，可能会让服务器崩溃和的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。