1、簡單佇列模式

該模式不需要生命Exchange僅使用queue佇列來直接交換訊息。

消費者訊息應答no-ack
channel.basic_consume(callback,queue='hello',no_ack=True)，預設情況no_ack=False表示consumer完成訊息處理後需手動應答。向生佇列伺服器說明訊息已處理完成，可以刪除。
如果消費者遇到情況(its channel is closed, connection is closed, or TCP connection is lost)掛掉了，那麼，RabbitMQ會重新將該任務新增到佇列中，並由其他consumer獲取該訊息，確保訊息不會丟失。
消費者回調函式中ch.basic_ack(delivery_tag=method.delivery_tag)，表示手動應答了伺服器。

服務端持久化
RabbitMQ支援訊息的持久化，也就是資料寫在磁碟上，當我們需要可靠的訊息處理的時候應該設定訊息持久化。訊息佇列持久化包括3個部分:

(1)exchange持久化，在宣告時指定durable => 1

(2)queue持久化，在宣告時指定durable => 1

(3)訊息持久化，在投遞時指定delivery_mode => 2(1是非持久化)

如果exchange和queue都是持久化的，那麼它們之間的binding也是持久化的。如果exchange和queue兩者之間有一個持久化，一個非持久化，就不允許建立繫結。

 訊息分發順序

預設狀態下，RabbitMQ將第n個Message分發給第n個Consumer。當然n是取餘後的。它不管Consumer是否還有unacked Message，只是按照這個預設機制進行分發。那麼如果有個Consumer工作比較重，那麼就會導致有的Consumer基本沒事可做，有的Consumer卻是毫無休息的機會。那麼，RabbitMQ是如何處理這種問題呢？
通過 basic.qos 方法設定prefetch_count=1 。這樣RabbitMQ就會使得每個Consumer在同一個時間點最多處理一個Message。換句話說，在接收到該Consumer的ack前，他它不會將新的Message分發給它。


最終版本
設定訊息確認，伺服器的持久化，和訊息分發順序後，最終版本