如何設計一個百萬級的消息推送系統？

時間 2020-05-04

標籤如何設計一個百萬消息推送系統简体版

原文原文鏈接

前言

首先遲到的祝你們中秋快樂。html

最近一週多沒有更新了。其實我一直想憋一個大招，分享一些你們感興趣的乾貨。前端

鑑於最近我我的的工做內容，因而利用這三天小長假憋了一個出來（實際上是玩了兩天🤣）。java

先簡單說下本次的主題，因爲我最近作的是物聯網相關的開發工做，其中就難免會遇到和設備的交互。mysql

最主要的工做就是要有一個系統來支持設備的接入、向設備推送消息；同時還得知足大量設備接入的需求。nginx

因此本次分享的內容不但能夠知足物聯網領域同時還支持如下場景：git

基於 WEB 的聊天系統（點對點、羣聊）。
WEB 應用中需求服務端推送的場景。
基於 SDK 的消息推送平臺。

技術選型

要知足大量的鏈接數、同時支持雙全工通訊，而且性能也得有保障。github

在 Java 技術棧中進行選型首先天然是排除掉了傳統 IO。web

那就只有選 NIO 了，在這個層面其實選擇也很少，考慮到社區、資料維護等方面最終選擇了 Netty。算法

最終的架構圖以下：sql

如今看着蒙不要緊，下文一一介紹。

協議解析

既然是一個消息系統，那天然得和客戶端定義好雙方的協議格式。

常見和簡單的是 HTTP 協議，但咱們的需求中有一項須要是雙全工的交互方式，同時 HTTP 更多的是服務於瀏覽器。咱們須要的是一個更加精簡的協議，減小許多沒必要要的數據傳輸。

所以我以爲最好是在知足業務需求的狀況下定製本身的私有協議，在我這個場景下其實有標準的物聯網協議。

若是是其餘場景能夠借鑑如今流行的 RPC 框架定製私有協議，使得雙方通訊更加高效。

不過根據這段時間的經驗來看，無論是哪一種方式都得在協議中預留安全相關的位置。

協議相關的內容就不過討論了，更多介紹具體的應用。

簡單實現

首先考慮如何實現功能，再來思考百萬鏈接的狀況。

註冊鑑權

在作真正的消息上、下行以前首先要考慮的就是鑑權問題。

就像你使用微信同樣，第一步怎麼也得是登陸吧，不能不管是誰均可以直接鏈接到平臺。

因此第一步得是註冊才行。

如上面架構圖中的 註冊/鑑權 模塊。一般來講都須要客戶端經過 HTTP 請求傳遞一個惟一標識，後臺鑑權經過以後會響應一個 token，並將這個 token 和客戶端的關係維護到 Redis 或者是 DB 中。

客戶端將這個 token 也保存到本地，從此的每一次請求都得帶上這個 token。一旦這個 token 過時，客戶端須要再次請求獲取 token。

鑑權經過以後客戶端會直接經過TCP 長鏈接到圖中的 push-server 模塊。

這個模塊就是真正處理消息的上、下行。

保存通道關係

在鏈接接入以後，真正處理業務以前須要將當前的客戶端和 Channel 的關係維護起來。

假設客戶端的惟一標識是手機號碼，那就須要把手機號碼和當前的 Channel 維護到一個 Map 中。

這點和以前 SpringBoot 整合長鏈接心跳機制相似。

同時爲了能夠經過 Channel 獲取到客戶端惟一標識（手機號碼），還須要在 Channel 中設置對應的屬性：

123	public static void putClientId(Channel channel, String clientId) { channel.attr(CLIENT_ID).set(clientId);}

獲取時手機號碼時：

123	public static String getClientId(Channel channel) { return (String)getAttribute(channel, CLIENT_ID);}

這樣當咱們客戶端下線的時即可以記錄相關日誌：

123	String telNo = NettyAttrUtil.getClientId(ctx.channel());NettySocketHolder.remove(telNo);log.info("客戶端下線，TelNo=" + telNo);

這裏有一點須要注意：存放客戶端與 Channel 關係的 Map 最好是預設好大小（避免常常擴容），由於它將是使用最爲頻繁同時也是佔用內存最大的一個對象。

消息上行

接下來則是真正的業務數據上傳，一般來講第一步是須要判斷上傳消息輸入什麼業務類型。

在聊天場景中，有可能上傳的是文本、圖片、視頻等內容。

因此咱們得進行區分，來作不一樣的處理；這就和客戶端協商的協議有關了。

能夠利用消息頭中的某個字段進行區分。
更簡單的就是一個 JSON 消息，拿出一個字段用於區分不一樣消息。

無論是哪一種只有能夠區分出來便可。

消息解析與業務解耦

消息能夠解析以後即是處理業務，好比能夠是寫入數據庫、調用其餘接口等。

咱們都知道在 Netty 中處理消息通常是在 channelRead() 方法中。

在這裏能夠解析消息，區分類型。

但若是咱們的業務邏輯也寫在裏面，那這裏的內容將是巨多無比。

甚至咱們分爲好幾個開發來處理不一樣的業務，這樣將會出現許多衝突、難以維護等問題。

因此很是有必要將消息解析與業務處理徹底分離開來。

這時面向接口編程就發揮做用了。

這裏的核心代碼和「造個輪子」——cicada(輕量級 WEB 框架) 是一致的。

都是先定義一個接口用於處理業務邏輯，而後在解析消息以後經過反射建立具體的對象執行其中的處理函數便可。

這樣不一樣的業務、不一樣的開發人員只須要實現這個接口同時實現本身的業務邏輯便可。

僞代碼以下：

想要了解 cicada 的具體實現請點擊這裏：

https://github.com/TogetherOS/cicada

上行還有一點須要注意；因爲是基於長鏈接，因此客戶端須要按期發送心跳包用於維護本次鏈接。同時服務端也會有相應的檢查，N 個時間間隔沒有收到消息以後將會主動斷開鏈接節省資源。

這點使用一個 IdleStateHandler 就可實現，更多內容能夠查看 Netty(一) SpringBoot 整合長鏈接心跳機制。

消息下行

有了上行天然也有下行。好比在聊天的場景中，有兩個客戶端連上了 push-server,他們直接須要點對點通訊。

這時的流程是：

A 將消息發送給服務器。
服務器收到消息以後，得知消息是要發送給 B，須要在內存中找到 B 的 Channel。
經過 B 的 Channel 將 A 的消息轉發下去。

這就是一個下行的流程。

甚至管理員須要給全部在線用戶發送系統通知也是相似：

遍歷保存通道關係的 Map，挨個發送消息便可。這也是以前須要存放到 Map 中的主要緣由。

僞代碼以下：

具體能夠參考：

https://github.com/crossoverJie/netty-action/

分佈式方案

單機版的實現了，如今着重講講如何實現百萬鏈接。

百萬鏈接其實只是一個形容詞，更多的是想表達如何來實現一個分佈式的方案，能夠靈活的水平拓展從而能支持更多的鏈接。

再作這個事前首先得搞清楚咱們單機版的能支持多少鏈接。影響這個的因素就比較多了。

服務器自身配置。內存、CPU、網卡、Linux 支持的最大文件打開數等。
應用自身配置，由於 Netty 自己須要依賴於堆外內存，可是 JVM 自己也是須要佔用一部份內存的，好比存放通道關係的大 Map。這點須要結合自身狀況進行調整。

結合以上的狀況能夠測試出單個節點能支持的最大鏈接數。

單機不管怎麼優化都是有上限的，這也是分佈式主要解決的問題。

架構介紹

在將具體實現以前首先得講講上文貼出的總體架構圖。

先從左邊開始。

上文提到的 註冊鑑權 模塊也是集羣部署的，經過前置的 Nginx 進行負載。以前也提過了它主要的目的是來作鑑權並返回一個 token 給客戶端。

可是 push-server 集羣以後它又多了一個做用。那就是得返回一臺可供當前客戶端使用的 push-server。

右側的 平臺 通常指管理平臺，它能夠查看當前的實時在線數、給指定客戶端推送消息等。

推送消息則須要通過一個推送路由（push-server）找到真正的推送節點。

其他的中間件如：Redis、Zookeeper、Kafka、MySQL 都是爲了這些功能所準備的，具體看下面的實現。

註冊發現

首先第一個問題則是 註冊發現，push-server 變爲多臺以後如何給客戶端選擇一臺可用的節點是第一個須要解決的。

這塊的內容其實已經在分佈式(一) 搞定服務註冊與發現中詳細講過了。

全部的 push-server 在啓動時候須要將自身的信息註冊到 Zookeeper 中。

註冊鑑權 模塊會訂閱 Zookeeper 中的節點，從而能夠獲取最新的服務列表。結構以下：

如下是一些僞代碼：

應用啓動註冊 Zookeeper。

對於註冊鑑權模塊來講只須要訂閱這個 Zookeeper 節點：

路由策略

既然能獲取到全部的服務列表，那如何選擇一臺恰好合適的 push-server 給客戶端使用呢？

這個過程重點要考慮如下幾點：

儘可能保證各個節點的鏈接均勻。
增刪節點是否要作 Rebalance。

首先保證均衡有如下幾種算法：

輪詢。挨個將各個節點分配給客戶端。但會出現新增節點分配不均勻的狀況。
Hash 取模的方式。相似於 HashMap，但也會出現輪詢的問題。固然也能夠像 HashMap 那樣作一次 Rebalance，讓全部的客戶端從新鏈接。不過這樣會致使全部的鏈接出現中斷重連，代價有點大。
因爲 Hash 取模方式的問題帶來了一致性 Hash算法，但依然會有一部分的客戶端須要 Rebalance。
權重。能夠手動調整各個節點的負載狀況，甚至能夠作成自動的，基於監控當某些節點負載較高就自動調低權重，負載較低的能夠提升權重。

還有一個問題是：