有的时候搞垮服务器，只需要一个循环引
每天早上七点三十，准时推送干货
Hello 大家好，我是阿粉，工作这么多年虽然经历过风风雨雨，但是每次线上发布版本的时候都是一场硬战，这不最近发布了一个版本，一不小心写了个 bug，差点造成了生产事故，幸好运维老大发现及时。
背景
事情是这样的，上周的一个早上阿粉高高兴兴的上班，刚到座位上早饭都还没来得及吃，就收到一条企业微信，是运维老大发来的，说有个服务 A 的 nginx 日志暴增。从平时的每天 133M 一下子暴增到 29G，看到这里突然想起来前一天刚好发过版本，一下子早餐也吃不下了，赶紧拿着电脑跑到运维那边排查问题。
首先找到对应服务 A 的 nginx 日志，通过命令 tail -f xxx.log 查看日志数据，发现日志里面输出最多的是对一个获取配置信息的接口的调用。这个接口是一个很简单的接口，就是加载数据库的数据存入缓存，然后对外提供接口访问，本身不存在业务逻辑。确定了接口以后，通过 nginx 日志看到请求都是来自一个核心的服务 B。
到这里基本上可以断定是服务 B 的逻辑有问题了，问题的方向已经确定下来了。定位了一下在服务 B 中调用了该接口的地方，总共有两处，一处是每五分钟调用一次，进行内存缓存，这块的逻辑是一直都有的，不会有问题；另一处是一个自定义的普罗米修斯的指标采集，普罗米修斯每 15 秒会进行一次数据的采集，这么一想那问题肯定是出在这里了。
看了一下逻辑，这块的代码是做了一个自定义的指标采集，用于在 Grafana 上面采集相应的数据，刚好生产上有 Prometheus 每 15 秒 Pull 一次数据，再加上生产环境的数据量较大，这段代码里面调用接口的逻辑写在了一个循环里面，从而导致了，每 15 秒会触发一次循环，每次循环的数据量很大并且每次都调用接口，并且服务 B 还是多实例部署，导致接口的调用次数暴增，从而引发了此次”血案“。
问题定位出来了，解决就比较简单了，将接口的调用从循环体内迁移到外面，方案做了一些变动，改完过后合并了一下代码，打了一个 tag，升级了其中一台服务器进行观察，发布完过后，整个接口调用的次数就下降了，观察了一会没有异常就全网了。
复盘
事后对这个问题做了一下复盘，事故的本身没有引起业务的异常，但是还好发现的早，不然每天产生如此大的日志量迟早会占满磁盘空间出事情。再深度复查一下发现接入普罗米修斯的这块自定义指标其实并没有实际使用价值，这块的逻辑前前后后改动过好多版本，但是没有一个最终的版本，不知道在哪个版本将代码提交上去了。这也体现出我们的版本规划是有问题的，很多需求前前后后经常变动和插入，没有严格的按照版本执行也是导致此次问题的一个重要原因。
这里也提醒一下大家一定要严格按照版本迭代进行开发和发布。不然哪天踩了这样的坑就比较尴尬了。
工作中难免会出现失误，但是有些失误能犯有些不能犯，每个程序员都会写出 bug，写出 bug 问题不大，但是能不能及时解决就很关键了。真正影响到线上业务的 bug，时间就是金钱，多消耗一分钟就损失一分钟的钱，有的时候一分钟的钱没多少，有的时候一分钟的钱足以倒闭一家公司。
所以我们每个程序员都应该要敬畏线上。
写在最后
最后邀请你加入我们的知识星球，这里有 1800+ 优秀的人与你一起进步，如果你是小白那你是稳赚了，很多业内经验和干货分享给你；如果你是大佬，那可以进来我们一起交流分享你的经验，说不定日后我们还可以有合作，给你的人生多一个可能。
最后说两句（求关注）
最近大家应该发现微信公众号信息流改版了吧，再也不是按照时间顺序展示了。这就对阿粉这样的坚持的原创小号主，可以说非常打击，阅读量直线下降，正反馈持续减弱。
所以看完文章，哥哥姐姐们给阿粉来个在看吧，让阿粉拥有更加大的动力，写出更好的文章，拒绝白嫖，来点正反馈呗~。
如果想在第一时间收到阿粉的文章，不被公号的信息流影响，那么可以给Java极客技术设为一个星标。
最后感谢各位的阅读，才疏学浅，难免存在纰漏，如果你发现错误的地方，由于本号没有留言功能，还请你在后台留言指出，我对其加以修改。
最后谢谢大家支持~
最最后，重要的事再说一篇~
快来关注我呀~
快来关注我呀~
快来关注我呀~
< END >
如果大家喜欢我们的文章，欢迎大家转发，点击在看让更多的人看到。也欢迎大家热爱技术和学习的朋友加入的我们的知识星球当中，我们共同成长，进步。
往期精彩回顾