我覺得 消息隊列正確的用法 應該是一個生產者對應一個 交換機。 一個 消費者對應一個 隊列， 至于 分發的邏輯 是通過各種綁定來實現的。

例如 電子商務場景：產生訂單的有很多 渠道 比如網站，團購，秒殺，第三方等等。每個 都 對應一個 交換機。產生的訂單 數據是類似的 但key 可以是 商品類別加上id 等信息組合。比如 大類.小類.商品id 這種格式

剛開始的時候 只有一個 總倉 訂單處理也就一個程序 一個消費者 也就一個隊列。 所有交換機都綁定這個隊列。這樣所有訂單都到總倉去了

慢慢生意大了 比如生鮮分出去了個 倉 有單獨的處理程序了 也成了個新的隊列 這樣 在mq 后臺 根據key 中大類是生鮮的綁定到新的隊列就好了

再過段時間 某次秒殺，預計量比較大。實現準備了個小倉庫 把這個秒殺商品預先包好存放在那單獨處理了。這時運行個 新的程序 產生個 新的隊列 ，這時就將秒殺交換機的 按照key 中的id為此商品的 綁定到新的隊列。這樣就可以了 而無論是秒殺的其他產品，還是在其他渠道上這個商品訂單還是 總倉處理

其實 交換機還可以再綁交換機 多次分發更實現更復雜的邏輯。就是這么綁來綁去，實現 不用改代碼就實現了整個信息流隨著業務的變遷

你所說的簡單的例子沒有聲明交換器，用雙引號（即空字符串）表示，但實際他是調用了默認的交換器，并以隊列名作為路由鍵發布消息！消費端也是看似沒有綁定交換器，但底層卻是根據隊列名作為路由鍵進行綁定！交換器始終是存在的，不存在生產者直接將消息發送給隊列

AMQP協議中的核心思想就是生產者和消費者隔離，生產者從不直接將消息發送給隊列。生產者通常不知道是否一個消息會被發送到隊列中，只是將消息發送到一個交換機。先由Exchange來接收，然后Exchange按照特定的策略轉發到Queue進行存儲。同理，消費者也是如此。Exchange 就類似于一個交換機，轉發各個消息分發到相應的隊列中。