RabbitMQ 入门:1. Message Broker(消息代理)
Message Broker(消息代理)
維基百科對(duì) Message Broker 的定義是:Message broker是一種中介程序模塊,它把消息從發(fā)送方的正式消息傳遞協(xié)議轉(zhuǎn)化為接收方的正式消息傳遞協(xié)議。
這個(gè)定義略繁瑣,下面看看 RabbitMQ 官網(wǎng)對(duì) Message broker 的定義:
Message broker 接收來自發(fā)布者的消息并將其路由到消費(fèi)者。
?
上面兩個(gè)定義說的都是同一件事情,但是 RabbitMQ 官網(wǎng)的定義里缺少了“轉(zhuǎn)換”這部分。
?
RabbitMQ 實(shí)現(xiàn)了一個(gè)加? AMQP(Advanced Message Queuing Protocol)的協(xié)議。
AMQP 如同互聯(lián)網(wǎng)的 HTTP 協(xié)議,它更注重于如何傳輸數(shù)據(jù),并不關(guān)心發(fā)送的數(shù)據(jù)是什么。這也就意味著需要消息的發(fā)送者和接收者來協(xié)調(diào)消息的格式。
?
為什么需要 Message broker?
看下圖,有這樣一個(gè)應(yīng)用,客戶端需要與服務(wù)器進(jìn)行通信,傳遞數(shù)據(jù)。最簡(jiǎn)單的情況就是客戶端通過HTTP 類協(xié)議直接與服務(wù)器連接,并發(fā)送數(shù)據(jù)。
目前一切都很簡(jiǎn)單明了。
但是,如果服務(wù)器因?yàn)榫S護(hù)或其它原因發(fā)生了停機(jī),或者你想對(duì)其橫向擴(kuò)展,添加更多的服務(wù)器來進(jìn)行響應(yīng),那么問題就來了:客戶端目前是與這臺(tái)服務(wù)器緊密的耦合在一起了,而隨著系統(tǒng)的增長(zhǎng)和進(jìn)化,這種緊耦合就開始讓人頭疼。
?
如果,我們?cè)诳蛻舳伺c服務(wù)器之間放置一個(gè) Message broker,那么情況就不一樣了:
客戶端首先將數(shù)據(jù)發(fā)送給 Message broker。Message broker 會(huì)對(duì)數(shù)據(jù)進(jìn)行檢驗(yàn),并將其發(fā)送給服務(wù)器。
但在這種簡(jiǎn)單的情景下,感覺好像沒帶來什么好處。
但是,Message broker 可以通過簡(jiǎn)單的設(shè)置來允許多種場(chǎng)景,從而讓后端服務(wù)器的橫向擴(kuò)展或停機(jī)維護(hù)等工作變得輕松,并且客戶端并不會(huì)感知到任何的變化。
這種解耦的架構(gòu)在分布式應(yīng)用中非常的常見,這意味著一切所唯一依賴要求可用的東西就是 Message broker。
而因?yàn)?Messagebroker 唯一的工作就是傳輸數(shù)據(jù),也沒有必要經(jīng)常對(duì)其進(jìn)行改動(dòng),所以它是一個(gè)相對(duì)安全可依賴的組件。
?
對(duì)于像 RabbitMQ 這樣可以設(shè)置集群來支持高可用的 Message broker,更是這樣。
總結(jié)
以上是生活随笔為你收集整理的RabbitMQ 入门:1. Message Broker(消息代理)的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: OSI强调:SSPL并不是开源许可证
- 下一篇: 什么时候我们应谈及性能?