RabbitMQ：1、入門

消息中間件

• 使用消息中間件的做用

  • 解耦
  • 削峯
  • 異步
  • 順序保證
  • 冗餘（存儲）

• RabbitMQ的特色

  • 可靠性
  • 靈活的路由
  • 擴展性
  • 高可用
  • 多語言客戶端
  • 插件機制
  • 多協議（主要仍是AMQP）

相關概念

• Producer：生產者，投遞消息的一方
• Consumer：消費者，接收消息的一方
• Broker：RabbitMQ的服務節點
• Queue：隊列，是RabbitMQ的內部對象，用於存儲消息。RabbitMQ中消息只能存儲在隊列中，這一點和Kafka這種消息中間件相反。Kafka將消息存儲在topic（主題）這個邏輯層面，而相應的隊列邏輯只是topic實際存儲文件中的位移標識。RabbitMQ 的生產者生產消息井最終技遞到隊列中，消費者能夠從隊列中獲取消息並消費。
  多個消費者能夠訂閱同一個隊列，這時隊列中的消息會被平均分攤 CRound-Robin ，即輪詢)
  給多個消費者進行處理，而不是每一個消費者都收到全部的消息井處理，如圖所示
  
  RabbitMQ 不支持隊列層面的廣播消費，若是須要廣播消費，須要在其上進行 次開發，處理邏輯會變得異常複雜，同時也不建議這麼作。
• Exchange：交換器。上圖看起來像是咱們將消息丟到消息隊列當中，實際上這在rabbitMQ中不會發生。實際上生產者將消息丟到交換器中，由交換器將消息路由到一個或者多個隊列中。
  若是路由不到，或許返回給生產者，或許直接丟棄。交換器有四種類型。
• RoutingKey：路由鍵。生產者將消息->交換器時，通常指定一個RoutingKey來決定路由規則。RoutingKey須要和交換器類型及綁定鍵聯合使用。
• Binding：綁定。經過綁定將隊列和交換器關聯起來。綁定時通常會指定綁定鍵（BingdingKey），當RoutingKey與BingdingKey匹配時，消息會被路由到對應的隊列中。
• 交換器類型
  • fanout：把全部發送到該交換器的消息路由到全部與該交換器綁定的隊列中。
  • direct：把消息路由到那些BindingKey與RoutingKey徹底匹配的隊列中。
  • topic：與direct類型有些相似，不過隊列的匹配規則有些不一樣
    • RoutingKey爲"."號分隔的字符串（被分開的每一段獨立字符稱爲一個單詞），如"com.rabbitmq.client","java.util.concurrent"；
    • BindingKey的形式與RoutingKey同樣；
    • BindingKey能夠存在兩種特殊字符串"","#"，用於作模糊匹配，""用於匹配1個單詞，"#"用於匹配多個單詞（能夠是0個）。
  • headers：不依賴於路由鍵的規則，而是根據消息內容中的headers屬性進行匹配。綁定隊列和交換器時指定鍵值對，發送消息到交換器時，RabbitMQ會拿headers屬性裏的鍵值對進行對比，徹底匹配則會路由到對應隊列。headers類型交換器性能不好，不多使用。
• Connection：生產者與消費者和Broker之間創建的TCP鏈接。
• Channel：信道。創建在Connection之上的虛擬鏈接。RabbitMQ處理的每條AMQP指令都是經過信道完成的。
  
  RabbitMQ經過採用相似NIO的作法，選擇TCP鏈接複用，減小性能開銷，便於管理。

參考資料：RabbitMQ實戰指南