第66章 短信江湖：服务器攻防战（1 / 2）
请关闭浏览器的阅读/畅读/小说模式并且关闭广告屏蔽过滤功能，避免出现内容无法显示或者段落错乱。
2001年的11月网益科技园三层
技术部的服务器指示灯像串坏了的糖葫芦，红得刺眼。
我攥着测温枪贴在机柜上，38.6℃的读数让呼出的白气都带着焦灼，这已经是本周第三次服务器过热告警。
而屏幕上“短信发送队列积压1238条”的红色提示，比机柜温度更让人窒息。
“又卡了！”
老谭把鼠标往桌上一拍，他面前的监控屏分着四个窗口：Apache服务器连接数、MySQL查询耗时、移动梦网接口响应时间，还有实时用户投诉量。
此刻前三个数字像被吹胀的气球，投诉量的折线图更是直戳天花板。
这一切的源头，得从两个月前沈剑锋的电话说起。
彼时的短信江湖，网益与信浪像两把开刃的刀，都盯着移动梦网这块肥肉，但磨刃的方式截然不同。
丁雷在财报危机后押下的注很明确：游戏与短信捆绑。
我们的短信系统架构是“Apache+MySQL+自定义交互模块”，核心在“交互”二字。
《大话西游》玩家能通过短信接收师徒系统提醒，移动QQ用户可以用短信收发即时消息。
为了处理这些高频交互，我和老谭给er_ss表加了双索引：er_id主键索引和sg_ti时间索引。还在应用层写了个简单的消息缓存池，把未读短信先存在内存里，每30秒批量写入数据库，这样能把MySQL的QPS从200压到80以下。
信浪则走资讯推送的路子。
他们依托新闻门户的优势，搞了套“Apache+Oracle+资讯分发引擎”，Oracle的稳定性扛得住每日百万级的资讯订阅请求，分发引擎能按用户标签（如“股市”“体育”）批量生成短信包。
听说他们的工程师给推送系统做了“热点缓存”，把突发新闻比如“国足出线”的短信模板预存在服务器内存，一旦触发就能直接调用移动梦网接口，比我们的资讯推送快2秒。
我们的服务器机架上堆着不少二手戴尔Pe2650，丁雷说“能省则省”，所以用负载均衡器把请求分到8台服务器；信浪那边清一色的IBMxSeries，单台内存就有4GB，比我们的2GB机型吞吐量大不少。
但论灵活性，我们的自定义模块更胜一筹——比如用户发“绑定游戏账号”到，后台能直接调用《大话西游》的用户验证接口，这是信浪的资讯系统学不来的。
沈剑锋当时还是信浪技术部的骨干，每周都要打两三个电话问技术细节。
“你们的短信验证码是怎么防重复的？”
“移动梦网接口超时怎么重试？”
我按公司规定只敢说些皮毛：“就是用随机数生成验证码，超时就等3秒再发一次。”
他在电话那头笑：“刘军，咱们都是搞技术的，别藏着掖着。”
现在想来，那些问话早露了马脚。
我把这个情况报告了ja和老谭
11月28日凌晨三点，监控屏突然炸了。
“连接数破1000了！”
老谭的声音惊醒了趴在桌上打盹的我。
正常情况下，我们的ApacheMaxts设为500，即使峰值也超不过600。
我点开服务器日志，密密麻麻的POST请求占满了屏幕，全是调用“/ss/send”接口的记录。
用户ID从到随机生成，手机号段涵盖全国各省，请求头里的“Referer”字段全是“sa点/ss”——虽然IP地址分散，但这痕迹太明显了。
更糟的是数据库。
老谭打开MySQL的慢查询日志，满屏都是“SELECT*FROMss_queueWHEREer_id=?ANDstat=0”的查询，执行时间最短15秒，最长48秒。
“他们用了模糊查询，还不限制结果集，把表给扫崩了！”
老谭拍着键盘，我看到ss_queue表的行数已经从正常的2万涨到18万，全是伪造的未发送记录。
上午九点，投诉电话快把前台打爆了。
“我订的股市短信怎么没收到？”
“游戏里的好友消息发不出去！”
↑返回顶部↑