所謂模式，就是在某種場景下，一類問題及其解決方案的總結歸納。生產消費者模式與訂閱發布模式是使用訊息中介軟體時常用的兩種模式，用於功能解耦和分布式系統間的訊息通訊，以下面兩種場景為例：
這樣做的好處有：第一，功能分離，上報的api介面不關心資料處理功能，只負責接入資料；第二，資料緩衝，資料上報的速率是不可控的，取決於使用者使用頻率，採用該模式可以一定程度地緩衝資料；第三，易於擴充套件，在資料量大時，通過增加資料處理worker來擴充套件，提高處理速率。這便是典型的生產消費者模式，資料上報為生產者，資料處理為消費者。
事件分發
假設有乙個電商系統，那麼，使用者「收藏」、「下單」、「付款」等行為都是非常重要的事件，通常後端服務在完成相應的功能處理外，還需要在這些事件點上做很多其他處理動作，比如傳送簡訊通知、記錄使用者積分等等。我們可以將這些額外的處理動作放到每個模組中，但這並不是優雅的實現，不利於功能解耦和**維護。
我們需要的是乙個事件分發系統，在各個功能模組中將對應的事件發布出來，由對其感興趣的處理者進行處理。這裡涉及兩個角色：a對b感興趣，a是處理者，b是事件，由事件處理器完成二者的繫結，並向訊息中心訂閱事件。服務模組是後端的業務邏輯服務，在不同的事件點發布事件，事件經過訊息中心分發給事件處理器對應的處理者。整個流程如下圖所示。這邊是典型的訂閱發布模式。
可以看到，生產消費者模式與訂閱發布模式都離不開訊息中介軟體來作為訊息中轉站，開源的訊息中介軟體有很多，各有優劣。本文將重點**rabbitmq的特性，以及如何實現上述的兩種場景。
rabbitmq核心概念
生產消費者模式搞清楚了rabbitmq的核心概念，要針對特定的場景來設計使用方案就很簡單了，基本上就是上述rabbitmq架構圖的變遷。讓我們先來看看文章開頭提到的「資料接入」場景，如何實現生產消費者模式。
這裡增加了一下場景複雜度：對於上報的資料，如果是special的行為，需要優先處理。從上圖可以看到，資料上報端負責將資料投遞到rabbitmq對應的exchange，並指明routing_key是common還是special。資料處理端，可以根據情況啟多個woker來消費資料，但至少需要兩個，乙個用來處理common資料，乙個用來處理special的資料。注意：當需要增加多個worker來消費同一類資料時，需要保持queue名字一致，比如上面的common資料。
訂閱發布模式再來看「事件分發」的場景，架構如下圖所示，使用event name/id來作為rabbitmq的routing key的名字。event processor 01對event 01 和event 02感興趣，則在啟動consumer worker時，將自己的queue繫結到這兩個routing key上即可，其他event processor也是如此，這樣便完成了事件的訂閱。當有事件發布時，訊息便會按照event name/id被投遞到對應的queue中。
由此可見，在不同的應用中，變化的只是routing_key與consumer queue的繫結關係，在充分理解rabbitmq的核心概念後處理這些應該也是得心應手了。
RabbitMQ生產者消費者模型
生產者 mport pika connection pika.blockingconnection pika.connectionparameters host 127.0.0.1 建立乙個例項 channel connection.channel 宣告乙個管道 channel.queue decl...
RabbitMQ下的生產消費者模式與訂閱發布模式
所謂模式，就是在某種場景下，一類問題及其解決方案的總結歸納。生產消費者模式與訂閱發布模式是使用訊息中介軟體時常用的兩種模式，用於功能解耦和分布式系統間的訊息通訊，以下面兩種場景為例 可以看到，生產消費者模式與訂閱發布模式都離不開訊息中介軟體來作為訊息中轉站，開源的訊息中介軟體有很多，各有優劣。本文將...
RabbitMQ下的生產消費者模式與訂閱發布模式
所謂模式，就是在某種場景下，一類問題及其解決方案的總結歸納。生產消費者模式與訂閱發布模式是使用訊息中介軟體時常用的兩種模式，用於功能解耦和分布式系統間的訊息通訊，以下面兩種場景為例 這樣做的好處有 第一，功能分離，上報的api介面不關心資料處理功能，只負責接入資料 第二，資料緩衝，資料上報的速率是不...