本發(fā)明涉及通信技術領域，特別是涉及一種應用消息推送方法和裝置。

背景技術：

隨著移動應用的迅速普及，為了保證用戶對移動應用的使用，對移動應用進行通知推送成為提升用戶活躍度的有效手段。目前，為了保證通知推送的實時性，需要維護客戶端與服務端之間的長連接，所謂長連接是指在一個連接上連續(xù)發(fā)送多個數(shù)據(jù)包，在客戶端與服務端之間創(chuàng)建和保持穩(wěn)定可靠的連接。在長連接中，客戶端通常采用長輪詢的方式，即服務端循環(huán)監(jiān)測數(shù)據(jù)，當監(jiān)測到數(shù)據(jù)更新時，立即輸出給客戶端并斷開連接，客戶端收到數(shù)據(jù)后再次發(fā)送請求，以使服務器進入下一個周期。在長連接中，服務端與每個客戶端都保持持久的連接。

因此，為了對移動應用進行實時通知推送，需要開啟大量的常駐服務器，但是通常對移動應用的通知推送最多也就一天一次，這樣將造成大量的服務器資源閑置，降低了服務器的利用率。

技術實現(xiàn)要素：

基于此，有必要針對上述問題，提供一種能夠降低服務端的資源需求，提高服務器的利用率的應用消息推送方法和裝置。

一種應用消息推送方法，包括：

接收終端定時輪詢上傳的消息推送請求，消息推送請求攜帶用戶標識；

根據(jù)消息推送請求檢測預設的消息數(shù)據(jù)庫中是否存在用戶標識對應的推送消息；

若是，則獲取推送消息并將推送消息發(fā)送至終端，以使終端對推送消息進行展示。

在其中一個實施例中，應用消息推送方法還包括：

根據(jù)預設時間內的系統(tǒng)日志獲取用戶活躍度，篩選出用戶活躍度大于預設活躍度的用戶作為活躍用戶；

根據(jù)預設篩選條件對活躍用戶進行篩選，將滿足預設條件的活躍用戶作為消息推送的目標用戶；

將目標用戶的用戶標識與推送消息相互關聯(lián)并存儲在消息數(shù)據(jù)庫中。

在其中一個實施例中，根據(jù)預設時間內的系統(tǒng)日志獲取用戶活躍度，篩選出用戶活躍度大于預設活躍度的用戶作為活躍用戶，包括：

獲取預設時間內系統(tǒng)日志中記錄的訪問頻次以及訪問時長；

根據(jù)訪問頻次以及訪問時長獲取用戶活躍度；

篩選出用戶活躍度大于預設活躍度的用戶作為活躍用戶。

在其中一個實施例中，根據(jù)預設篩選條件對活躍用戶進行篩選，將滿足預設篩選條件的活躍用戶作為消息推送的目標用戶，包括：

獲取活躍用戶對應的用戶標識及應用信息，應用信息包括應用的版本號、地區(qū)代碼、語言編號及活躍時間版本號、地區(qū)代碼、語言編號及活躍時間中的至少一種；

根據(jù)預設篩選條件對應用信息進行篩選，將滿足預設篩選條件的應用信息對應的活躍用戶作為消息推送的目標用戶。

在其中一個實施例中，應用消息推送方法還包括：

根據(jù)接收到的終端返回的推送成功的信息清除消息數(shù)據(jù)庫中的推送消息。

一種應用消息推送裝置，包括：

接收模塊，用于接收終端定時輪詢上傳的消息推送請求，消息推送請求攜帶用戶標識；

檢測模塊，用于根據(jù)消息推送請求檢測預設的消息數(shù)據(jù)庫中是否存在用戶標識對應的推送消息；

發(fā)送模塊，用于若檢測預設的消息數(shù)據(jù)庫中存在用戶標識對應的推送消息，則獲取推送消息并將推送消息發(fā)送至終端，以使終端對推送消息進行展示。

在其中一個實施例中，應用消息推送裝置還包括：

活躍用戶篩選模塊，用于根據(jù)預設時間內的系統(tǒng)日志獲取用戶活躍度，篩選出用戶活躍度大于預設活躍度的用戶作為活躍用戶；

目標用戶確定模塊，用于根據(jù)預設篩選條件對活躍用戶進行篩選，將滿足預設條件的活躍用戶作為消息推送的目標用戶；

消息存儲模塊，用于將目標用戶的用戶標識與推送消息相互關聯(lián)并存儲在消息數(shù)據(jù)庫中。

在其中一個實施例中，活躍用戶篩選模塊用于獲取預設時間內系統(tǒng)日志中記錄的訪問頻次以及訪問時長；根據(jù)訪問頻次以及訪問時長獲取用戶活躍度；篩選出用戶活躍度大于預設活躍度的用戶作為活躍用戶。

在其中一個實施例中，目標用戶確定模塊用于獲取活躍用戶對應的用戶標識及應用信息，應用信息包括應用的版本號、地區(qū)代碼、語言編號及活躍時間版本號、地區(qū)代碼、語言編號及活躍時間中的至少一種；根據(jù)預設篩選條件對應用信息進行篩選，將滿足預設篩選條件的應用信息對應的活躍用戶作為消息推送的目標用戶。

在其中一個實施例中，應用消息推送裝置還包括：

清除模塊，用于根據(jù)接收到的終端返回的推送成功的信息清除消息數(shù)據(jù)庫中的推送消息。

上述應用消息推送方法和裝置，根據(jù)終端定時輪詢上傳的消息推送請求以及攜帶的用戶標識在消息數(shù)據(jù)庫中檢測用戶標識對應的推送消息，獲取推送消息發(fā)送至終端以使終端進行展示，完成應用消息推送的過程。通過終端定時輪詢發(fā)送消息推送請求，服務器不需要一直與終端建立持久的連接，只需要在終端發(fā)送消息推送請求時進行響應，降低對服務端的資源要求，通過設置終端輪詢發(fā)送消息推送請求的時間間隔，能夠達到只使用少量服務器即可滿足用戶訪問的需求，提高了服務器的利用率。

附圖說明

圖1為一個實施例中應用消息推送方法流程圖；

圖2為一個實施例中服務端生成應用推送消息的步驟的流程圖；

圖3為一個實施例中獲取活躍用戶的步驟流程圖；

圖4為另一個實施例中應用消息推送方法流程圖；

圖5為一個實施例中應用消息推送裝置的結構框圖；

圖6為一個實施例中應用消息推送裝置的結構框圖；

圖7為另一個實施例中應用消息推送裝置的結構框圖。

具體實施方式

為了使本發(fā)明的目的、技術方案及優(yōu)點更加清楚明白，以下結合附圖及實施例，對本發(fā)明進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

如圖1所示，在一個實施例中，提供一種應用消息推送方法，包括以下步驟：

步驟110，接收終端定時輪詢上傳的消息推送請求，消息推送請求攜帶用戶標識。

本實施例中，預先在應用中設置定時輪詢機制，定時輪詢是指每隔預設時間發(fā)出一次請求。當終端中某個應用在運行時，啟動定時輪詢機制，終端每隔預設時間向正在運行的應用對應的服務器的消息推送接口發(fā)送一次消息推送請求。

通過消息推送接口接收終端發(fā)送的消息推送請求，消息推送請求攜帶用戶標識，這里所說的用戶標識可以是根據(jù)終端系統(tǒng)信息生成的唯一標識符如udid，也可以是登錄應用的賬號信息對應的id。這里的終端可以但不僅限于是手機、平板電腦、可穿戴設備等移動終端或者其他可運行應用的設備。

步驟120，根據(jù)消息推送請求檢測預設的消息數(shù)據(jù)庫中是否存在用戶標識對應的推送消息，若是，則執(zhí)行步驟130。

本實施例中，服務端在特定的時間對推送消息進行更新，并且將更新的推送消息與用戶標識相互關聯(lián)存儲在消息數(shù)據(jù)庫中。當接收到終端的消息推送請求后，服務端查詢消息數(shù)據(jù)庫，即將推送消息攜帶的用戶標識與消息數(shù)據(jù)庫中的用戶標識相互匹配，若匹配不成功，則說明用戶標識對應的應用沒有相關聯(lián)的推送消息，服務器斷開與終端的連接關系，若匹配成功，則說明用戶標識對應的應用存在相關聯(lián)的推送消息，執(zhí)行步驟130。

步驟130，獲取推送消息并將推送消息發(fā)送至終端，以使終端對推送消息進行展示。

本實施例中，當在消息數(shù)據(jù)庫中匹配到與終端發(fā)送的消息推送請求攜帶的用戶標識一致的用戶標識時，獲取該用戶標識相關聯(lián)的推送消息并發(fā)送至用戶標識對應的終端，以使終端對推送消息進行展示。這里所說的推送消息可以為應用的優(yōu)化更新信息、版本變更信息、活動推送信息等各種通知信息，或其他推廣信息如公益宣傳廣告信息等。該推送消息可以在服務端預先編輯定義，因此能夠避免不良信息或者大量廣告信息的推送。終端對推送消息的展示方式可以是但不僅限于是通知欄展示、彈窗展示、鎖屏展示。

上述應用消息推送方法，服務器只需要對終端定時發(fā)送的消息推送請求進行響應，獲取對應的推送消息傳輸至終端即可完成對推送消息的推送過程，不需要服務器一直與終端保持連接，不斷監(jiān)測數(shù)據(jù)更新發(fā)送至終端，因此，降低了對服務器資源的需求，使少量的服務器就能滿足基本的用戶需求，提高了服務器的使用率。

在一個實施例中，應用消息推送方法還包括終端生成推送消息的步驟，如圖2所示，包括以下步驟：

步驟210，根據(jù)預設時間內的系統(tǒng)日志獲取用戶活躍度，篩選出用戶活躍度大于預設活躍度的用戶作為活躍用戶。

本實施例中，為了提高推送的效率，僅對近期的活躍用戶進行消息推送，活躍用戶指近期經(jīng)常使用應用的用戶，可以利用用戶活躍度來確定活躍用戶。在使用應用時，終端應用對服務器的數(shù)據(jù)請求被記錄在系統(tǒng)日志中，系統(tǒng)日志是指記錄系統(tǒng)中硬件、軟件和系統(tǒng)問題的信息，同時還可以監(jiān)視系統(tǒng)中發(fā)生的事件。通過獲取預設時間內的系統(tǒng)日志，獲取預設時間內的用戶活躍度，預先根據(jù)數(shù)據(jù)分析或產品需求設置預設活躍度，獲取的預設時間內的用戶活躍度大于該預設活躍度的應用對應的用戶標識即為活躍用戶對應的用戶標識。

步驟220，根據(jù)預設篩選條件對活躍用戶進行篩選，將滿足預設篩選條件的活躍用戶作為消息推送的目標用戶。

本實施例中，為了進一步提升推送的效率，設置篩選條件對獲取的活躍用戶再次進行篩選，將滿足預設篩選條件的活躍用戶為消息推送的目標用戶。

具體的，對于相同的應用，不同的用戶的需求可能不同，因此為了進一步提高推送的效率，設置篩選條件針對不同的用戶推送不同的消息。如一款提供新聞閱讀的應用，對于不同的用戶對新聞種類的需求不同，如一部分用戶比較關注金融類信息，另外一部分用戶比較關注娛樂消息，如果現(xiàn)在有一則金融類相關的消息需要推送，則首先設置篩選條件為預設時間內訪問過金融類相關信息，對獲取的活躍用戶進行篩選，符合該篩選條件的活躍用戶即為該金融類相關信息推送的目標用戶。

步驟230，將目標用戶的用戶標識與推送消息相互關聯(lián)并存儲在消息數(shù)據(jù)庫中。

本實施例中，為了能夠為對應的終端提供對應的推送消息，在獲取目標用戶后，獲取目標用戶對應的用戶標識，將推送消息與目標用戶的用戶標識相互關聯(lián)并存儲在消息數(shù)據(jù)庫中。當接收到終端發(fā)送的消息推送請求時，即可根據(jù)該關聯(lián)關系在消息數(shù)據(jù)庫中查詢用戶標識對應的推送消息。

本實施例中，通過系統(tǒng)日志獲取預設時間內的活躍用戶，并根據(jù)不同的推送消息設置不同的篩選條件，在活躍用戶中進一步獲取推送消息的目標用戶，最后將推送消息與目標用戶的用戶標識建立關聯(lián)存儲在消息數(shù)據(jù)庫中，能夠針對不同的用戶需求推送不同的消息，有效的提高了推送的效率。

如圖3所示，在一個實施例中，根據(jù)預設時間內的系統(tǒng)日志獲取用戶活躍度，篩選出用戶活躍度大于預設活躍度的用戶作為活躍用戶，包括：

步驟310，獲取預設時間內系統(tǒng)日志中記錄的訪問頻次以及訪問時長。

本實施例中，訪問頻次是指預定時間內用戶使用應用的頻率和次數(shù)，訪問時長是指用戶每次使用應用的時長。由于用戶每次使用應用均會在服務端產生訪問記錄，記錄在系統(tǒng)日志中，因此對系統(tǒng)日志進行分析，能夠獲取對應用戶預設時間內使用應用的頻次和時長。

步驟320，根據(jù)訪問頻次以及訪問時長獲取用戶活躍度。

本實施例中，用戶活躍度可以用訪問頻次和訪問時長進行衡量，預先根據(jù)數(shù)據(jù)分析或者產品需求設置一個活躍度，將預設的活躍度作為衡量是否為活躍用戶的標準。每天定時對前一日系統(tǒng)日志進行分析，獲取前一日系統(tǒng)日志中的訪問頻次及訪問時長，從而獲取每日用戶活躍度，同時獲取預設時間內的系統(tǒng)日志獲取預設時間內的用戶活躍度，根據(jù)每日用戶活躍度與預設時間內的用戶活躍度獲取對應的用戶活躍度。

步驟330，篩選出用戶活躍度大于預設活躍度的用戶作為活躍用戶。

本實施例中，將獲取的用戶活躍度與預設的活躍度進行比較，篩選出用戶活躍度大于預設的活躍度的用戶標識，則篩選出的用戶標識對應的用戶即為活躍用戶。具體的，可以通過設置活躍度使在預設時間內使用了應用的用戶就判斷為活躍用戶，此時只需要對預設時間內的系統(tǒng)日志進行遍歷，獲取系統(tǒng)日志中記錄的用戶標識，對獲取的用戶標識進行去重操作即可獲取活躍用戶對應的用戶標識列表。

在一個實施例中，根據(jù)預設篩選條件對活躍用戶進行篩選，將滿足預設篩選條件的活躍用戶作為消息推送的目標用戶，包括：

獲取活躍用戶對應的用戶標識及應用信息，應用信息包括應用的版本號、地區(qū)代碼、語言編號及活躍時間中的至少一種；

根據(jù)預設篩選條件對應用信息進行篩選，將滿足預設篩選條件的應用信息對應的活躍用戶作為消息推送的目標用戶。

本實施例中，為了提高推送效率，對活躍用戶進行進一步篩選獲取推送的目標用戶。具體的，系統(tǒng)日志中記載了用戶使用應用對服務端進行訪問時的應用信息以及對應的用戶標識，應用信息包括應用的版本號、地區(qū)代碼、語言編號及活躍時間中的至少一種。當編寫推送消息時，根據(jù)推送消息的具體內容，通過應用信息的任意組合設置合適的篩選條件，獲取對應的目標用戶標識。比如檢測到一個應用版本號5之前的版本存在重大的漏洞，此時需要編寫一個通知推送給對應的用戶，此時以版本號為篩選條件，版本號為5或者以下的應用對應的用戶標識為該推送消息的目標用戶標識；再如若版本號5之前的英文版本存在問題而中文版本不存在問題，則篩選條件即為英文和版本號為5或以下的應用對應的用戶標識為該篩選條件對應的目標用戶標識。

在一個實施例中，應用消息推送方法還包括：根據(jù)接收到的終端返回的推送成功的信息清除消息數(shù)據(jù)庫中的推送消息。

本實施例中，當服務器將獲取的用戶標識對應的推送消息發(fā)送至終端時，終端對接收到的推送消息進行展示，展示完成后返回推送成功的消息至服務器，該消息同樣攜帶用戶標識，服務器接收到該推送成功的消息后，根據(jù)攜帶的用戶標識在消息數(shù)據(jù)庫中查找到該用戶標識對應的推送消息，并將該推送消息清除。

本實施例中，當終端接收到推送消息并成功展示后，服務器接收終端返回的推送成功的信息，對用戶標識對應的推送消息進行清除，有效的避免了消息重復推送，提高了推送的效率。

如圖4所示，在一個實施例中，提供一種應用消息推送方法，包括以下步驟：

步驟410，獲取預設時間內系統(tǒng)日志中記錄的訪問頻次以及訪問時長，根據(jù)訪問頻次以及訪問時長獲取用戶活躍度，篩選出用戶活躍度大于預設活躍度的用戶作為活躍用戶。

本實施例中，為了提高推送消息的效率，僅針對近期的活躍用戶進行消息推送，為了篩選出活躍用戶可以預先設置活躍度作為評價用戶是否為活躍用戶的標準。系統(tǒng)日志是指記錄系統(tǒng)中硬件、軟件和系統(tǒng)問題的信息，同時還可以監(jiān)視系統(tǒng)中發(fā)生的事件。獲取預設時間內系統(tǒng)日志中監(jiān)視應用訪問的記錄，即獲取系統(tǒng)日志中應用的訪問頻次和訪問時長，從而根據(jù)訪問頻次和訪問時長獲取用戶活躍度，將根據(jù)系統(tǒng)日志獲取的用戶活躍度與預設活躍度相比較，用戶活躍度大于預設活躍度的應用對應的用戶標識即為活躍用戶對應的用戶標識。

具體的，為了方便對活躍用戶進行篩選，設置活躍度的衡量標準為前一日對應用進行了使用，即服務器每天定時對前一日的系統(tǒng)日志進行分析，只要滿足在服務器分析的系統(tǒng)日志中有使用應用的記錄，就認為該應用對應的用戶標識為活躍用戶標識。當用戶主動使用應用的某個功能時，服務端觸發(fā)該功能對應的服務器端的api(applicationprogramminginterface，應用程序編程接口)調用，此時只需要遍歷系統(tǒng)日志中的api請求日志就可以獲得活躍用戶對應的用戶標識。例如，用戶標識為系統(tǒng)信息生成的udid值，此時首先使用linuxgrep命令，定時對前一日的系統(tǒng)日志進行篩選，篩選出用戶使用應用產生的api請求日志，該請求日志中包含udid參數(shù)，然后使用linux命令awk，將udid參數(shù)抽取出來保存到一個文件中，每一行對應一個udid。由于用戶可能一天多以使用應用或者使用了應用的不同功能，因此此時抽取出的udid參數(shù)存在重復，對該保存udid參數(shù)的文件使用linuxsort命令，然后使用linuxuniq命令，就得到去除重復之后的活躍用戶的udid列表。

步驟420，獲取活躍用戶對應的用戶標識及應用信息，并將用戶標識與應用信息存儲在數(shù)據(jù)庫中。

本實施例中，獲取活躍用戶的用戶標識后，在系統(tǒng)日志中獲取對應的應用信息，應用信息包括應用的版本號、地區(qū)代碼、語言編號及活躍時間等至少一種。將應用信息與用戶標識相關聯(lián)并存儲在數(shù)據(jù)庫中，以便后續(xù)操作。

具體的，以mysql(關系型數(shù)據(jù)庫管理系統(tǒng))為例，mysql是一種關聯(lián)數(shù)據(jù)庫管理系統(tǒng)，關聯(lián)數(shù)據(jù)庫將數(shù)據(jù)保存在不同的表中。這里的用戶標識可以用終端系統(tǒng)信息生成的udid值表示，不同的udid值對應不同的終端及不同的應用信息。經(jīng)過篩選、去重操作之后獲取udid列表，獲取該udid列表中的udid對應的應用信息，并將udid列表及對應的應用信息存儲到mysql數(shù)據(jù)庫的user表中。

在其他實施例中，如果每日的用戶訪問量較多，還可以使用數(shù)據(jù)倉庫對用戶標識和對應的應用信息進行存儲，更加適合批量增加和條件查詢的場景。這里所說的數(shù)據(jù)倉庫是指一個面向主題的(subjectoriented)、集成的(integrated)、相對穩(wěn)定的(non-volatile)、反映歷史變化(timevariant)的數(shù)據(jù)集合，用于支持管理決策(decisionmakingsupport)。

步驟430，根據(jù)預設篩選條件對應用信息進行篩選，將滿足預設篩選條件的應用信息對應的活躍用戶作為消息推送的目標用戶。

本實施例中，為了進一步提高推送效率，預先在數(shù)據(jù)庫中根據(jù)應用信息設置篩選條件，對存儲的活躍用戶對應的應用信息進行篩選，將滿足預設的篩選條件的應用信息對應的用戶標識作為消息推送的目標用戶標識。

具體的，應用信息包括應用的版本號、地區(qū)代碼、語言編號及活躍時間中的至少一種。對于不同版本號的應用需要不同的升級信息；推送的消息根據(jù)地區(qū)的不同內容有所不同，如一款預報天氣的應用，對于不同的地區(qū)需要針對當?shù)氐那闆r進行信息推送；針對應用活躍時間推送不同的消息，如一款音樂服務的應用，針對用戶的活躍時間推薦不同類型的音樂等，因此針對不同的推送消息的具體內容，預先根據(jù)應用的版本號、地區(qū)代碼、語言編號及活躍時間中的至少一種設置篩選條件，在活躍用戶對應的用戶標識中獲取對應的目標用戶的用戶標識。如以mysql為例，當根據(jù)系統(tǒng)日志獲取對應的活躍用戶的用戶標識以及對應的應用信息，并存儲在mysql數(shù)據(jù)庫的user表中后，通過sql設置篩選條件對user表進行篩選，得到目標用戶對應的用戶標識的集合。

步驟440，將目標用戶的用戶標識與推送消息相互關聯(lián)并存儲在消息數(shù)據(jù)庫中。

本實施例中，確定推送消息的目標用戶之后，將推送消息的具體消息與目標用戶對應的用戶標識相互關聯(lián)，并存儲在消息數(shù)據(jù)庫中，便于根據(jù)終端的請求信息攜帶的用戶標識對相應的推送消息進行查詢。

具體的，以redis數(shù)據(jù)庫為例，redis是一個開源的使用ansic語言編寫、支持網(wǎng)絡、可基于內存亦可持久化的日志型、key-value數(shù)據(jù)庫，并提供多種語言的api。當獲取到目標用戶對應的用戶標識的集合后，用戶標識用udid值表示，獲取目標用戶對應的udid列表中的每一個udid值，并將每一個udid值分別與編寫的推送消息相互關聯(lián)，保存在以udid為key的redis數(shù)據(jù)庫列表中。redis數(shù)據(jù)庫的數(shù)據(jù)模型為key-value模式，當以udid為key保存時，支持udid的存取，并且推送消息以udid為標識。

以nosql(notonlysql，泛指非關系型的數(shù)據(jù)庫)為例，nosql是通過主鍵對數(shù)據(jù)進行查詢。獲取目標用戶對應的udid列表之后，獲取udid列表中的每一個udid值，并將udid值分別與推送消息相互關聯(lián)，保存在一個列表中，將udid為表的主鍵。

步驟450，接收終端定時輪詢上傳的消息推送請求，消息推送請求攜帶用戶標識，根據(jù)消息推送請求攜帶的用戶標識檢測預設的消息數(shù)據(jù)庫中是否存在用戶標識對應的推送消息。

本實施例中，預先在應用中設置定時輪詢機制，當終端運行該應用時，觸發(fā)定時輪詢機制，定時輪詢服務器的消息推送接口并發(fā)送消息推送請求，消息推送請求攜帶用戶標識，服務器接收終端發(fā)送的消息推送請求后，通過在消息數(shù)據(jù)庫中檢測是否存在相同的用戶標識，檢測是否存在用戶標識對應的推送消息。

具體的，如以終端系統(tǒng)信息生成的udid值為用戶標識，服務器接收到終端上傳的消息推送請求時，獲取消息推送請求攜帶的udid，查詢redis數(shù)據(jù)庫中以udid為key的列表，此時udid作為調用服務器api的參數(shù)，是推送消息的標識，查找到對應的udid即說明redis數(shù)據(jù)庫中有與該udid相關聯(lián)的推送消息。

同樣的，若推送消息存儲在nosql數(shù)據(jù)庫中，則udid作為主鍵查詢nosql中的以udid為主鍵的表格，若有相同的udid則說明nosql數(shù)據(jù)庫中對應的推送的消息需要推送至該udid對應的應用終端。

步驟460，當檢測到存在用戶標識對應的推送消息時，獲取推送消息并將推送消息發(fā)送至終端，以使終端對推送消息進行展示。

本實施例中，由于在消息數(shù)據(jù)庫中用戶標識與推送消息相關聯(lián)，若在消息數(shù)據(jù)庫中檢測到了消息推送請求攜帶的用戶標識相同的用戶標識，則說明存在與推送請求攜帶的用戶標識對應的推送消息，獲取與該用戶標識相關聯(lián)的推送消息并發(fā)送至終端，以使終端對推送消息進行展示。

具體的，如以終端系統(tǒng)信息生成的udid值為用戶標識，以udid為key在redis數(shù)據(jù)庫中查找到了相同的udid，則獲取與該udid相關聯(lián)的推送消息，則該推送消息推送至終端，使終端對該推送消息進行展示，如在通知欄展示、彈窗展示、鎖屏展示等，以使用戶看到該推送消息進行相應操作。

步驟470，根據(jù)接收到的終端返回的推送成功的信息清除消息數(shù)據(jù)庫中的推送消息。

本實施例中，本實施例中，當服務器將獲取的用戶標識對應的推送消息發(fā)送至終端時，終端對接收到的推送消息進行展示，展示完成后返回推送成功的消息至服務器，該消息同樣攜帶用戶標識，服務器接收到該推送成功的消息后，根據(jù)攜帶的用戶標識在消息數(shù)據(jù)庫中查找到該用戶標識對應的推送消息，并將該推送消息清除。

具體的，當服務端對終端以udid為標識向服務端消息推送接口發(fā)送的消息推送請求進行相應，并在redis或者nosql數(shù)據(jù)庫中查找到對應的推送消息發(fā)送至終端后，終端對該推送消息進行展示，并返回攜帶該udid的推送成功信息至服務端，服務端根據(jù)該udid在redis或者nosql數(shù)據(jù)庫中查找到對應的推送消息，將該推送消息清除，避免重復推送。

本實施例中，服務端定時分析系統(tǒng)日志以確定目標用戶，并將目標用戶的用戶標識與推送消息的具體信息關聯(lián)存儲在消息數(shù)據(jù)庫中，為消息推送做準備。當接收到終端發(fā)送的消息推送的請求時，根據(jù)推送請求攜帶的用戶標識在消息數(shù)據(jù)庫中查找對應的用戶標識，從而獲取對應的推送消息進行推送，推送成功后根據(jù)終端的返回信息，清除已經(jīng)推送成功的推送消息。通過終端定時輪詢發(fā)送請求獲取服務端的推送消息，不需要服務端一直與終端保持聯(lián)系，通過設置定時輪詢的時間間隔，能夠合理的利用服務端資源，并且建立反饋機制，避免重復推送進一步降低了對服務端的資源需求，提高服務器的使用率。

如圖5所示，在一個實施例中，提供一種應用消息推送裝置，包括：

接收模塊510，用于接收終端定時輪詢上傳的消息推送請求，消息推送請求攜帶用戶標識；

檢測模塊520，用于根據(jù)消息推送請求檢測預設的消息數(shù)據(jù)庫中是否存在用戶標識對應的推送消息；

發(fā)送模塊530，用于若檢測預設的消息數(shù)據(jù)庫中存在用戶標識對應的推送消息，則獲取推送消息并將推送消息發(fā)送至終端，以使終端對推送消息進行展示。

上述應用消息推送裝置，通過接收終端定時輪詢上傳的消息推送請求，根據(jù)消息推送請求攜帶的用戶標識在消息數(shù)據(jù)庫中查詢對應的推送消息，并將推送消息發(fā)送至用戶標識對應的終端以對推送消息進行展示。服務器只需要接收終端定時上傳的推送消息請求并進行響應，不需要一直與終端建立持久的連接，降低了對服務資源的要求，達到使用少量服務器就能夠滿足用戶需求，提高了服務器的利用率。

如圖6所示，在一個實施例中，提供一種應用消息推送裝置，包括：

活躍用戶篩選模塊610，用于根據(jù)預設時間內的系統(tǒng)日志獲取用戶活躍度，篩選出用戶活躍度大于預設活躍度的用戶作為活躍用戶；

目標用戶確定模塊620，用于根據(jù)預設篩選條件對活躍用戶進行篩選，將滿足預設條件的活躍用戶作為消息推送的目標用戶；

消息存儲模塊630，用于將目標用戶的用戶標識與推送消息相互關聯(lián)并存儲在消息數(shù)據(jù)庫中。

在一個實施例中，活躍用戶篩選模塊610用于獲取預設時間內系統(tǒng)日志中記錄的訪問頻次以及訪問時長；根據(jù)訪問頻次以及訪問時長獲取用戶活躍度；篩選出用戶活躍度大于預設活躍度的用戶作為活躍用戶。

在一個實施例中，目標用戶確定模塊620用于獲取活躍用戶對應的用戶標識及應用信息，應用信息包括應用的版本號、地區(qū)代碼、語言編號及活躍時間中的至少一種；根據(jù)預設篩選條件對應用信息進行篩選，將滿足預設篩選條件的應用信息對應的活躍用戶作為消息推送的目標用戶。

如圖7所示，在一個實施例中，應用消息推送裝置還包括：

清除模塊540，用于根據(jù)接收到的終端返回的推送成功的信息清除消息數(shù)據(jù)庫中的推送消息。

以上所述實施例的各技術特征可以進行任意的組合，為使描述簡潔，未對上述實施例中的各個技術特征所有可能的組合都進行描述，然而，只要這些技術特征的組合不存在矛盾，都應當認為是本說明書記載的范圍。

以上所述實施例僅表達了本發(fā)明的幾種實施方式，其描述較為具體和詳細，但并不能因此而理解為對發(fā)明專利范圍的限制。應當指出的是，對于本領域的普通技術人員來說，在不脫離本發(fā)明構思的前提下，還可以做出若干變形和改進，這些都屬于本發(fā)明的保護范圍。因此，本發(fā)明專利的保護范圍應以所附權利要求為準。