目錄
1.核心API
2.交換機類型
3.持久化
4.網絡通信
5.小結
1.核心API
消息隊列服務器（Broker Server），要提供的核心API?
1.創建隊列（queueDeclare）
此處不使用 Create 這樣的術語，而是使用 Declare，是因為：
Create 就只是單純的“創建”
Declare 起到的效果：不存在就創建，存在就什么都不做
2.銷毀隊列（queueDelete）
3.創建交換機（exchangeDeclare）
4.銷毀交換機（exchangeDelete）
5.創建綁定（queueBind）
6.解除綁定（queueUnbind）
7.發布消息（basicPublish）
8.訂閱消息（basicConsume）
9.確認消息（basicAck）
與TCP通過確認應答類似：
? ? ? ? 這個API起到的效果，是可以讓消費者顯式的告訴broker server，這個消息我已經處理完畢了
? ? ? ? 提高整個系統的可靠性，保證消息處理沒有遺漏
問題：為什么沒有消費消息的API？
對于MQ和消費者之間的工作模式，有兩種：
1.Push（推） Broker 把收到的數據 ，主動發給訂閱的消費者。RabbitMQ只支持 推 的方式。
2.Pull（拉）消費者主動調用Broker 的 API 取數據。Kafka就能支持拉。
2.交換機類型
????????交換機在轉發消息的時候，有一套轉發的規則。提供幾種不同的交換機類型（ExchangeType）來描述不同的轉發規則。
RabbitMQ主要實現了 四種 交換機類型 （AMPQ協議定義）
1.Direct?直接交換機
2.Fanout 扇出交換機
3.Topic 主題交換機
4.Header 消息頭交換機? （規則復雜，應用場景少）
1.Direct直接交換機
????????生產者發送消息的時候，就會指定“目標隊列”的名字。交換機收到之后，就看綁定的隊列里有沒有匹配的隊列，如果有轉發過去（把消息塞到對應的隊列中），如果沒有就丟棄。
2.Fanout扇出交換機
????????生產者發送消息，交換機收到之后，就把消息轉發給綁定的所有隊列。
3.Topic主題交換機
關鍵概念：
1.bindingKey：把隊列和交換機綁定的時候，指定一個單詞（像一個暗號）
2.routingKey：生產者發送消息的時候，也指定一個單詞
如果當前bindingKey和routingKey 能夠對上暗號，此時就把這個消息轉發到對應的隊列里。
3.持久化
????????虛擬主機，交換機，隊列，綁定，消息等都需要Broker Server 組織管理。所以這些對應的數據需要存儲和管理起來。此時內存和硬盤都會各自存儲一份，以內存為主，硬盤為輔。
內存存儲的原因：
? ? ? ? 對于MQ來說，能夠高效的轉發處理數據，是非常關鍵的指標。因此使用內存來組織上述數據，得到的效率，就比硬盤中高的多。
硬盤存儲的原因：
? ? ? ? 為了防止內存的數據隨著 進程重啟/主機重啟 丟失。
4.網絡通信
其他服務器（生產者/消費者）通過網絡，與Broker Server進行交互。
此處采用：TCP + 自定義應用層協議 實現 生產者/消費者 和Broker Server 之間的交互工作
主要工作：
????????客戶端通過網絡調用Broker Server 提供的編程接口，所以客戶端這邊也要提供上述API，只不過服務器的上述API是真正的業務邏輯，客戶端這邊僅僅知識發送請求和接收響應。
雖然調用的是本地方法，實際上就像似調用了一個遠端服務器方法一樣 -> 遠程過程調用（RPC）
遠程過程調用（RPC）：
? ? ? ? 簡單解釋：可以視為編寫客戶端服務器程序，通信過程的一種設計思想。
5.小結
通過需求分析的出具體要做的事情：
1.需要實現生產者 ， Broker Server，消費者三部分。
?生產者和消費者，主要編寫客戶端和服務器的網絡通信部分。消費者和生產者具體的業務邏輯并不關心，給客戶端一組API，讓客戶端的業務代碼通過網絡通信來調用Broker Server上的方法即可。
2.實現Broker Server 以及 Broker Server 內部的一些基本概念和核心API
3.持久化
把上述這些關鍵數據，在硬盤中的存儲。
解決存儲在數據庫/文件中，以及后續服務器重啟重新獲取上述數據的問題。
最終目標：
實現一個分布式系統下的生產者消費者模型（不支持分布式部署功能），只是一個單機的Broker Server，但是能給多個生產者消費者服務。
專業的 MQ 都是支持集群的：
優點：
1.提高可用性
2.處理更高的并發
3.數據互相備份
