代碼實戰案例：【https://github.com/tiger1992/demo-rabbitmq】
【https://github.com/tiger1992/demo-rabbitmq.git】
mybatis代碼自動化生成項目：【https://github.com/tiger1992/base-mybatis-generate】
1、背景：在互聯網架構中，MQ是一種非常常見的上下游“邏輯解耦+物理解耦”的消息通信服務。
2、概念：消息中間件主要用於組件之間的解耦，消息的發送者無需知道消息使用者的存在，反之亦然。
3、常見MQ的類型：
1)、activeMQ 對java支持良好，缺點是對其他語言支持不夠友好，適合中小企業系統
2)、rabbitMQ 對java支持良好，對其他語言也支持良好，跨平臺，語言無關
3)、kaffka 日誌消息中間件 支持大數據場景
4、不應使用MQ的場景：調用方實時依賴執行結果(上游需要關注執行結果)的業務場景，也就是上游實時關注執行結果
5、MQ使用場景：
1)、數據驅動的任務依賴
2)、上游不關心多下游執行結果
3)、異步返回執行時間長
============ AMQP核心概念 ============
1、Server：又稱Broker，接收客戶端連接，實現AMQP實體服務
2、Connection：連接，應用程序與Broker的網絡連接
3、Channel：網絡信道，幾乎所有的操作都是在這上面進行，是消息讀寫的通道，客戶端可以建立多個，每個代表一個會話
4、Message：消息，服務器與應用程序之間傳送數據的載體，由Properties和Body組成。Properties可以對消息進行修飾，比如優先級、延遲等高級特性，Body是消息體內容。
5、Virtual host：虛擬主機，用於邏輯隔離，最上層的消息路由。可以有多個，一般由項目模塊劃分
6、Exchange：交換機，接收消息，根據路由鍵轉發消息到綁定的隊列
7、Binding：Exchange與Queue之間的虛擬連接，binding中可以包含routing key
8、RoutingKey：一個路由規則，虛擬機可以用它來確定如何路由一個特定的消息
9、Queue：即Message Queue，消息隊列，保存消息並將它們轉發給消費者
============ RabbitMQ簡介 ============
1、Connection是RabbitMQ的socket鏈接，它封裝了socket協議相關部分邏輯
2、ConnectionFactory爲Connection的製造工廠。
3、Channel是我們與RabbitMQ打交道的最重要的一個接口，我們大部分的業務操作是在Channel這個接口中完成的，包括定義Queue、定義Exchange、綁定Queue與Exchange、發佈消息等。
4、Message acknowledgment：消息確認，消費者再消費完一條消息後會發送一個回執確認已經消費的信息到MQ，MQ則將該消息從隊列中移除。
5、Message durability：消息持久化，到MQ服務宕機時保證未被消費的消息不丟失。
6、Prefetch count：預取計數，消息一條一條推送，消費完一條再推送一條。
7、Exchange：交換器，生產者將消息發送到Exchange（交換器，下圖中的X），由Exchange將消息路由到一個或多個Queue中（或者丟棄）。
8、routing key：路由選擇鍵，在發送消息給Exchange時，通過指定routing key來決定消息流向哪裏，與Exchange Type及binding key聯合使用才能最終生效
9、Binding：RabbitMQ中通過Binding將Exchange與Queue關聯起來，這樣RabbitMQ就知道如何正確地將消息路由到指定的Queue了。
10、
============ JMS認識 ============
1、MQ實現參照了jms規範，（規範就是一種約定）該規範中包括
2、提供者：實現jms規範的中間件服務器
3、客戶端：發送或者接受消息的應用程序
4、生產者/發佈者:創建併發送消息的客戶端
5、消費者/訂閱者:接受並處理消息的客戶端
6、消息：應用程序之間傳遞的內容
7、消息模式：在客戶端之間傳遞消息的方式，jms中定義了主題和隊列兩種模式
1)、主題模式：假如發佈者發佈了100條消息，那麼如果有n個訂閱者，每個訂閱者都可以獲取到100條消息。
2)、隊列模式：假如生產者發送了100條消息，如果有n個消費者，那麼每個消費者加起來獲取到的消息總數是100，一個消息只能被一個消費者消費。
============ 優點，爲什麼要使用消息隊列 ============
1、解耦：上下游邏輯+物理解耦，除了與MQ有物理連接，模塊之間都不相互依賴；將消息寫入消息隊列，新增一個下游消息關注方，上游不需要修改任何代碼
2、異步：上游執行時間短，將消息寫入消息隊列，非必要的業務邏輯以異步的方式運行，加快響應速度
3、削峯：系統A慢慢的按照數據庫能處理的併發量，從消息隊列中慢慢拉取消息。在生產中，這個短暫的高峯期積壓是允許的。
============ 缺點，爲什麼要使用消息隊列 ============
1、系統可用性降低:系統更復雜，多了一個MQ組件
2、消息傳遞路徑更長，延時會增加
3、消息可靠性和重複性互爲矛盾，消息不丟不重難以同時保證
4、上游無法知道下游的執行結果，這一點是很致命的
============ 什麼叫消息隊列 ============
消息（Message）是指在應用間傳送的數據。消息可以非常簡單，比如只包含文本字符串，也可以更復雜，可能包含嵌入對象。 消息隊列（Message Queue）是一種應用間的通信方式，消息發送後可以立即返回，由消息系統來確保消息的可靠傳遞。消息發佈者只管把消息發佈到 MQ 中而不用管誰來取，消息使用者只管從 MQ 中取消息而不管是誰發佈的。這樣發佈者和使用者都不用知道對方的存在。
