所謂模式，就是在某種場景下，一類問題及其解決方案的總結歸納。生產消費者模式與訂閱發布模式是使用訊息中介軟體時常用的兩種模式，用於功能解耦和分布式系統間的訊息通訊，以下面兩種場景為例：
可以看到，生產消費者模式與訂閱發布模式都離不開訊息中介軟體來作為訊息中轉站，開源的訊息中介軟體有很多，各有優劣。本文將重點**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的核心概念後處理這些應該也是得心應手了。
個人總結：
為了實現訂閱功能，其實很簡單（這是一種方式，其餘的還在研究）
1、訂閱著需要制定queue的名字，並且和exchange及key繫結，為了讓queue名字不重複，可以如下設定：
channel.exchange_declare(exchange ="hello-exchange",#宣告交換器
exchange_type="direct",
passive=false,
durable=true,
auto_delete=false)
#channel.queue_declare("hello")#宣告佇列
#channel.queue_bind(queue="hello",#通過鍵「hola」將佇列與交換器i繫結
# exchange="hello-exchange",
# routing_key="hola")
result = channel.queue_declare(exclusive=true)
queue_name = result.method.queue
channel.queue_bind(exchange='hello-exchange',queue=queue_name,routing_key="hola")
2、傳送者將訊息傳送到指定的exchangge和key中就可以了
RabbitMQ生產者消費者模型
生產者 mport pika connection pika.blockingconnection pika.connectionparameters host 127.0.0.1 建立乙個例項 channel connection.channel 宣告乙個管道 channel.queue decl...
RabbitMQ下的生產消費者模式與訂閱發布模式
所謂模式，就是在某種場景下，一類問題及其解決方案的總結歸納。生產消費者模式與訂閱發布模式是使用訊息中介軟體時常用的兩種模式，用於功能解耦和分布式系統間的訊息通訊，以下面兩種場景為例 這樣做的好處有 第一，功能分離，上報的api介面不關心資料處理功能，只負責接入資料 第二，資料緩衝，資料上報的速率是不...
RabbitMQ下的生產消費者模式與訂閱發布模式
所謂模式，就是在某種場景下，一類問題及其解決方案的總結歸納。生產消費者模式與訂閱發布模式是使用訊息中介軟體時常用的兩種模式，用於功能解耦和分布式系統間的訊息通訊，以下面兩種場景為例 這樣做的好處有 第一，功能分離，上報的api介面不關心資料處理功能，只負責接入資料 第二，資料緩衝，資料上報的速率是不...