聊聊消息中間件(1)，AMQP那些事兒
開篇
說到消息隊列，相信大家並不陌生。大家在日常的工作中其實都有用過。相信大部分的研發在使用消息隊列的過程中也僅僅是停留在用上面，裡面的知識點掌握得並不是很系統，有部分強大的功能可能由於本身公司的業務形態或者業務量級的原因根本無法觸及到。老貓在工作中就是如此，所使用的MQ都是架構師封裝好的，簡單調用即可。為了更好地了解其所以然，所以老貓就花時間好好梳理了一下MQ的一系列的知識點，俗話說「好記心不如爛筆頭」，所以老貓在學習的過程中就記錄了下來。分享出來給有需要的小夥伴，當然也方便後續自己查閱，因此就有了該系列文章。
AMQP協議簡介
大家在工作中很多就接觸過RabbitMq，其實RabbitMq就是AMQP協議的一種實現。
與其說AMQP是一種協議，其實它更是一種標準。是應用層協議的一個開放標準，為面向消息的中間件設計。AMQP是一個進程間傳遞非同步消息的網路協議。 全稱為AMQP（Advanced Message Queuing Protocol）。基於此協議的客戶端與消息中間件可傳遞消息，並不受客戶端/中間件不同產品，不同開發語言等條件的限制。AMQP的主要特徵是面向消息、隊列、路由（包括點對點和發布/訂閱）、可靠性、安全。AMQP在消息提供者和客戶端的行為進行了強制規定，使得不同賣商之間真正實現了互操作能力。
關於Kafka和AMQP單獨補充一個點
相信大家的工作日常中除了用RabbitMQ之外很多小夥伴也用過kafka吧，那麼kafka和AMQP有什麼關係么？
答案是：沒關係。
Kafka根本不是消息隊列。按官方說法，Kafka是一個流式處理平台（stream processing platform）。Kafka在設計之初是為了支援高吞吐量的日誌處理的，只不過它恰好也可以實現消息隊列的大部分功能而已。Kafka所用的「黑科技」（例如零拷貝/記憶體映射，以及對page cache的利用，當然這些後續分享kafka的時候再和小夥伴同步）都是脫離標準消息隊列的設計範疇的，所以不能簡單地認為Kafka比RabbitMQ等符合AMQP的消息隊列更優。例如，RabbitMQ支援死信隊列、延遲隊列、優先隊列、多租戶、推模式消費等，Kafka統統不支援。
AMQP和JMS的區別
說到AMQP協議，就不得不聊JMS。 JMS是早期消息中間件進行標準化的一個嘗試，它僅僅是在API級進行了規範。 只適用於Java平台的消息中間件規範，支援Java應用程式之間進行消息交換。並且通過提供標準的生產、發送、接收消息的介面簡化企業應用的開發。 如果想要詳細了解JMS的小夥伴其實百度百科就有很詳細的講解。具體鏈接：//baike.baidu.com/item/JMS/2836691?fr=aladdin，
另外如果有小夥伴想要其具體的介面文檔，可以在此進行下載：//download.oracle.com/otndocs/jcp/7195-jms-1.1-fr-spec-oth-JSpec/
JMS簡單概括
JMS主要包括兩種模型，（1）點對點模型（2）發布訂閱模型
點對點：生產者向隊列投遞一條消息只有一個監聽者才能獲取該條消息。
發布訂閱：生產者向隊列投遞一條消息，所有監聽該隊列的訂閱者都可以拿到該消息。
JMS 五種不同的消息正文格式
JMS定義了五種不同的消息正文格式，以及調用的消息類型，允許你發送並接收以一些不同形式的數據，提供現有消息格式的一些級別的兼容性。
- StreamMessage – Java原始值的數據流
- MapMessage–一套名稱-值對
- TextMessage–一個字元串對象
- ObjectMessage–一個序列化的 Java對象
- BytesMessage–一個位元組的數據流
AMQP模型概括
AMQP模型如下
- Server：又稱Broker，接受客戶端的連接，實現AMQP實體服務。
- Connection：連接，應用程式與Broker的網路連接。
- Channel：網路信道。幾乎所有的操作都在Channel中進行，Channel是進行消息讀寫的通道。客戶端可建立多個Channel，每個Channel代表一個會話任務。
- Message：消息，伺服器和應用程式之間傳送的數據，由Properties和body組成，Properties可以對消息進行修飾，比如消息的優先順序、延遲等高級特性；Body則是消息主體。
- Virtual host：虛擬地址，由於進行邏輯隔離，最上層的消息路由。一個Virtual Host裡面可以有若干個Exchange和Queue,同一個Virtual Host裡面不能有相同名稱的Exchange或Queue。
- Exchange：交換機，接收消息，根據路由鍵轉發消息到綁定的隊列。
- Binding：Exchange和Queue之間的虛擬連接，binding中可以包含routing Key。
- Routing Key：一個路由規則，虛擬機可以用它來確定如何路由一個特定消息。
- Queue：也稱為Message Queue,消息隊列，保存消息並將它們轉發給消費者。
AMQP和JMS對比
上述做了一些簡單的概括，如果小夥伴覺得有所欠缺，不是太全，那麼可以自行查閱相關資料。
| 對比方向 | JMS | AMQP |
|---|---|---|
| 定義 | Java API | 協議 |
| 跨語言 | 否 | 是 |
| 跨平台 | 否 | 是 |
| 對比模型 | ①Peer-2-Peer（點對點）; ②Pub/sub（發布訂閱） |
①direct exchange； ②fanout exchange； ③topic change； ④headers exchange； ⑤system exchange。 本質來講，後四種和JMS的pub/sub模型沒有太大差別， 僅是在路由機制上做了更詳細的劃分； （這塊後續老貓和大家分享rabbitMq的時候會詳細說到） |
| 消息類型 | 支援多種消息類型 ， 我們在上面提到過 |
byte[]（二進位） |
寫在最後
關於AMQP協議的簡單介紹大概就到這裡。有小夥伴覺得不夠詳細的地方當然也可以自發去找找更多的資料。後面老貓會重點整理RabbitMq以及Kafka的知識點和大家分享。期待你的持續關注。
