RabbitMQ實戰 訊息通訊模式和最佳實踐

2021-08-18 08:39:57 字數 1518 閱讀 8184

本系列是「rabbitmq實戰:高效部署分布式訊息佇列」書籍的總結筆記。

通過介紹,你會了解到:

主要從非同步狀態思維、處理能力擴充套件性、整合複雜度方面,說明面向訊息通訊的好處。

非同步狀態思維

當將訊息通訊整合到應用程式時,開發模式將從同步模型變為非同步模型,rabbitmq提供了不同的方法,允許我們在一處傳送請求,在另一處進行處理,這樣同步程式可以繼續執行其他邏輯。

舉個簡單的例子來說明,通過支付寶還信用卡:

如果是同步請求,使用者需要等待幾個小時檢視結果,等待過程中不能進行其他操作,這是很不合理的。

非同步的思維是將請求和處理分離,在應用中緊密耦合的兩部分中間使用rabbitmq,請求解析後,傳送一條業務能夠理解的訊息到rabbitmq,就返回給使用者,真正的處理由另外的服務非同步處理。

擴充套件性隨著業務的擴充套件,對服務處理能力的要求越來越高,rabbitmq可以很簡單的增加處理能力。

因為rabbitmq可以將請求在處理伺服器間平均地分發,不需要負載均衡器了。

零成本api

系統間相互呼叫,需要約定一套api,通常來講,需要花費一點點時間,編寫一大段**將傳入的http請求轉化為應用程式中的函式呼叫。

如果使用amqp來連線應用程式的各個部分,無需額外定義api,使用訊息通訊即可。另外, amqp是語言無關的,擁有數十種語言的本地語言繫結。

當考慮訊息通訊能夠解決的問題型別時,訊息通訊適用的主要領域是的「發後即忘」處理模式。關心的是任務將會完成,但無須實時完成,建立乙個任務,傳送到交換器上後,就可以返回繼續工作,甚至都不需要通知使用者任務已經完成。

匹配該模式的兩種型別任務:

有多種方式來實現遠端過程呼叫rpc,比如rest api、soap、thrift等,這些傳統的rpc實現方法有共同之處:客戶端和伺服器緊密相連、而且要等待返回結果。另外考慮這些問題:

通過mq伺服器來實現時,只是簡單地發布訊息而已,將訊息路由到合適的地方放,通過多台rpc伺服器對訊息進行負載均衡,當處理訊息的伺服器崩潰時,將rpc訊息重發到另一台。

現在的問題在於,如果將應答返回給客戶端?

rabbitmq使用訊息來發回應答,在amqp訊息頭里有乙個字段叫做reply_to,訊息的生成者可以通過該字段來確定佇列名稱,並監聽佇列等待應答,訊息接收者能夠檢查reply_to欄位,並建立包含應答內容的新的訊息,並以佇列名稱作為路由鍵。

關於reply_to的佇列名稱,如果生成者宣告了沒有名字的佇列,rabbitmq為自動生成乙個唯一的佇列名,同時在宣告的時候指定exclusive引數,確保只有建立佇列的生產者可以讀取佇列上的訊息。

這樣,所有rpc客戶端要做的,就是宣告臨時的、排他的、匿名佇列,並將該佇列名稱包含到rpc訊息的reply_to頭中,這樣伺服器端就知道應答訊息該發往哪兒了。

很多場景使用「發後即忘」模型,不需要處理者響應,如果需要響應,可以使用rabbitmq的rpc模型。

RabbitMQ實戰 理解訊息通訊

前段時間總結完了 深入淺出mybatis 系列,對mybatis有了更全面和深入的了解,在掘金社群也收到了一些博友的喜歡,很高興。另外,短暫的陪產假就要結束了,小寶也二周了,下周二就要投入工作了,希望自己盡快調整過來,加油努力。從本篇開始總結 rabbitmq實戰 系列的閱讀筆記,rabbitmq是...

RabbitMQ實戰 理解訊息通訊

rabbitmq是乙個開源的訊息 和佇列伺服器,可以通過基本協議在完全不同的應用之間共享資料,可以將作業排隊以便讓分布式服務進行處理。本篇介紹下訊息通訊,首先介紹基礎概念,將這些概念對映到amqp協議,然後介紹訊息持久化 傳送方確認模式等訊息可靠性保證。通過本篇介紹,你會了解到 訊息通訊概念 此部分...

RabbitMQ實戰 訊息通訊模式和最佳實踐

本系列是 rabbitmq實戰 高效部署分布式訊息佇列 書籍的總結筆記。通過介紹,你會了解到 主要從非同步狀態思維 處理能力擴充套件性 整合複雜度方面,說明面向訊息通訊的好處。非同步狀態思維 當將訊息通訊整合到應用程式時,開發模式將從同步模型變為非同步模型,rabbitmq提供了不同的方法,允許我們...