移動裝置獲得通知的兩種方式

1. 隨著移動網際網路的發展，越來越多的移動端應用得到普及，此處的移動端不僅僅限於手機，還有很多裝置也參與到移動互聯中來。比較典型如微軟的xbox等，這些裝置上執行的應用都需要具有一定的訊息通知功能。那麼訊息是如何從應用的服務端到達應用終端，也就是各種移動裝置上呢？目前，移動端獲得訊息通知主要有兩種方式：pull(拉)方式和push(推)方式，下面分別對這兩種方式做簡要介紹。

   • pull方式

     • pull方式即“拉方式”，這種方式中手機上的應用程式在啟動時及經過一定週期會定時連線應用的服務端來獲得伺服器需要傳遞給終端的訊息，因為此處是終端從服務端主動獲得訊息，因此稱為拉方式。
       此方式服務端實現簡單，只需要在終端連線上之後把需要傳送的訊息傳送給終端即可，但是此方式有如下弊端：

       1. 每個應用終端都需要建立到自己伺服器的socket連線，移動終端需要維護多個socket連線，較為耗電，不易於管理。
       2. 採用拉的方式，應用在啟動的時候會從應用的伺服器上拉取訊息；啟動之後，應用會週期性的連線伺服器去檢查是否有訊息需要拉取，這種方式並不實時，需要等到終端主動拉取的時候伺服器才能把訊息傳遞到終端。如果應用頻繁檢查是否有訊息需要拉取，那麼耗電會增加，如果檢查週期過長，那麼會影響訊息的實時性。
       3. 綜上，採用pull方式進行通知訊息的傳遞並不是一個很好的方法。

   • push方式

     • 採用push方式主要有點如下：

       1. 採用push方式，移動終端只需要和推送伺服器之間保持一個長連線即可。這樣移動終端用於推送的socket連線數量就與需要推送服務的應用數量無關了，只需要維持一個終端與推送伺服器之間的長連線即可，所有應用的服務端都是直接連線推送伺服器並通過推送伺服器來把訊息推送到終端。而終端也只與推送伺服器進行連線即可獲得推送的通知訊息。
       2. 推送伺服器通過長連線，在訊息到來的時候可以立即把訊息推送到連線上來的終端上，實時性比較高。

一個典型的訊息推送系統設計

設計通知推送系統需要考慮的幾個問題

• 推送應用認證問題：使用推送系統的應用首先需要認證，只有認證通過的應用才允許使用推送系統推送訊息。
• 多個推送伺服器的負載均衡問題：通過在推送應用服務端程式與推送伺服器之間放置tcp負載均衡伺服器來實現。
• 移動端伺服器連線負載均衡問題：通過DNS負載均衡來實現。
• 推送訊息時，移動終端線上，則訊息應該立即送達。
• 推送訊息時，移動終端不線上，那麼分兩種情況：對於按序訊息，應該每條訊息都儲存，在移動終端上線時按照順序由移動終端主動拉取，此時，新的推送訊息要等待之前的訊息都被接收之後再實時推送；對於覆蓋訊息，只保留最後一條訊息，在移動終端上線之後直接實時推送訊息。

訊息推送系統示意圖

• 此圖展示了實際應用場景中訊息推送的關係。
• 在實際應用場景中，需要推送的應用服務端只與推送系統進行互動，它並不知道是否有及有多少終端需要被推送訊息。服務端把需要推送的訊息交給推送系統，其餘的就不是應用服務端需要關心的事情了。
  

訊息推送系統邏輯設計圖

• 此圖中，推送應用1，2，3為推送應用的服務端，其負責把需要推送的訊息放入推送系統。這些應用服務端通過負載均衡伺服器來連線到具體的推送伺服器。負載均衡伺服器在應用連線過來時，首先會通過