消息队列01
?公司項(xiàng)目里面用到了這個(gè)rabbitmq，自己以前不熟悉，看了代碼里面的應(yīng)用，自己也準(zhǔn)備試著搭建下。
?可以參照其他博主的這篇優(yōu)秀博文：?https://www.cnblogs.com/chengpeng15/p/5814197.html
?
?
一 前期需要了解的概念
1.什么是異步？什么是異步通信？
異步：客戶端不需要等待服務(wù)器處理消息，甚至不需要等待消息投遞完成。客戶端發(fā)送消息，然后繼續(xù)執(zhí)行。(因?yàn)榭蛻舳思俣朔?wù)器最終可以收到并處理這條消息)
異步通信是指：有些業(yè)務(wù)不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制，允許用戶把消息放入隊(duì)列，但并不立即處理它。想在隊(duì)列中放入多少消息就放多少，然后在需要的時(shí)候再去處理他。
?
2.為什么說異步中? 間接性 是關(guān)鍵?
一個(gè)應(yīng)用向另一個(gè)應(yīng)用發(fā)送消息時(shí)，兩個(gè)應(yīng)用間沒有間接的聯(lián)系。而是發(fā)送方的應(yīng)用程序會(huì)將消息交給一個(gè)服務(wù)器(也就是消息中間件), 由服務(wù)來將消息投遞給接收方。
?
3.建立一個(gè)消息隊(duì)列的服務(wù)器，所有內(nèi)部的通訊交互都通過消息隊(duì)列進(jìn)行分發(fā)與訂閱。
?
?
4.使用消息隊(duì)列有以下的好處?：
A. 解耦
消息隊(duì)列在處理過程中間插入了一個(gè)隱含的、基于數(shù)據(jù)的接口層，兩邊的處理過程都要實(shí)現(xiàn)這一接口。這允許你獨(dú)立的擴(kuò)展或修改兩邊的處理過程，只要確保它們遵守同樣的接口約束。
B. 冗余
有時(shí)在處理數(shù)據(jù)的時(shí)候處理過程會(huì)失敗。除非數(shù)據(jù)被持久化，否則將永遠(yuǎn)丟失。消息隊(duì)列把數(shù)據(jù)進(jìn)行持久化直到它們已經(jīng)被完全處理，通過這一方式規(guī)避了數(shù)據(jù)丟失風(fēng)險(xiǎn)。在被許多消息隊(duì)列所采用的“插入-獲取-刪除”范式中，在把一個(gè)消息從隊(duì)列中刪除之前，需要你的處理過程明確的指出該消息已經(jīng)被處理完畢，確保你的數(shù)據(jù)被安全的保存直到你使用完畢。
C. 擴(kuò)展性
因?yàn)橄㈥?duì)列解耦了你的處理過程，所以增大消息入隊(duì)和處理的頻率是很容易的；只要另外增加處理過程即可。不需要改變代碼、不需要調(diào)節(jié)參數(shù)。擴(kuò)展就像調(diào)大電力按鈕一樣簡單。
D. 靈活性 & 峰值處理能力
在訪問量劇增的情況下，你的應(yīng)用仍然需要繼續(xù)發(fā)揮作用，但是這樣的突發(fā)流量并不常見；如果為以能處理這類峰值訪問為標(biāo)準(zhǔn)來投入資源隨時(shí)待命無疑是巨大的浪費(fèi)。使用消息隊(duì)列能夠使關(guān)鍵組件頂住增長的訪問壓力，而不是因?yàn)槌鲐?fù)荷的請(qǐng)求而完全崩潰。
E. 可恢復(fù)性
當(dāng)體系的一部分組件失效，不會(huì)影響到整個(gè)系統(tǒng)。消息隊(duì)列降低了進(jìn)程間的耦合度，所以即使一個(gè)處理消息的進(jìn)程掛掉，加入隊(duì)列中的消息仍然可以在系統(tǒng)恢復(fù)后被處理。而這種允許重試或者延后處理請(qǐng)求的能力通常是造就一個(gè)略感不便的用戶和一個(gè)沮喪透頂?shù)挠脩糁g的區(qū)別。
F. 送達(dá)保證
消息隊(duì)列提供的冗余機(jī)制保證了消息能被實(shí)際的處理，只要一個(gè)進(jìn)程讀取了該隊(duì)列即可。無論有多少進(jìn)程在從隊(duì)列中領(lǐng)取數(shù)據(jù)，每一個(gè)消息只能被處理一次。這之所以成為可能，是因?yàn)楂@取一個(gè)消息只是"預(yù)定"了這個(gè)消息，暫時(shí)把它移出了隊(duì)列。除非客戶端明確的表示已經(jīng)處理完了這個(gè)消息，否則這個(gè)消息會(huì)被放回隊(duì)列中去，在一段可配置的時(shí)間之后可再次被處理。
G.排序保證
在許多情況下，數(shù)據(jù)處理的順序都很重要。消息隊(duì)列本來就是排序的，并且能保證數(shù)據(jù)會(huì)按照特定的順序來處理。消息漿糊通過FIFO（先進(jìn)先出）的順序來處理，因此消息在隊(duì)列中的位置就是從隊(duì)列中檢索他們的位置。
H.緩沖
在任何重要的系統(tǒng)中，都會(huì)有需要不同的處理時(shí)間的元素。例如,加載一張圖片比應(yīng)用過濾器花費(fèi)更少的時(shí)間。消息隊(duì)列通過一個(gè)緩沖層來幫助任務(wù)最高效率的執(zhí)行--寫入隊(duì)列的處理會(huì)盡可能的快速，而不受從隊(duì)列讀的預(yù)備處理的約束。該緩沖有助于控制和優(yōu)化數(shù)據(jù)流經(jīng)過系統(tǒng)的速度。
I. 理解數(shù)據(jù)流
在一個(gè)分布式系統(tǒng)里，要得到一個(gè)關(guān)于用戶操作會(huì)用多長時(shí)間及其原因的總體印象，是個(gè)巨大的挑戰(zhàn)。消息系列通過消息被處理的頻率，來方便的輔助確定那些表現(xiàn)不佳的處理過程或領(lǐng)域，這些地方的數(shù)據(jù)流都不夠優(yōu)化。
J. 異步通信
很多時(shí)候，你不想也不需要立即處理消息。消息隊(duì)列提供了異步處理機(jī)制，允許你把一個(gè)消息放入隊(duì)列，但并不立即處理它。你想向隊(duì)列中放入多少消息就放多少，然后在你樂意的時(shí)候再去處理它們。
?
?
2.MQ原理
2.1mq模型
Pub/Sub發(fā)布訂閱（廣播）：使用topic作為通信載體?
PTP點(diǎn)對(duì)點(diǎn):使用queue作為通信載體?
2.2 mq的組成
-
Broker：消息服務(wù)器，作為server提供消息核心服務(wù)
-
Producer:消息生產(chǎn)者，業(yè)務(wù)的發(fā)起方，負(fù)責(zé)生產(chǎn)消息傳輸給broker
-
Consumer：消息消費(fèi)者，業(yè)務(wù)的處理方，負(fù)責(zé)從broker獲取消息并進(jìn)行業(yè)務(wù)邏輯處理
-
Topic:主題，發(fā)布訂閱模式下的消息統(tǒng)一匯集地，不同生產(chǎn)者向topic發(fā)送消息，由MQ服務(wù)器分發(fā)到不同的訂閱者，實(shí)現(xiàn)消息的廣播
-
Queue：隊(duì)列，PTP模式下，特定生產(chǎn)者向特定queue發(fā)送消息，消費(fèi)者訂閱特定的queue完成指定消息的接收
-
Message：消息體，根據(jù)不同通信協(xié)議定義的固定格式進(jìn)行編碼的數(shù)據(jù)包，來封裝業(yè)務(wù)數(shù)據(jù)，實(shí)現(xiàn)消息的傳輸
2.3 mq常用協(xié)議
-
AMQP?
AMQP即Advanced Message Queuing Protocol,一個(gè)提供統(tǒng)一消息服務(wù)的應(yīng)用層標(biāo)準(zhǔn)高級(jí)消息隊(duì)列協(xié)議,?
是應(yīng)用層協(xié)議的一個(gè)開放標(biāo)準(zhǔn),為面向消息的中間件設(shè)計(jì)。基于此協(xié)議的客戶端與消息中間件可傳遞消息，并?
不受客戶端/中間件不同產(chǎn)品，不同開發(fā)語言等條件的限制。?
優(yōu)點(diǎn)：可靠、通用 -
MQTT協(xié)議?
MQTT（Message Queuing Telemetry Transport，消息隊(duì)列遙測傳輸）是IBM開發(fā)的一個(gè)即時(shí)通訊協(xié)?
議，有可能成為物聯(lián)網(wǎng)的重要組成部分。該協(xié)議支持所有平臺(tái)，幾乎可以把所有聯(lián)網(wǎng)物品和外部連接起來，?
被用來當(dāng)做傳感器和致動(dòng)器（比如通過Twitter讓房屋聯(lián)網(wǎng)）的通信協(xié)議。?
優(yōu)點(diǎn)：格式簡潔、占用帶寬小、移動(dòng)端通信、PUSH、嵌入式系統(tǒng) -
STOMP協(xié)議?
STOMP（Streaming Text Orientated Message Protocol）是流文本定向消息協(xié)議，是一種為MOM(Message Oriented Middleware，面向消息的中間件設(shè)計(jì)的簡單文本協(xié)議。STOMP提供一個(gè)可互操作的連接格式，允許客戶端與任意STOMP消息代理（Broker）進(jìn)行交互。?
優(yōu)點(diǎn)：命令模式（非topic\queue模式） -
XMPP協(xié)議?
XMPP（可擴(kuò)展消息處理現(xiàn)場協(xié)議，Extensible Messaging and Presence Protocol）是基于可擴(kuò)展標(biāo)記語言（XML）的協(xié)議，多用于即時(shí)消息（IM）以及在線現(xiàn)場探測。適用于服務(wù)器之間的準(zhǔn)即時(shí)操作。核心是基于XML流傳輸，這個(gè)協(xié)議可能最終允許因特網(wǎng)用戶向因特網(wǎng)上的其他任何人發(fā)送即時(shí)消息，即使其操作系統(tǒng)和瀏覽器不同。?
優(yōu)點(diǎn)：通用公開、兼容性強(qiáng)、可擴(kuò)展、安全性高，但XML編碼格式占用帶寬大 -
其他基于TCP/IP自定義的協(xié)議?
有些特殊框架（如：redis、kafka、zeroMq等）根據(jù)自身需要未嚴(yán)格遵循MQ規(guī)范，而是基于TCP\IP自行封裝了一套協(xié)議，通過網(wǎng)絡(luò)socket接口進(jìn)行傳輸，實(shí)現(xiàn)了MQ的功能。
2.4 MQ選型
-
RabbitMQ?
使用Erlang編寫的一個(gè)開源的消息隊(duì)列，本身支持很多的協(xié)議：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它變的非常重量級(jí)，更適合于企業(yè)級(jí)的開發(fā)。同時(shí)實(shí)現(xiàn)了Broker架構(gòu)，核心思想是生產(chǎn)者不會(huì)將消息直接發(fā)送給隊(duì)列，消息在發(fā)送給客戶端時(shí)先在中心隊(duì)列排隊(duì)。對(duì)路由(Routing)，負(fù)載均衡(Load balance)、數(shù)據(jù)持久化都有很好的支持。多用于進(jìn)行企業(yè)級(jí)的ESB整合。 -
ZeroMQ?
又稱?MQ、0MQ、ZMQ，號(hào)稱最快的消息隊(duì)列系統(tǒng)，專門為高吞吐量、低延遲的場景開發(fā)，在金融界的應(yīng)用中經(jīng)常使用，偏重于實(shí)時(shí)數(shù)據(jù)通信場景。ZMQ能夠?qū)崿F(xiàn)RabbitMQ不擅長的高級(jí)/復(fù)雜的隊(duì)列，但是開發(fā)人員需要自己組合多種技術(shù)框架，開發(fā)成本高。因此ZeroMQ具有一個(gè)獨(dú)特的非中間件的模式，更像一個(gè)socket library，你不需要安裝和運(yùn)行一個(gè)消息服務(wù)器或中間件，因?yàn)槟愕膽?yīng)用程序本身就是使用ZeroMQ API完成邏輯服務(wù)的角色。但是ZeroMQ僅提供非持久性的隊(duì)列，如果down機(jī)，數(shù)據(jù)將會(huì)丟失。如：Twitter的Storm中使用ZeroMQ作為數(shù)據(jù)流的傳輸。 ZeroMQ套接字是與傳輸層無關(guān)的：ZeroMQ套接字對(duì)所有傳輸層協(xié)議定義了統(tǒng)一的API接口。默認(rèn)支持 進(jìn)程內(nèi)(inproc) ，進(jìn)程間(IPC) ，多播 ，TCP協(xié)議，在不同的協(xié)議之間切換只要簡單的改變連接字符串的前綴。可以在任何時(shí)候以最小的代價(jià)從進(jìn)程間的本地通信切換到分布式下的TCP通信。ZeroMQ在背后處理連接建立，斷開和重連邏輯。?
特性：-
無鎖的隊(duì)列模型?
對(duì)于跨線程間的交互（用戶端和session）之間的數(shù)據(jù)交換通道pipe，采用無鎖的隊(duì)列算法CAS；在pipe的兩端注冊(cè)有異步事件，在讀或者寫消息到pipe的時(shí)，會(huì)自動(dòng)觸發(fā)讀寫事件。 -
批量處理的算法?
對(duì)于批量的消息，進(jìn)行了適應(yīng)性的優(yōu)化，可以批量的接收和發(fā)送消息。 -
多核下的線程綁定，無須CPU切換?
區(qū)別于傳統(tǒng)的多線程并發(fā)模式，信號(hào)量或者臨界區(qū)， zeroMQ充分利用多核的優(yōu)勢，每個(gè)核綁定運(yùn)行一個(gè)工作者線程，避免多線程之間的CPU切換開銷。
-
-
ActiveMQ?
Apache下的一個(gè)子項(xiàng)目。使用Java完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實(shí)現(xiàn)，少量代碼就可以高效地實(shí)現(xiàn)高級(jí)應(yīng)用場景。可插拔的傳輸協(xié)議支持，比如：in-VM, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transports。RabbitMQ、ZeroMQ、ActiveMQ均支持常用的多種語言客戶端 C++、Java、.Net,、Python、 Php、 Ruby等。 -
Redis?
使用C語言開發(fā)的一個(gè)Key-Value的NoSQL數(shù)據(jù)庫，開發(fā)維護(hù)很活躍，雖然它是一個(gè)Key-Value數(shù)據(jù)庫存儲(chǔ)系統(tǒng)，但它本身支持MQ功能，所以完全可以當(dāng)做一個(gè)輕量級(jí)的隊(duì)列服務(wù)來使用。對(duì)于RabbitMQ和Redis的入隊(duì)和出隊(duì)操作，各執(zhí)行100萬次，每10萬次記錄一次執(zhí)行時(shí)間。測試數(shù)據(jù)分為128Bytes、512Bytes、1K和10K四個(gè)不同大小的數(shù)據(jù)。實(shí)驗(yàn)表明：入隊(duì)時(shí)，當(dāng)數(shù)據(jù)比較小時(shí)Redis的性能要高于RabbitMQ，而如果數(shù)據(jù)大小超過了10K，Redis則慢的無法忍受；出隊(duì)時(shí)，無論數(shù)據(jù)大小，Redis都表現(xiàn)出非常好的性能，而RabbitMQ的出隊(duì)性能則遠(yuǎn)低于Redis。 -
Kafka?
Apache下的一個(gè)子項(xiàng)目，使用scala實(shí)現(xiàn)的一個(gè)高性能分布式Publish/Subscribe消息隊(duì)列系統(tǒng)，具有以下特性： 快速持久化：通過磁盤順序讀寫與零拷貝機(jī)制，可以在O(1)的系統(tǒng)開銷下進(jìn)行消息持久化；?
高吞吐：在一臺(tái)普通的服務(wù)器上既可以達(dá)到10W/s的吞吐速率；?
高堆積：支持topic下消費(fèi)者較長時(shí)間離線，消息堆積量大；?
完全的分布式系統(tǒng)：Broker、Producer、Consumer都原生自動(dòng)支持分布式，依賴zookeeper自動(dòng)實(shí)現(xiàn)復(fù)雜均衡；?
支持Hadoop數(shù)據(jù)并行加載：對(duì)于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng)，但又要求實(shí)時(shí)處理的限制，這是一個(gè)可行的解決方案。
-
?
?
?
?
?
?
?
?
?
--未完，待補(bǔ)充
轉(zhuǎn)載于:https://www.cnblogs.com/PinkPink/p/9264007.html
總結(jié)
- 上一篇： C++内存模型
- 下一篇： 20180705 考试记录