大型移動APP開發(fā)之服務器端MQ技術選型

1、MQ技術選 型消息中間件 的 傳遞模式一般有兩種 傳遞模型：點對點模型 （ PTP）和發(fā)布 - 訂閱模型（ Pub/Sub ）。1. 點對點模型 （ PTP）點對點模型 用于消息生 產者和消息 消費者之間 點 到點的通 信。消息生產者 將消息發(fā)動 到由某個名 字 標識的特 定消費 者。這個名字實 際上對應于 消息服務中 的 一個隊列 （），在消息傳動 給 消費者之 前它被存儲 在這個隊列 中。隊列可以是 持久的，以保證在消 息服務出現 故障時仍然 能夠傳遞消 息。2. 發(fā)布 -訂閱模型（ Pub/Sub ）發(fā)布-訂閱模型用 稱為主題（）的內容分層 結構代替了 PTP模型中的惟一目 的地，發(fā)送應

2、用程 序發(fā)布自己 的消息，指出消息描 述的是有關 分層結構中 的 一個主題 的信息。希望接收這 些消息的應 用程序訂閱 了 這個主題 。訂閱包含子 主 題的分層 結構中的主 題的訂閱者 可以接收該 主題和其子 主題發(fā)表的 所 有消息。下圖展示了 發(fā)布和訂閱 模 型：多個應用程 序 可以就一 個 主題發(fā)布 和訂閱消息 ，而應用程序 對其他人仍 然是匿名的 。MOM ge Orie，面向消息的 中間件）起著代理（r ）的作用，將一個主題 已發(fā)表的消 息路由給該主題的所有 訂閱者。常見消息協 議協議，col ，是流文本定 向消息協議 ，是一種為 OM 設計 的簡單文本協議。它提供了一 個可互操作 的

3、連接格式 ，允許 MP 客戶端與任意 OMP 消息 代理r）進行交互，類似于enWi e （一種二進制 協議 ）。由于其設計 簡單，很容易開發(fā) 客戶端，因此在多種 語言和多種 平臺上得到 廣泛應用。其中最流行 的 P消息代理 是 eMQ。協議工作于 TCP 協議 之上，使用了下列 命令：* SEND 發(fā)送RIBE 訂閱E 退訂開始T 提交取消* ACK 確認斷開AMQP協議AMQ，P 即col ，高級消息隊 列 協議，是應用層協 議的一個開 放 標準，為面向消息 的中間件設 計 。AMQP的主要特征是 面向消息、隊列、路由(包括點對點 和發(fā)布/ 訂閱)、可靠性、安全。AMQP在消息提供者 和客

4、戶端的 行為進行了 強制規(guī)定，使得不同賣 商之間真正 實現了互操 作 能力。 JMS是早期消息中間件進行標準化的一個嘗試，它僅僅是在 API 級進行了規(guī)范，離創(chuàng)建互操 作能力還差很遠。與 JMS不同，AMQP是一個 e 級的協議 ，它描述了在 網絡上傳輸 的數據的格 式，以字節(jié)為流 。因此任何遵 守此數據 格 式的工具，其創(chuàng)建和解 釋消息，都能與其他 兼容工具進 行互操作。AMQP的實現有：MQ等。常 見消息中 間件產品e MQe MQ 是一個 基 于ced 發(fā)布，開放源碼的 JMS 產品。 其特點為：1) 提供點到點 消息模式和 發(fā)布/ 訂閱消息模 式；2) 支持ss、imo 等開 源應用服

5、務 器，支持 ing 框架的消息驅動 ；3) 新增了一個 P2P 傳輸層，可以用于創(chuàng) 建可靠的 2P JMS 網絡連接；4) 擁有消息持 久化、事務、集群支持等 JMS 基 礎設 施服務。tQent: t q/2.2.14.Fina -.htmlt Q是一個支持集群和 多種協議，可嵌入、高性能的異 步消息系統。tQ完全支持 JMS，tQ不但支持.1API 同時也定義屬于自己的消息 API ，這可以最大 限度的提升tQ的性能 和靈活性。在不久的將 來更多的 協議將被支持。t Q擁有超高的性能，t Q在持久化消息方面 的性能可以 輕易的超于 其它常見的非持久化消 息引擎的性 能。當然，t Q的非持

6、 久化消息的 性能會表 現的更好！t Q完全使 用，純 的設計讓Q可以盡可 能少的以來 第三方的包 。從設計模式來說，tQ這樣的設計入侵性也最小。t Q既可以獨立運行，也可以與其 它 應用程序服 務器集成使 用。tQ擁有完善的錯誤處理機制，t Q提供服務器復制和 故障自動轉移功能，該功能可以消除消息丟失或多個重 復信息導致服務器出錯。H t Q提供了靈活的集群 功能，通過創(chuàng)建Q集群，您可以享受 到到消息的 負載均衡帶來的性能提 升。您也可以通過集群，組成一個全球性的消息 網絡。您也可以靈 活的配置消 息路由。t Q擁有強大的管理功 能。t Q提供了大量的管理 API 和監(jiān)控服務器。它可以無 縫

7、的與應用程序服務器整合，并共同工作 在一個 環(huán) 境中eMQ 和 Q 的比較：特點t Q2.0GAeMQ5.3.0客戶端語言Java，Java,C#,C 等 1.1,jms1.2應用協議on,XMPP,AMQP支持的 傳 送協 議TCP,SSL,HTTP等-, JXTA 等監(jiān)測 消 息支持支持使用 erts （排他和非排 他 ）可虛擬目標隊列，鏡像隊列（隊列自 動復消息目 標隊 列的分類以使用 過濾相匹配消 息被轉 移制）和復合目的 地隊 列1.發(fā)布消息通 過廣播（ UDP組播）1. 發(fā)送消息通 過廣播（ UDP組播或者零配或固定客 戶端和服 務端置）或者固定的 客戶端和服 務端。2. 支持 負

8、載 均衡2. 支持 負載均衡3. 消息的重分 發(fā)：發(fā)送前，配置3. 容錯機制（ ver）: 主備服務器無消費者對消息的 重新分發(fā)的參（每一個主服 務器只有一 個備 服務 器）集群數。4. 靜態(tài)或者 動態(tài)的發(fā)布。4.容錯機制（ver ）:主備服5. 針對 消息的 r 的重分 發(fā)。務器 （每一個主服 務器只能有 一6. 高可用性：從主服 務器 異步日志到 備 份個冷 備份服務器）服 務器 （快），或者通 過 DBC通過共享5. 高可用性：異步日志復 制從主文件系 統存儲（慢）或者共享存 儲 （有沒到備 （快）或者通 過共享文件系有需要 復制）統的共享存 儲（有沒有需要 復JMX監(jiān)控和管理JMS到

9、MS的 i dge 的方 式在集群中消 息組和排他 性消 費。性能（e）測試 工具持久化安全Blob 和消 息的支持調度傳遞（ ery ）消息 轉換 （xml 轉換 為對 象）異步 發(fā) 送e優(yōu)化生產者流程控制慢消費消息 的處理攔截器架構通配符的支 持（ ard ）的支持重新 傳遞 策略 消息優(yōu)先級和權重的 設置 命令代理AMQP支持SOAP協議 Web服務的支持JEE應用服務整合超時 消息的 目 標地址檢查重復的 消息集群中服 務端的負載 均衡制） 支持，包含一個 eb 控制臺 支持， HQ到 和 HQ到任 何.1 的服務器。一次只能提 供 一次，并保 證 在 Q到es. 支持MS 壓力 測試

10、僅支持異步 日志系 統（ al ），提供兩種方 式：1. Java NIOAIO（ 僅支持 nux2.6 以上的版 本） 身份驗證和授權的 AS的配置 文 件中定義。7中不同的 權限。 支持 支持 支持，但是 僅僅 在HQ和e 之間 。支持前置 dge 支持（ 僅僅 在 ndow） 支持 支持，在包一 級傳入的數據 庫捕 獲支持不支持 延遲交還和DLQ 不支持 不支持 不支持 不支持 支持，使用 RA 支持 支持 支持支持支持r 的性能 測試 支持多種方 式：B（比較好的可 擴展性，更短的恢 復時間。）2.AMQ消息存 儲（快） 3.JDBC數據庫（比 較慢）JAAS的身份驗證和配置文件授 權

11、。3 中不 同的 權限（ 讀，寫，管理） 支持 支持（使用 支持（其中 案） 支持 批量 支持（ 僅僅 在 支持 支持，使用一個 攔截器棧捕獲 傳入的消息支持 支持 DLQ，丟 失的消息 將 無法在交 付。 支持支持在 Q4.2 以上 支持 支持，使用che Axis 和CXF支持，使用 RA 不支持 不支持 支持）i ng 提供 具體的 實現 方dge，異步消息 傳 遞 ndow）支持，自 動故障 轉移和應用管理客戶端容錯機制ver)模式支持，隨機和循 環(huán)使用故障 轉移協議Vm傳輸支持支持對 Aja 的支持未知支持客戶端負載 均衡(e) 支持(隨機和循 環(huán) )不支持對 ng 的支持tMQy

12、出名的 g 寫成，tMQ 是由 t 提供的一個 AMQP 的開源實現 ，由以高性能 、健壯以及因此也是繼 承了這些優(yōu) 點AMQP 里的兩個主 要組件： nge 和 ，綠色的 X 就是 nge ，紅色的是 ，這兩者都在 r 端，又稱作 r ，這部分是 tMQ 實現的，而藍色的則 是 客戶端，通常有cer 和 mer 兩種類型：AMQP 有四個非常 重要的概念 ：虛擬機al host) ，交換機nge) ，隊列)和綁定(binding) 。虛擬機 : 通常是應用 的外在邊界 ，我們可以為 不同的虛擬 機分配訪問 權 限。虛擬機可持 有多個交換 機、隊列和 綁定 。交換機 : 從連接通道 el)接收

13、消息，并按照特定 的 路由規(guī)則 發(fā)送給隊列 。隊列: 消息最終的 存儲容器，直到消費客 戶端 mer) 將其取走。綁定 : 也就是所謂 的路由規(guī)則 ，告訴交換機 將何種類型 的消息發(fā)送 到某個隊列 中。 通常的操作 流程是 :(1) 消費者 : 創(chuàng)建信息通 道 。(2) 消費者 : 定義消息隊 列 。(3) 消費者 : 定義特定類 型 的交換機 。(4) 消費者 : 設定綁定規(guī) 則 (包括交換機 名 稱、隊列名稱以 及路由鍵 )。(5) 消費者 : 等待消息。(6) 生產者 : 創(chuàng)建消息。(7) 生產者 : 將消息投遞給信息通道 (注明接收交換機名稱和路由鍵)。(8) 交換機: 獲取消息，依據

14、交換機 類型決定是否匹配路由規(guī)則 (如需匹配，則對比消息 路由鍵和綁定路由 鍵)。(9) 消費者 : 獲取并處理消息，發(fā)送反饋。(10) 結束: 關閉通道和連接。隊列定義參數:sive: 僅創(chuàng)建者可以使用的私有隊列，斷開后自動 刪除。e: 當所有消費客戶端連接斷開后，是否自動刪 除隊列。交換機定義參數:type: 交換機類型，包括 t 和 。e: 當所有綁定隊列都不再使用時，是否自動刪 除該交換機。 如所定義隊列和交換機已存在， are 和 e 將直接使用，不會拋出異 常。交換機類型 :t: 不處理路由鍵，將消息廣播給綁定到該交換機的所有隊列。t: 處理路由鍵，對消息路徑進行全文匹配。消息路由

15、鍵 “ ” 只能匹配 “ ” 綁定，不 匹配“ ”這類綁定。: 處理路由鍵，按模式匹配路由鍵。模式符號 “#”表 示一個或多個單詞， ” ”僅 匹配一個 單詞。如 “#” 可匹配 “ ”，但“”只 匹配 “ ”。通過 ing 配置來實現異步接收消息類是用于發(fā)送消息的類。實現如下Java 代 碼..2.13.getmq;tlate;ctelate;c voider i) ge = + # + i;nge 的名 稱為，的名稱為r Send(ge);ln(發(fā)送第 + i +個消息成功！內容為：eueeue,ge);16.r17.ges);18.ln( 發(fā)

16、送第 + i + 個消息成功！內容為：ges);19.20.21.c voidlate) 22.this .late;23.24.25. t + # + i;14.15.8.rty name=ame9.rty name=ord10.11.bean id=dmin12.=13.r-arg ref=14.15.bean id=late16.=17.r-arg ref=18.19.bean id=20.=21.rty name=22.24.g 的配置文件如下： -Java 代 碼1.on= 1.0 ing= UTF-82. =3. :xsi= http:/www.w4. tion=5. - nce-

17、 3.0.xsd ory host /= /= /nry /t.core. late ry r-arglate late /25.對于發(fā)送消息的程序自己可以實現。面來看看接受消息的程序如下er 類用于接收消息的處理類，如下Java 代 碼1.getmq;2.3.t java.util.Date;4.5.Heller 6.c voidg text) 7.ln(ved: + text);8.9.ln( newDate();10.11.g 的配置文件如下：tmq.xmlJava 代 碼1. 2.3.:xsi=nce4.tion=http:/www.spri5.6.ory 8.r-=host /9.r

18、ty name=ame = /10.rty name=ord =9.nlate 20.r-arg ref=ryr-arg5.ruc -=r-arg4.-=r -arg8.40.-= tr -arg4.46.-=0 ref=r -arg47.-=1 ref=r -arg48.-=2 =.#r-arg6.58.r-arg ref=er/59.rty name=d=agerty60.rty name=r ref=rrty61.6

19、2.63.65.rty name=Name=rty66.rty name=ry ref=ryrty67.rty name= ref=rty68.69.70.官網： /和itMQ，就好比inx 和 e，sh 和uid。簡單、輕量級、高性能、易使用等特點，以及優(yōu)先級、多隊列、持久化、分布式容錯 、超時控制等特性。設計思想高性能離不開異步，異步離不開隊列，而其內部都是mer 模式的原理應用，一個高性能、輕量級的分布式內存隊列系統，最初設計的高容量 b 應用系統的頁面訪問延遲，支持過有 .5 on 用戶的目的是想通過后臺異步執(zhí)行耗時的任務來降低s 應用。后來開源，現在有k大規(guī)模部署和使用，每天處理百萬

20、級任務是典型的類 ched 設計，協議和使用方式都是同樣的風格核心概念設計里面的核心概念：job 一個需要異步處理的任務，是 d中的基本單元，需要放在一個 中。tube一個有名的任務隊列，用來存儲統 一類型的 ob，是ucer 和 mer 操作的對象。cerJob 的生 產者，通過命令來將一 個 job 放到 一個 be 中。merJob 的消 費者，通過e 命令來 獲取 job 或改 變 的狀態(tài)。Job 生命 周 期中一個 b的生命周 期如圖 2所示。一個 有 D四種狀 態(tài)。當ucer 直接 put 一個 job 時，job 就處于 Y 狀態(tài)，等待 來處理，如果選擇延 遲 put，job 就

21、先 到YED狀 態(tài)， 等待時間過 后 才遷移到狀 態(tài)。mer 獲取 了當前 ADY 的 ob 后，該 job 的 狀態(tài)就遷移 到RVED ，這樣其他的 mer 就不能 再操作該 job。當umer 完成 該 后，可以選擇 se 或者 ury操作； e之后， job 從系統消亡，之后不能再 獲取； se操作可以重新把該 job 狀態(tài)遷移回 ADY（也 可以延遲該 狀態(tài)遷移操 作），使其他的e r可以繼續(xù)獲取和執(zhí) 行該；有意思的是 bury 操作，可以把該 ob休眠，等到需要的 時候，再將休 眠的 kick 回 狀態(tài)，也可以 D 狀態(tài)的 ob。正是有這些 有趣的操作 和狀態(tài)，才可 以基于此做出很多

22、意思的應用 ，比如要實現 一個循環(huán)隊 列，就可以將 ED狀態(tài)的 job 休眠掉，等沒有 ADY狀態(tài) 的 job 時再將 IED 狀態(tài)的 job 一次性 k回 DY 狀態(tài)。ycle:e VED *poof*特性優(yōu)先級支持 0到 *32 的優(yōu)先級，值越小，優(yōu)先級越高 ，默認優(yōu)先級 為持久化分布式容錯分布式設計 和類似， 各個 ver 之間并 不知道彼 此的存在，都是通過來實現分布 式以及根據tube 名 稱去特定獲取 。可以通過 態(tài)。將 job 及其 狀態(tài)記錄 到文件里面 ，在d 下次啟 動時可以通過 讀取 log 來恢 復之前的 ob 及狀rve 操作 設置了時間，如果該r 執(zhí)行。kd 來自 動

23、刪除空 be。Tube 是在被引 ed 或者ied job ）并且沒有客 戶端引超時控制為了防止某 個 umer 長時 間占用任 務但不能處 理 的情況，為r不能在指 定時間內完 成 job ，job將被遷移回 ADY 狀態(tài)，供其他 不足沒有提供刪 除一個 be的操作 ，只能將 be的 b依次刪除，并讓 用到 時按需創(chuàng)建 的。如果一個 ube 空了 （也就是說不 包含任何 用，該 將被刪除。不支持客戶 端認證機制 （開發(fā)者將應 用場景定位 在 局域網）talk 協議talk協議是 使用 II編碼方式 運行在 p之上的。整個協議是 由客戶端主 動發(fā)起 p連接，發(fā)送命令和 數 據，等待響應，然后關閉連 接來進行通信的。對于每一個 連接，服務嚴格按