一、前言

由于工作需要，前一阵子使用python+twisted重新开发了中国联通SGIP短信系统的通信部分。 由于这个系统是在原有系统上升级，时间有限的缘故，沿用了原系统的数据处理部分。这部分采用MS SQL Server数据库做后台支撑，使用python的sql server包进行数据访问。程序不间断轮询数据库的待发送短信表，读取到短信数据后调用sgip模块进行发送。另外短信的Submited、 Response、Report、归档几个状态的转换也全部都是基于数据库操作，因此系统对数据库的读写操作相当频繁。随着业务的增长，到每天几十万的短 信下行时，数据库已不堪重负，故障频传了。在这样的情形下，对系统数据操作及存储的升级势在必行了。

短信平台系统（这里是指独立的短信收发处理程序，不涉及具体的产品业务数据）有两个的特点：其一是数据架构比较简单，只有MT、MO、Report 三种（严格上说还包括Response），但MT数据存在一个状态的转换，即待提交->已提交->已响应->已报告状态；其二是数据对 事务处理没有要求，数据库在系统中的的作用就是查询上下行短信记录。因此我觉得要提升系统性能，使用当下热门的内存数据库（NoSQL）是一个不错的选 择。

二、系统架构

内存数据库很多，基本都是大型网站的开源产品，最终我选择了Redis。原因是除了它强劲的性能，它的List特新非常适合对数据队列的不间断轮询，另外它的Set用于保存下行短信处理过程中的状态转换也十分方便。下面是系统架构图：

系统共由五个部分组成，即：短信下行RPC接口程序、短信发送程序、短信接收程序、Report转发程序、数据泵。短信下行RPC接口程序是通过 XML-RPC的方式向外部提供接口，供要发送短信的业务系统调用，从这里一条下行短信开始了它的生命周期；发送程序同网关建立TCP/IP链接，向网关 提交下行短信；接收程序监听端口，接收来自网关的用户上行短信和状态报告，同时将上行短信转发到短信平台业务系统；Report转发程序用于将网关返回的 下行短信Report转发到短信平台业务系统；数据泵的作用是将处理完成的下行短信（已收到状态报告的）和用户上行短信数据从Redis持久化到 MySQL数据库，用于历史数据的查询和统计。

三、数据架构

使用内存数据库，数据架构的规划非常重要，由于它不是关系型数据库，因此我们关于数据库的经验在这里全部不管用了。在key-value的存储中，关系数据库中一个简单的select，在这里都需要设计相应的数据结构才能完成。下面是我的数据架构规划，可供参考：

SCHEMA_MT                = “mt:%s”                     # MT的key架构
SCHEMA_SUBMITED          = “submit:%(seqno)d:%(ts)d”   # 已提交MT的id的key架构
SCHEMA_SUBMIT_FAIL       = “submit-failed:%s”          # 提交失败mt的key架构
SCHEMA_REPORT            = “report:%s”                 # 状态报告的kye架构
SCHEMA_MT_SEQNO          = “mt-seqno:%s”               # 短信提交序号key架构
SCHEMA_MT_TIMESTAMP      = “mt-ts:%s”                  # 短信提交时间戳key架构KEY_MT_ID                = “mt-GID”                    # MT唯一id的key
KEY_PENDING_LIST         = “list:pending-%d”           # 待发送MT的id列表key
KEY_SUBMITED_SET         = “set:submited”              # 已提交MT的id集合key
KEY_RESP_SUCC_SET        = “set:response-succ”         # 收到提交响应MT的id集合key(成功)
KEY_RESP_FAIL_SET        = “set:response-fail”         # 收到提交响应MT的id集合key(失败)
KEY_REPORT_LIST          = “list:report”               # 状态报告的id列表key
KEY_FINISH_LIST          = “list:finish”               # 已完成的id列表keySCHEMA_MO                = “mo:%s”                     # MO的key架构
KEY_MO_LIST              = “list:mo-id”                # 收到MO的id列表
KEY_MO_ID                = “mo-GID”                    # MO唯一id的key

四、数据处理流程描述

1.RPC接口程序收到客户端的调用时，为MT生成一个唯一ID（incr KEY_MT_ID），将该ID作为MT的key（SCHEMA_MT），短信数据作为value保存，同时将该ID存入待发送列表KEY_PENDING_LIST；

2.发送程序从KEY_PENDING_LIST中弹出待发送短信的ID，并通过该ID作为key（SCHEMA_MT） 取得短信数据。提交到网关后，将ID写入KEY_SUBMITED_SET。网关异步返回Response后，根据返回的状态值将ID写入 KEY_RESP_SUCC_SET或KEY_RESP_FAIL_SET。另外记录该MT的发送序号SCHEMA_MT_SEQNO和时间戳 SCHEMA_MT_TIMESTAMP，同时保存ID与这两个数据的关系到SCHEMA_SUBMITED，以便后期从发送序号和时间戳反向获得ID；

3.接收程序收到状态报告后，通过对应下行短信的发送序号和时间戳获得MT的ID，将该ID从KEY_RESP_SUCC_SET中删除并写入到返回状态报告的MT ID列表KEY_REPORT_LIST；

4.状态报告转发程序从KEY_REPORT_LIST中弹出MT的ID并得到短信数据后，将状态报告转发到业务系统，并将ID加入到KEY_FINISH_LIST；

5.数据泵程序从KEY_FINISH_LIST弹出MT的ID得到短信数据，将下行短信的相关数据写入到MySQL，并删除所有相关的key。

五、后记

以上几个程序全部采用轮询的方式读取相应的List，有数据时处理即可。系统升级到Redis后，效率大幅提高，系统压力几乎没有了，即使业务大幅增长，应对起来也绰绰有余了。