一次教训

今天一大早回到公司,测试同学就问我发短信给他干嘛。当时觉得奇怪,我都没找过他,问啥时候发。问清才知道原来是他收到了这边一个省钱电话的充值短信,看了一下,短信的内容还是旧的,不是新更新后的。当时以为是谁在做测试,也没当一回事。

过了不久,身边好些人都收到了同样的短信,这时候开始有点预感可能出问题了。上线查了一下,才发现服务端在不断地推送短信,但却没有收到任何充值通知,而且收到的短信内容都是更新前的,但是今天早上已经更新了新的,线上环境check过也确实是了。

后来发现外部队列有五千多条未下发的信息,服务端是从外部队列读取到信息然后下发的。但观察日志在重启前一直是正常的,重启之后就突然有一堆未下发的短信了。当时还怀疑是不是外部队列有问题,但是它出问题的可能信极低。由于发送短信这块是一个离职的同事负责完成的,我在他离职后由于未出啥问题和变动一直没有去看过代码。这次不得不去看了一下,光看代码没看出啥问题,后来对比了一下日志,才发现问题的所在。当时他是用一个定时器轮询外部队列是否有信息,当有信息的时候,会先取出一条,然后将发送状态置1,等到发送完成再将发送状态清零,在此期间如果定时器的回调再次被触发时判断到发送状态被置1就会直接return掉。问题就出在这里,由于发现短信所用的接口是异步的,发送状态依赖于异步回调被触发才会被清除掉。但实际上当时他使用的发送短信的客户端是参考以前的一个实现,以前的实现有一个BUG,就是发送到的服务端如果超时时是不会触发异步回调的,等于说之前是一直发不出去短信的,但是新的短信却一直积压在外部队列里,这次更新后程序正常了,所以开始下发那些迟到的短信了。

其实这个问题测试同学就有反映过,我也修复过了,当时反馈给开发短信发送模块的同学,我也就没去跟进了。后来这个服务端上线了几个月,竟然都没有人反映没有收到短信,我也没时不时观察下日志看下程序是否正常服务,以为没人爆问题就是真的没问题了。

虽说并不是我开发的,但他离职后我既然接手过来了,实际上还是应该承担起相应的责任的,应该及时跟进他的代码,至少应该想到短信下发是属于比较敏感的东西,可能给公司带来一定的影响,进而及时加上相关的警报,这样可能就不会导致这样的问题。幸好这个省钱电话还没有大量推广,影响的用户层不大,不然后果可能就真的不是这样了。

这里记下这次教训,以后无论什么事,都要及时跟进,做好一切的准备,掩耳盗铃并不是一个好的方式。也不要想当然,现在没有问题,不代表以后不会出问题,这次就是一个很好的例子。

标签: ,
文章分类 工作

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*