2001年11月
晚上8点，网益科技园 3楼的技术部还亮着灯。
我攥着刚打印的业务分工表，站在老谭的办公桌前——表格上“短信业务”四个字被红笔圈了 twice，旁边写着“Q4核心指标：日活用户破 50万”。
老谭叼着没点燃的烟，手指在键盘上敲出一行日志：“今早 9点短信推送高峰，系统又卡了 2分钟，客服那边接了 300多个投诉电话。”
我把分工表摊开，指着“邮件系统维护”那栏：“Rebecca和梁辉刚说，邮件服务器上个月才扩容，应该能扛住日常维护。倒是短信这边，我上午跟运营商对接时，移动的人说他们的网关每秒能处理 800条请求，咱们的系统上次测才到 200条。”
老谭终于点燃烟，吐了个烟圈：“先把业务流理清楚，才能找症结。”
他从抽屉里翻出张白纸，画了三条并行的线——用户、网益 SP服务器、运营商网关。
“你看，用户在咱们首页点‘订阅体育短信’，输入手机号后，请求先到咱们的 SP服务器；服务器要查两个东西：一是这个手机号有没有在咱们的用户库里，二是运营商那边有没有欠费；确认没问题后，再把订购请求推给移动或联通的网关；网关返回‘成功’，咱们才能给用户发确认短信，月底再跟运营商结算分成——这整个流程，哪一步慢了都不行。”
我突然想起上周的崩溃事件：“上周六晚上有场国足比赛，赛后 10分钟内，有 3万用户同时订‘赛况短信’，结果 SP服务器直接宕机了。当时查日志，发现数据库里‘用户订阅表’的查询语句跑了 40秒——原来没给‘手机号’字段加索引。”
“这只是小问题。”
老谭把烟摁灭在烟灰缸里，打开服务器监控界面。
屏幕上的红色曲线刺得人眼疼，“你看高并发时的资源占用：CPU到 90%，但内存才用了 40%；数据库连接池满了，新请求全堵在队列里。咱们的系统架构是年初搭的，当时想着短信业务刚起步，用两台 IBM XSeries服务器做集群，数据库用 Oracle单实例——哪想到才半年，用户量就翻了三倍。”
窗外的夜色更浓了，技术部的同事陆续走光，只剩我和老谭的电脑屏幕亮着。
老谭突然翻出一份竞品分析报告，是市场部上周发的：“移动自己的短信平台，直接接基站，不用走第三方网关，响应速度比咱们快 0.8秒；联通更狠，给省市级分公司开了专属接口，覆盖范围比咱们广 30%。还有信浪，他们把短信跟新闻绑定，用户看头条时一点就能订，上周日活已经破 60万了；搜虎靠娱乐短信，把‘明星八卦’打包成包月服务，用户留存率比咱们高 15%。”
我攥紧了拳头：“那咱们的优势呢？文档里说用户基数和邮箱资源——是不是能从邮箱引流？比如给邮箱用户发提醒：‘绑定手机号，接收登录验证码短信’，先把用户拉进来，再推订阅服务。”
老谭眼睛亮了：“这是个好路子，但前提是系统得扛住。现在咱们要解决两个核心问题：一是请求处理瓶颈，二是数据库压力。”
他打开 Excel，列了三个方案：“第一，加两台 SP服务器，做轮询负载均衡——用户请求进来，轮流分配到四台服务器，避免单台过载；第二，给数据库做读写分离，查询请求走从库，写入请求走主库，再给‘用户订阅表’加联合索引；第三，在 SP服务器和数据库之间加一层缓存，把常用的‘用户状态’‘订阅套餐’存在内存里，不用每次都查数据库。”
“这些方案要多久落地？”
我盯着 Excel里的“预估耗时”，老谭写的是“3天”。
“明天先跟采购部申请服务器，同时让梁辉帮忙优化数据库索引；后天部署负载均衡器，我来写缓存逻辑——用本地缓存就行，现在还没必要上复杂的分布式缓存。”
老谭突然笑了，“你还记得去年做邮件系统时，咱们也是这么加班赶工的？当时邮件并发上不去，最后是靠分批次发送才解决的。”
第三天晚上，我们用模拟工具测了 10万次并发请求——之前会崩溃的系统，这次响应时间稳定在 0.5秒，数据库连接池的占用率才到 60%。
老谭盯着监控屏幕，突然说：“移动的人今天跟我说，下个月要上调 SP的分成比例，从 3:7调到 4:6。”
我愣了一下，突然想起市场部的话：“短信业务的毛利率有 60%，比游戏还高。但你说，这高利润能走多久？信浪已经在做彩信了，听说能发图片。”
老谭没说话，只是把监控界面的截图保存下来，命名为“短信业务破局 1.0”。
窗外的天快亮了，楼下的早点摊飘来豆浆的香味。
小主，这个章节后面还有哦，请点击下一页继续阅读，后面更精彩！
喜欢人生何处是归途：花城网事三十年请大家收藏：(m.zjsw.org)人生何处是归途：花城网事三十年爪机书屋更新速度全网最快。