一、消息確認機制
rabbitmq在發送消息後立即從內存中刪除消息，因此如果消費者處理消息耗時較長，在處理過程中消費者被kill，則處理中的消息、以及其他發往該消費者的消息都將丟失。
爲了保證消息不丟失，rabbitmq支持消息確認機制，消費者可以發送ack告訴rabbitm指定消息已經收到並處理，因此rabbitmq可以刪除該消息。
如果消費者死掉（channel關閉、connection關閉、或者TCP connection丟失），導致rabbitmq沒有收到ack，rabbitmq將把消息重入隊列。
不存在消息超時，這意味着處理一個消息非常長的時間也是ok的。
消息確認機制默認是開啓的，通過在channel.basic_consume中設置no_ack=True關閉。
注意消費者在處理消息後，不要忘記調用channel.basic_ack進行消息確認，否則rabbitmq將不斷消耗內存把消息重入隊列。
二、隊列/消息持久化
爲了防止rabbitmq服務終止導致隊列和消息丟失，需要將隊列和消息標記爲持久化的：
確保rabbitmq永遠不丟失隊列，需要將隊列 聲明爲持久化的：
channel.queue_declare(queue='task_queue', durable=True)
將消息聲明爲持久化的：
channel.basic_publish(exchange='', routing_key="task_queue", body=message, properties=pika.BasicProperties( delivery_mode = 2, # make message persistent ))
注意：儘管已經很健壯了，但是仍然無法完全保證消息不會丟失，例如rabbitmq接收消息但是還沒有保存到硬盤的情況。
三、exchange
簡單的說，exchange的一端接收消息，另一端把消息放進隊列。
在rabbitmq中生產者不會將請求直接發送給消費者，生產值只會把消息發給exchange，exchange收到消息後需要知道怎麼做：添加到特定隊列、添加到多個隊列、還是丟棄。
exchange的類型包括direct,topic,headers,fanout
四、綁定
exchange和queue之間的聯繫被稱爲綁定(binding)，可以簡單的看：隊列對於特定exchange上的消息感興趣
channel.queue_bind(exchange='logs', queue=result.method.queue)
此時'logs' exchange將添加消息到指定queue
綁定可以使用一個額外的routing_key參數，例如：
channel.queue_bind(exchange=exchange_name, queue=queue_name, routing_key='black')
對於fanout類型的exchange來說，routing_key參數是被忽略的
五、topic exchange
發往topic exchange的消息不能攜帶任意的routing_key，必須是以點隔開的一串字符，最大255個字節
binding key也必須是相同的形式，注意binding key有兩個重要的特殊情況：
* 可以替代一個單詞
#可以替代零個或多個單詞
例如，如果binding key是*.orange.*，則可以匹配所有<one word>.orange.<one word>的key，但是如果key不是*.*.*的形式，例如orange，或者quick.orange.male.rabbit，則消息將被丟棄。
如果binding key是lazy.#，則類似於帶有lazy.orange.male.rabbit的key的消息可以匹配。
topic exchange非常強大，通過匹配routing_key可以表現的像存在多個exchange
六、RPC
爲了接收響應，客戶端需要在發送請求時附加發送回調隊列地址：
result = channel.queue_declare(exclusive=True) callback_queue = result.method.queue channel.basic_publish(exchange='', routing_key='rpc_queue', properties=pika.BasicProperties( reply_to = callback_queue, ), body=request) # ... and some code to read a response message from the callback_queue ...