本系列是「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提供了不同的方法，允許我們...