令人还念的短信业务开发（一）

曾经几时，移动短信SP业务火遍九州，今日想起甚是怀念，2004年6月高考月，考生们都心急如焚的等待着考分，那时在我们城市只有电话热线查询，移动率先推出短信查询，第一次做这种业务，心情很激动，然而…业务开始仅仅不到1分钟，短信大量挤压，服务器CPU饱和了，短信网关统计每秒上行2000，这个数字拿到现在可能真的不算什么了，可2004年，我们一台2U，2G的服务器已经可以支撑10几个SP业务，那么回想一下当时的系统架构。
应用程序为CMPP客户端+线程池+业务调用同一台服务器上的数据库，CPU饱和的原因就是数据库，这是一次惨痛的教训，必须深刻反省。于是有了为2005年准备的架构升级。

服务器独立

这个必须的

去除数据库

没必要用数据库，一个hashmap就可以的

CMPP客启端使用nio

非阻塞io可以提高通信效率

网关多开几路连接，放大每秒下发限制

几经测试发现网关默认是每条连接，每秒10条限制，可cmpp规范写的滑动窗口是30，可恶！！！
做了大量压力测试，开了2个接收连接，大约有每秒压到10000条左右，cpu 40%多，网卡5M，还可以，心里还是有些忐忑，期待2005年6月。
这次没有掉链子，100000多查询量，半个小时高峰，可以哈哈了。

幸甚至哉，歌以咏志

后续写一写我们基于短信营业厅的异步框架。