第66章 短信江湖：服务器攻防战（1/2）

2001年的11月网益科技园三层

技术部的服务器指示灯像串坏了的糖葫芦，红得刺眼。

我攥着测温枪贴在机柜上，38.6c的读数让呼出的白气都带着焦灼，这已经是本周第三次服务器过热告警。

而屏幕上“短信发送队列积压 1238条”的红色提示，比机柜温度更让人窒息。

“又卡了！”

老谭把鼠标往桌上一拍，他面前的监控屏分着四个窗口：apache服务器连接数、mysql查询耗时、移动梦网接口响应时间，还有实时用户投诉量。

此刻前三个数字像被吹胀的气球，投诉量的折线图更是直戳天花板。

这一切的源头，得从两个月前沈剑锋的电话说起。

彼时的短信江湖，网益与信浪像两把开刃的刀，都盯着移动梦网这块肥肉，但磨刃的方式截然不同。

丁雷在财报危机后押下的注很明确：游戏与短信捆绑。

我们的短信系统架构是“apache+mysql +自定义交互模块”，核心在“交互”二字。

《大话西游》玩家能通过短信接收师徒系统提醒，移动 qq用户可以用短信收发即时消息。

为了处理这些高频交互，我和老谭给 user_sms表加了双索引：user_id主键索引和 msg_time时间索引。还在应用层写了个简单的消息缓存池，把未读短信先存在内存里，每 30秒批量写入数据库，这样能把 mysql的 qps从 200压到 80以下。

信浪则走资讯推送的路子。

他们依托新闻门户的优势，搞了套“apache+oracle +资讯分发引擎”，oracle的稳定性扛得住每日百万级的资讯订阅请求，分发引擎能按用户标签（如“股市”“体育”）批量生成短信包。

听说他们的工程师给推送系统做了“热点缓存”，把突发新闻比如“国足出线”的短信模板预存在服务器内存，一旦触发就能直接调用移动梦网接口，比我们的资讯推送快 2秒。

我们的服务器机架上堆着不少二手戴尔 poweredge 2650，丁雷说“能省则省”，所以用负载均衡器把请求分到 8台服务器；信浪那边清一色的 ibm xseries，单台内存就有 4gb，比我们的 2gb机型吞吐量大不少。

但论灵活性，我们的自定义模块更胜一筹——比如用户发“绑定游戏账号”到 ，后台能直接调用《大话西游》的用户验证接口，这是信浪的资讯系统学不来的。

沈剑锋当时还是信浪技术部的骨干，每周都要打两三个电话问技术细节。

“你们的短信验证码是怎么防重复的？”

“移动梦网接口超时怎么重试？”

我按公司规定只敢说些皮毛：“就是用随机数生成验证码，超时就等 3秒再发一次。”

他在电话那头笑：“刘军，咱们都是搞技术的，别藏着掖着。”

现在想来，那些问话早露了马脚。

我把这个情况报告了jackson和老谭

11月28日凌晨三点，监控屏突然炸了。

“连接数破 1000了！”

老谭的声音惊醒了趴在桌上打盹的我。

正常情况下，我们的 apache maxclients设为 500，即使峰值也超不过 600。

我点开服务器日志，密密麻麻的 post请求占满了屏幕，全是调用“\/sms\/send”接口的记录。

用户 id从 到 随机生成，手机号段涵盖全国各省，请求头里的“referer”字段全是“sina点\/sms”——虽然 ip地址分散，但这痕迹太明显了。

更糟的是数据库。

老谭打开 mysql的慢查询日志，满屏都是“select * from sms_queue where user_id =? and status = 0”的查询，执行时间最短 15秒，最长 48秒。

“他们用了模糊查询，还不限制结果集，把表给扫崩了！”

老谭拍着键盘，我看到 sms_queue表的行数已经从正常的 2万涨到 18万，全是伪造的未发送记录。

上午九点，投诉电话快把前台打爆了。

“我订的股市短信怎么没收到？”

“游戏里的好友消息发不出去！”