1. 首頁 > 生活百科 > >

設計原理有哪些 消息推送設計的4大原理？

生活百科


設計原理有哪些 消息推送設計的4大原理？

文章插圖
隨著 iPhone 和安卓手機這類超級手機的興起，現在完全可以繞過運營商，通過標準 TCP/IP 網絡直接向這些手機發送消息，這些消息就稱為推送消息 。
推送消息是通過 Apple 和 Google 掌控的互聯網服務器發送的，推送消息從根本上就是設計用于與應用程序通信的，它們可以發送文本、多媒體文件和特定于應用程序的數據，例如：警告聲音和顯示在應用程序圖標上的標記等 。
推送通知非常適合智能手機應用，但與基于運營商的移動消息傳遞相比，它們的普及性和可靠性都較差 。
消息推送的分類和方式等，如下圖：
設計原理有哪些 消息推送設計的4大原理？

文章插圖
（1）消息提醒的流程
輸入消息》進入消息倉庫》發送消息》消息流水》消息詳情
（2）消息發送的時間
  • 一般為上午9點-10點
  • 中午12點-14點
  • 下午5點-6點
  • 晚上21點-22點
（3）消息推送的類型
  • 優惠券到期通知
  • 客服即時消息
  • 抽獎商品到期通知
  • 收藏降價通知
  • 抽獎機會提醒
  • 訂單發貨提醒
  • 訂單退貨提醒
  • 購物車商品過期通知
  • 拼團到期通知
  • 各大活動通知
（4）消息推送的規則
移動端獲得消息通知主要有兩種方式：pull（拉）方式和push（推）方式，下面分別對這兩種方式做簡要介紹 。
pull方式：
pull方式即“拉方式”，這種方式中手機上的應用程序在啟動時及經過一定周期會定時連接應用的服務端來獲得服務器需要傳遞給終端的消息，因為此處是終端從服務端主動獲得消息，因此稱為拉方式 。此方式服務端實現簡單，只需要在終端連接上之后把需要發送的消息發送給終端即可，但是此方式有如下弊端：
每個應用終端都需要建立到自己服務器的socket連接，移動終端需要維護多個socket連接，較為耗電，不易于管理 。
采用拉的方式，應用在啟動的時候會從應用的服務器上拉取消息；啟動之后，應用會周期性的連接服務器去檢查是否有消息需要拉取，這種方式并不實時，需要等到終端主動拉取的時候服務器才能把消息傳遞到終端 。如果應用頻繁檢查是否有消息需要拉取，那么耗電會增加，如果檢查周期過長，那么會影響消息的實時性 。
綜上，采用pull方式進行通知消息的傳遞并不是一個很好的方法 。
push方式：
  • 采用push方式，移動終端只需要和推送服務器之間保持一個長連接即可 。這樣移動終端用于推送的socket連接數量就與需要推送服務的應用數量無關了，只需要維持一個終端與推送服務器之間的長連接即可，所有應用的服務端都是直接連接推送服務器并通過推送服務器來把消息推送到終端 。而終端也只與推送服務器進行連接即可獲得推送的通知消息 。
  • 推送服務器通過長連接，在消息到來的時候可以立即把消息推送到連接上來的終端上，實時性比較高 。
消息推送示意圖
設計原理有哪些 消息推送設計的4大原理？

文章插圖
消息推送系統邏輯設計圖
設計原理有哪些 消息推送設計的4大原理？

文章插圖
此圖中，推送應用1，2，3為推送應用的服務端，其負責把需要推送的消息放入推送系統 。這些應用服務端通過負載均衡服務器來連接到具體的推送服務器 。
服務端是Socket.io的集群，供客戶端（Web、移動端）連接 。集群后面是一個Redis服務器，保存集群中每個節點（我們稱之為Cluster）連接的客戶端ID 。同時Redis里面為每一個Cluster分配了一個隊列，保存推送到這個Cluster的消息 。
當有消息從某個客戶端發出后，所連接的Cluster從Redis里面獲取這個消息的目標客戶端ID（由于我們同時支持一對一私聊和群組，因此一條消息可能會被推送到多個客戶端），然后把消息Push到每個Cluster的消息隊列里面 。
每一個Cluster都會以阻塞方式讀取它所對應的消息隊列，一旦發現有消息，就獲取并且查看其目標客戶端ID是不是連接在這個Cluster上 。如果是，就通過Socket.io發送，如果不是就丟棄 。然后繼續阻塞讀取，直到下一條消息到達 。
總結其實粗略來講，即時通訊-消息推送只是一種實現，比如：你可以用第三方產品，很輕易的就可以實現點對點、甚至點對多的消息收發 。
但是在用戶需求很個性化，比如：我要對用戶的聊天內容進行監控，涉及到敏感的關鍵字不讓消息推送出去、或者我要對開通會員的用戶給予“尊貴的身份” 。

推薦閱讀