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服務停止問題。
缺點：無法解決服務器宕機或重啟問題。
由於開發進度較緊，並衡量相關情況，最終采用方案三。服務器重啟情況經咨詢系統部門同事，不會出現自動重啟的情況，需要重啟幾率極小，確實需要重啟時可通知我們，由我們部署臨時的上行短信獲取服務，或者在半夜重啟。針對服務器宕機情況，另外開發監控服務，監控相關運行狀態，必要時通過行政手段通知短信平台暫停使用。