所謂模式，就是在某種場景下，一類問題及其解決方案的總結歸納。生產消費者模式與訂閱發布模式是使用訊息中介軟體時常用的兩種模式，用於功能解耦和分布式系統間的訊息通訊，以下面兩種場景為例：
這樣做的好處有：第一，功能分離，上報的api介面不關心資料處理功能，只負責接入資料；第二，資料緩衝，資料上報的速率是不可控的，取決於使用者使用頻率，採用該模式可以一定程度地緩衝資料；第三，易於擴充套件，在資料量大時，通過增加資料處理worker來擴充套件，提高處理速率。這便是典型的生產消費者模式，資料上報為生產者，資料處理為消費者。
事件分發
假設有乙個電商系統，那麼，使用者「收藏」、「下單」、「付款」等行為都是非常重要的事件，通常後端服務在完成相應的功能處理外，還需要在這些事件點上做很多其他處理動作，比如傳送簡訊通知、記錄使用者積分等等。我們可以將這些額外的處理動作放到每個模組中，但這並不是優雅的實現，不利於功能解耦和**維護。
我們需要的是乙個事件分發系統，在各個功能模組中將對應的事件發布出來，由對其感興趣的處理者進行處理。這裡涉及兩個角色：a對b感興趣，a是處理者，b是事件，由事件處理器完成二者的繫結，並向訊息中心訂閱事件。服務模組是後端的業務邏輯服務，在不同的事件點發布事件，事件經過訊息中心分發給事件處理器對應的處理者。整個流程如下圖所示。這邊是典型的訂閱發布模式。
可以看到，生產消費者模式與訂閱發布模式都離不開訊息中介軟體來作為訊息中轉站，開源的訊息中介軟體有很多，各有優劣。本文將重點**rabbitmq的特性，以及如何實現上述的兩種場景。
rabbitmq核心概念
通訊方式
rabbitmq是基於amqp協議來實現的訊息中介軟體。amqp，類似於http協議，也是乙個應用層的協議，網路層使用tcp來通訊。因此，rabbitmq也是典型的c-s模型，準確地說是c-s-c模型，因為伴隨著rabbitmq的使用，總是會有producer與consumer兩個client和乙個broker server。
client要與server進行通訊，就必須先建立連線，rabbitmq中有connection與channel兩個概念，前者就是乙個tcp連線，後者是在這個連線上的虛擬概念，負責邏輯上的資料傳遞，因此，為了節省資源，一般在乙個客戶端中建立乙個connection，每次使用時再分配乙個channel即可。
訊息體
message是rabbitmq中的訊息體概念。類似http傳輸中，有header和body兩部分資料，message中也有attributes和payload兩部分資料，前者是一些元資訊，後者是傳遞的訊息資料實體。
訊息投遞
exchange、queue與routing key三個概念是理解rabbitmq訊息投遞的關鍵。rabbitmq中乙個核心的原則是，訊息不能直接投遞到queue中。producer只能將自己的訊息投遞到exchange中，由exchange按照routing_key投遞到對應的queue中，具體的架構參見下圖。細細品味就會體會到這樣設計的精妙之處。
那麼，具體實現時，如何完成這三者關係的繫結？總結起來是兩點：第一，在consumer worker中，宣告自己對哪個exchange感興趣，並將自己的queue繫結到自己感興趣的一組routing_key上，建立相應的對映關係；第二，在producer中，將訊息投遞乙個exchange中，並指明它的routing_key。由此可見，queue這個概念只是對consumer可見，producer並不關心訊息被投遞到哪個queue中。
看過rabbitmq的」hello world」教程的童鞋可能會發現在那裡面的圖中並沒有看到exchange和routing_key的蹤跡，但這並不意味著rabbitmq可以支援直接將訊息投遞到queue中，而是在內部使用了預設的exchange和routing_key了。預設情況下，rabbitmq使用名稱為「amq.direct」的direct exchange，routing_key預設名字與queue保持一致。
搞清楚上述概念，就不難理解exchange的四種型別了。direct、fanout、topic、headers，區別在於如何將訊息從exchange投遞到queue中。direct使用具體的routing_key來投遞；fanout則忽略routing_key，直接廣播給所有的queue；topic是使用模糊匹配來對一組routing_key進行投遞；headers也是忽略routing_key，使用訊息中的headers資訊來投遞。
訊息可靠性
不同於http的同步訪問，rabbitmq中，producer並不知道訊息是否被可靠地投遞到了consumer中處理。那麼，rabbitmq是如何保證訊息的可靠投遞？主要是兩點：第一，訊息確認機制。consumer處理完訊息後，需要傳送確認訊息給broker server，可以選擇「確認接收」、「丟棄」、「重新投遞」三種方式。如果consumer在broker server收到確認訊息之前掛了，broker server便會重新投遞該訊息。第二，可以選擇資料持久化，這樣即使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的核心概念後處理這些應該也是得心應手了。
EPOLL兩種模式
select epoll 的特點 select 的特點 select 選擇控制代碼的時候，是遍歷所有控制代碼，也就是說控制代碼有事件響應時，select 需要遍歷所有控制代碼才能獲取到哪些控制代碼有事件通知，因此效率是非常低。但是如果連線很少的情況下，select 和epoll的lt 觸發模式相比，...
ftp的兩種模式
常用ftp的人都知道，ftp在傳輸檔案的時候分為兩種模式 ascii模式 和 二進位制模式 1 ascii模式是一般是用來傳輸文字檔案的 2 二進位制模式是用來傳輸二進位制檔案的 一般我們使用ftp工具進行檔案傳輸的時候，工具內部應該會識別檔案型別，而如果我們使用windows內建的ftp，在命令列...
XML的兩種模式
color darkblue size medium 在xml使用過程中，往往需要對xml的有效性進行驗證。只要不違反xml格式良好的規則，就可以自由選取標記的名字，用自己習慣的方式描述事物。這就意味著用xml描述相同的事物時，不同的編寫者可能寫出含有不同標記名 採用不同結構的xml文件，這對於資料...