7、 上行短信获取服务
获取上行短信SDK介绍如下：
“接收上行短消息,SDK最大缓存20W条上行短信。满20W条上行短信后，将清空全部缓存数据，重新开始接收新的上行短信。
每次调用方法将获得缓存中的全部数据，并从缓存中删除已获取的数据。”
服务调用SDK获取数据后将数据全部存入数据库。
为保证高可用性，此处不做任何数据处理。
上行短信信息表：
|
SMS_MO_DATA_INFO上行短信信息表 |
|||||
|
字段代码 |
字段名称 |
字段类型 |
可空 |
标识 |
主键 |
|
SMS_MO_ID |
主键 |
varchar(36) |
N |
N |
Y |
|
MOBILE |
手机号码 |
varchar(32) |
N |
N |
N |
|
SMS_CONTENT |
短信内容 |
varchar(max) |
N |
N |
N |
|
SEND_TIME |
发送时间 |
datetime |
N |
N |
N |
|
ADD_SERIAL |
目标代码 |
varchar(32) |
N |
N |
N |
|
CREATE_TIME |
创建时间 |
datetime |
N |
N |
N |
|
MSG_GROUP |
批次号 |
varchar(32) |
Y |
N |
N |
|
SMS_MO_DATA_HIS_INFO 上行短信信息历史表 |
|||||
|
字段代码 |
字段名称 |
字段类型 |
可空 |
标识 |
主键 |
|
SMS_MO_ID |
主键 |
varchar(36) |
N |
N |
Y |
|
MOBILE |
手机号码 |
varchar(32) |
N |
N |
N |
|
SMS_CONTENT |
短信内容 |
varchar(max) |
N |
N |
N |
|
SEND_TIME |
发送时间 |
datetime |
N |
N |
N |
|
ADD_SERIAL |
目标代码 |
varchar(32) |
N |
N |
N |
|
CREATE_TIME |
创建时间 |
datetime |
N |
N |
N |
|
MSG_GROUP |
批次号 |
varchar(32) |
Y |
N |
N |
|
HANDLE_RESULT |
处理结果 |
varchar(max) |
Y |
N |
N |
|
HANDLE_TIME |
处理时间 |
datetime |
N |
N |
N |
8、 上行短信获取守护服务
这个是比较坑的一件事。移动云MAS平台，在无账号登录SDK的时候，无法推送上行短信，重新登录SDK后云MAS平台才会继续推送消息，中间时间段的上行短信会丢失！！！
首先上行短信服务停止，可能遇到的情况有1、Windows服务异常并导致服务停止，2、系统更新需要服务重启，3、服务器异常导致服务器宕机，4、服务器操作系统或安全软件更新升级需要电脑重启。
针对上面分析的可能出现的问题，设计了几个方案。
方案一、双服务器并行运行上行短信获取服务。
优点：此方案的可以很好地解决上面所有的问题。
缺点：但是会导致上行短信数据重复获取两遍，由于两个服务并发运行，获取数据后需要锁表并进行判断后才能插入数据，对数据访问的效率影响太大。或者是数据重复插入两遍，在处理时候进行去重操作，但是由于数据插入可能有时间差，可能出现处理时只有一条数据，处理后另一条数据才插入然后又被处理一遍，去重操作无效。
方案二、一个服务器上运行上行短信获取服务，另一个服务器上运行守护服务。
优点：可解决SDK停止的问题。守护服务实时监控正式服务运行状态，只在正式服务停止运行时才会正式运行，数据并不会重复插入。
缺点：在一个服务器上的守护服务，监控另一个服务器上的Windows服务的状态，这个开发难度较大。
方案三、只在一个服务器上部署上线短信获取服务和守护服务。
优点：解决上行短信获取Windows服务停止问题。
缺点：无法解决服务器宕机或重启问题。
由于开发进度较紧，并衡量相关情况，最终采用方案三。服务器重启情况经咨询系统部门同事，不会出现自动重启的情况，需要重启几率极小，确实需要重启时可通知我们，由我们部署临时的上行短信获取服务，或者在半夜重启。针对服务器宕机情况，另外开发监控服务，监控相关运行状态，必要时通过行政手段通知短信平台暂停使用。
