本申請涉及通信中的短信發送領域，具體的，涉及一種能夠根據客戶的具體情況，根據用戶的各種需求發送相應短信內容的自定義短信發送系統。

背景技術：

目前，短信發送系統主要分為三種：固定的用戶群，該類型是直接把短信發送到固定的一批用戶；固定的短信內容，該類型是預先設置好短信內容，向用戶發送一致的短信內容；固定的發送時間點，該類型是發送短信的觸發時間點一般固定，同一時間進行發送。

上述的短信發送系統具有一定的缺點。固定的用戶群，該類型向固定的用戶群發送短信，有一定的引導性，但對短信內容沒有需求的人，這條短信就是垃圾短信，甚至是騷擾短信，用戶體驗差，針對性不強。固定的短信內容，該類型發送內容一致的短信，一般也是引導性的短信，對于靈活性的場景達不到相應的要求，不同的用戶可能需要不同的短信內容，需要有一定的區別。固定的發送時間點，該類型的短信同一時間點發送，沒有實效性，有時用戶對短信有一定的時效性要求，固定時間點發送短信就滿足不了用戶的要求。

上述的短信發送系統都有著一定的缺點，如何能夠根據用戶的需求，根據用戶的具體情況發送相應短信內容成為現有技術亟需解決的技術問題。

技術實現要素：

本發明的目的在于提出一種自定義短信發送系統，能夠根據用戶的各種需求發送相應短信內容的自定義短信系統。

為達此目的，本發明采用以下技術方案：

一種自定義短信發送系統，包括短信自定義服務器1，查詢交易服務器2、事件登記服務器3、和短信發送服務器4，

其中查詢交易服務器2，用于商品信息查詢、下單、支付的各類操作，還是訂單中心，包含有訂單信息，訂單支付信息和訂單配送信息，并且能夠為其它系統提供訂單信息查詢的功能；

事件接收與分發服務器3，用于接收交易服務器發送的各種事件(如下單、支付)，并將事件分發到監聽服務器，如短信自定義服務器1；

短信自定義服務器1，用于自定義各類短信內容，監聽事件接收與分發服務器3所分發的各種事件，并向所述查詢交易服務器2獲取所述事件的具體信息，并根據所述具體信息，與各類短信模板進行匹配，從而生成具體的信息，并將所述具體的信息發送到所述短信發送服務器4；

所述短信發送服務器4，用于發送所接收到的具體的信息。

進一步的，所述事件的具體信息還包括用戶的基本信息，所述與各類短信模板進行匹配為：根據項目、場館、供應商和合作方的順序依次對短信模板進行匹配。

更進一步的，在匹配中，如果匹配到對應的短信模板，則使用該模板，否則，則使用默認的模板，然后生成相應的短信內容。

進一步的，所述短信自定義服務器1，包括短信自定義后臺服務器11，短信定制服務器12，和短信定制數據庫13，

所述短信自定義后臺服務器11，用于監聽事件接收與分發服務器3所分發的各種事件，并向所述查詢交易服務器2獲取所述事件的具體信息，并根據所述具體信息，與所述短信定制數據庫13保存的各類短信模板進行匹配，從而生成具體的信息，并將所述具體的信息發送到所述短信發送服務器4。

所述短信定制服務器12，用于編輯定制各種短信模板，并所述各類短信模板保存在所述短信定制數據庫13中。

所述短信定制數據庫13，用于保存所述的各類短信模板，并供所述短信自定義后臺服務器11根據所查詢到的具體信息進行匹配；示例性的，所述短信定制數據庫13可以為Mysql數據庫。

更進一步的，查詢交易服務器2包括交易服務器21和CRM服務器22。

所述交易服務器21，用于為查詢商品信息、下單、支付的各種操作提供服務，并可以為其它系統提供查詢訂單信息的功能。其中所述商品可以為票務，即成為一種購票流程服務器。

所述CRM服務器22，用于客戶關系的管理，能夠為訂單中心，包括訂單信息，訂單支付信息和訂單配送信息，并為其它系統提供查詢訂單信息的功能。

所述事件接收與分發服務器3，為高吞吐量的分布式發布訂閱消息系統，能夠處理消費者規模的網站中的所有動作流數據，類似于處理消息隊列，如activeMQ。示例性的，可以為Kafka。

具有查錯輪詢服務器5，在短信自定義后臺服務器11向所述查詢交易服務器2，即分別向交易服務器21和CRM服務器22查詢各種訂單的信息數據時，如果發生異常，則記錄該異常的訂單信息，并后續進行輪詢訂單數據，當所述輪詢達到一定的次數還未成功時，例如6次，則記錄并進行異常處理。也就是說，查錯輪詢服務器5每10秒鐘輪詢一次，6次就1分鐘，如果是短信自定義后臺服務器11查詢過程中的系統延，一分鐘就能夠克服系統延時，查詢到相關信息了，超過一分鐘則說明是異常情況。

進一步的，所述查錯輪詢服務器5包括查錯輪詢數據庫51和郵件服務器52，在短信自定義后臺服務器11向所述查詢交易服務器2，即分別向交易服務器21和CRM服務器22查詢各種訂單的信息數據時，如果發生異常，則將該異常的訂單信息記錄在查錯輪詢數據庫51中，并后續進行輪詢訂單數據，當所述輪詢達到一定的次數還未成功時，則說明出現了異常，則通過郵件服務器52發郵件到相應的維護和開發人員處，以進行異常處理。

查錯輪詢數據庫51可以采用Redis數據庫。

本發明可以根據業務人員的需求，自行編輯訂制各類短信模板，利用Kafka分布式發布訂閱消息系統可以及時處理下單與支付事件；用戶可以收到訂制的短信，不再是單一的內容；用戶在下單與支付成功后，可以及時收到所需的短信，幾乎沒有延時；并且有了輪詢機制與郵件報警機制，系統更加穩健。

附圖說明

圖1是根據本發明的自定義短信發送系統的模塊圖；

圖2是根據本發明的自定義短信發送系統的一個具體實施方式的模塊圖。

圖中的附圖標記所分別指代的技術特征為：

1、短信自定義服務器；2、查詢交易服務器；3、事件接收與分發服務器；4、短信發送服務器；5、查錯輪詢服務器；12、短信自定義后臺服務器；13、短信定制數據庫；21、交易服務器；22、CRM服務器；11、短信定制服務器；51、查錯輪詢數據庫；52、郵件服務器。

具體實施方式

下面結合附圖和實施例對本發明作進一步的詳細說明。可以理解的是，此處所描述的具體實施例僅僅用于解釋本發明，而非對本發明的限定。另外還需要說明的是，為了便于描述，附圖中僅示出了與本發明相關的部分而非全部結構。

參見圖1，示出了根據本發明的自定義短信發送系統，包括短信自定義服務器1，查詢交易服務器2、事件登記服務器3、和短信發送服務器4，

其中查詢交易服務器2，用于商品信息查詢、下單、支付的各類操作，還是訂單中心，包含有訂單信息，訂單支付信息和訂單配送信息，并且能夠為其它系統提供訂單信息查詢的功能；

事件接收與分發服務器3，用于接收交易服務器發送的各種事件，如下單、支付等，并將上述事件分發到監聽服務器上，如短信自定義服務器1。

短信自定義服務器1，用于自定義各類短信內容，監聽事件接收與分發服務器3所分發的各種事件，并向所述查詢交易服務器2獲取所述事件的具體信息，并根據所述具體信息，與各類短信模板進行匹配，從而生成具體的信息，并將所述具體的信息發送到所述短信發送服務器4；

所述短信發送服務器4，用于發送所接收到的具體的信息。

因此，在本發明中，可以利用短信自定義服務器根據訂單的具體的情況來自定義各種短信模板，從而能夠根據訂單的具體情況進行匹配。

具體的，所述事件的具體信息還包括用戶的基本信息，所述與各類短信模板進行匹配為：根據項目、場館、供應商和合作方的順序依次對短信模板進行匹配。

更進一步的，在匹配中，如果匹配到對應的短信模板，則使用該模板，否則，則使用默認的模板，然后生成相應的短信內容。

更進一步的，參見圖2中，所述短信自定義服務器1，包括短信自定義后臺服務器11，短信定制服務器12，和短信定制數據庫13，

所述短信自定義后臺服務器11，用于監聽事件接收與分發服務器3所分發的各種事件，并向所述查詢交易服務器2獲取所述事件的具體信息，并根據所述具體信息，與所述短信定制數據庫13保存的各類短信模板進行匹配，從而生成具體的信息，并將所述具體的信息發送到所述短信發送服務器4。

所述短信定制服務器12，用于編輯定制各種短信模板，并所述各類短信模板保存在所述短信定制數據庫13中，因此，業務人員能夠根據業務的需要編輯定制各種短信模板，示例性的，該短信定制服務器12可以采用Web服務器的方式。

所述短信定制數據庫13，用于保存所述的各類短信模板，并供所述短信自定義后臺服務器11根據所查詢到的具體信息進行匹配；示例性的，所述短信定制數據庫13可以為Mysql數據庫。

更進一步的，查詢交易服務器2包括交易服務器21和CRM服務器22。

所述交易服務器21，用于為查詢商品信息、下單、支付的各種操作提供服務，并可以為其它系統提供查詢訂單信息的功能。其中所述商品可以為票務，即成為一種購票流程服務器。

所述CRM服務器22，用于客戶關系的管理，能夠為訂單中心，包括訂單信息，訂單支付信息和訂單配送信息，并為其它系統提供查詢訂單信息的功能。

即，將所述查詢交易功能分解為購票過程，以及購票之后的訂單管理，從而實現功能的模塊化布置，以減少服務器的壓力，降低開發成本。短信自定義后臺服務器11可以分別向交易服務器21和CRM服務器22查詢各種訂單的信息數據。

進一步的，所述事件接收與分發服務器3，為高吞吐量的分布式發布訂閱消息系統，能夠處理消費者規模的網站中的所有動作流數據，類似于處理消息隊列，如activeMQ。示例性的，可以為Kafka。

因此，交易服務器與CRM服務器有下單與支付行為時，可以實時向Kafka發送下單與支付事件，而Kafka向短信自定義后臺服務器11及時發送訂閱的下單與支付事件。

進一步的，還具有查錯輪詢服務器5，在短信自定義后臺服務器11向所述查詢交易服務器2，即分別向交易服務器21和CRM服務器22查詢各種訂單的信息數據時，如果發生異常，則記錄該異常的訂單信息，并后續進行輪詢訂單數據，當所述輪詢達到一定的次數還未成功時，例如6次，則記錄并進行異常處理。也就是說，查錯輪詢服務器5每10秒鐘輪詢一次，6次就1分鐘，如果是短信自定義后臺服務器11查詢過程中的系統延，一分鐘就能夠克服系統延時，查詢到相關信息了，超過一分鐘則說明是異常情況。

進一步的，所述查錯輪詢服務器5包括查錯輪詢數據庫51和郵件服務器52，在短信自定義后臺服務器11向所述查詢交易服務器2，即分別向交易服務器21和CRM服務器22查詢各種訂單的信息數據時，如果發生異常，則將該異常的訂單信息記錄在查錯輪詢數據庫51中，并后續進行輪詢訂單數據，當所述輪詢達到一定的次數還未成功時，則說明出現了異常，則通過郵件服務器52發郵件到相應的維護和開發人員處，以進行異常處理。

查錯輪詢數據庫51可以采用Redis數據庫，它是一個開源的使用ANSI C語言編寫、支持網絡、可基于內存亦可持久化的日志型、Key-Value數據庫，查詢速度比較快。

因此，本發明還為異常處理增加了Redis輪詢機制與郵件報警機制，使得系統更加穩健。

因此，本發明可以根據業務人員的需求，自行編輯訂制各類短信模板，利用Kafka分布式發布訂閱消息系統可以及時處理下單與支付事件；用戶可以收到訂制的短信，不再是單一的內容；用戶在下單與支付成功后，可以及時收到所需的短信，幾乎沒有延時；并且有了輪詢機制與郵件報警機制，系統更加穩健。

以上內容是結合具體的優選實施方式對本發明所作的進一步詳細說明，不能認定本發明的具體實施方式僅限于此，對于本發明所屬技術領域的普通技術人員來說，在不脫離本發明構思的前提下，還可以做出若干簡單的推演或替換，都應當視為屬于本發明由所提交的權利要求書確定保護范圍。