聊聊訊息中介軟體(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的小夥伴其實百度百科就有很詳細的講解。具體連結：https://baike.baidu.com/item/JMS/2836691?fr=aladdin，
另外如果有小夥伴想要其具體的介面檔案，可以在此進行下載：https://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的知識點和大家分享。期待你的持續關注。