我初次看 RabbitMQ 的文件時，覺得這個東西似乎滿利害的。可是，心裡卻有很大的困擾，到底要怎麼用啊？ 何時會需要呢？被這樣子的問題困擾了很久。直到最近重新去想 open-falcon transfer 的 source code 之後，才覺得心裡的迷團解開了~。
open-falcon 的 Transfer 的架構圖，大概是類似左圖。Agent 將 metric 送進 Transfer 之後，會將 metric 分別放到兩個 queue ，一個是準備之後要送到 Judge 的資料。另一個是準備之後要送到 Graph 的資料。 當 Transfer 要跟外部的模組連線時，它用了 connection pools 的設計，跟 Judge 還有 Graph 都建立了多條的連線。因為當 Agent 多的時候， Agent 上報的 metric 數量會非常多。要讓 queue 可以不會被塞爆，其中一種方式就是透過 connections pool 建立多條連線來加快 queue 清空的速度。
上述的 Transfer 從某些角度來說，可以說是應用了兩種 RabbitMQ 的使用情境：
(1) connections pool 可以視為是
Work queues 的應用情境。因為每一條 connection 其實也可以想象成是獨立的 consumer ，或是稱之為 worker 。
(2) Transfer 內部針對要送到不同的外部模組而分別建立兩個獨立的 queues 的作法，可以視為是
Publish/Subscribe 的應用情境。在這個情境裡， 負責連線到 Judge 和 Graph 的程式碼就可以視為是獨立的兩個 consumer 。
