如何實現amqp協議分析

這篇文章給大家介紹如何實現amqp協議分析，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

AMQP協議

博客分類：




• 其它

網絡協議Exchange應用服務器網絡應用算法 

        當前各種應用大量使用異步消息模型，并隨之產生眾多消息中間件產品及協議，標準的不一致使應用與中間件之間的耦合限制產品的選擇，并增加維護成本。AMQP是一個提供統一消息服務的應用層標準協議，基于此協議的客戶端與消息中間件可傳遞消息，并不受客戶端/中間件不同產品，不同開發語言等條件的限制。 

        當然這種降低耦合的機制是基于與上層產品，語言無關的協議。AMQP協議是一種二進制協議，提供客戶端應用與消息中間件之間異步、安全、高效地交互。從整體來看，AMQP協議可劃分為三層： 
   
                          
  
        這種分層架構類似于OSI網絡協議，可替換各層實現而不影響與其它層的交互。AMQP定義了合適的服務器端域模型，用于規范服務器的行為(AMQP服務器端可稱為broker)。在這里Model層決定這些基本域模型所產生的行為，這種行為在AMQP中用”command”表示，在后文中會著重來分析這些域模型。Session層定義客戶端與broker之間的通信(通信雙方都是一個peer，可互稱做partner)，為command的可靠傳輸提供保障。Transport層專注于數據傳送，并與Session保持交互，接受上層的數據，組裝成二進制流，傳送到receiver后再解析數據，交付給Session層。Session層需要Transport層完成網絡異常情況的匯報，順序傳送command等工作。 

        上面是對AMQP協議的大致說明。下面會以我們對消息服務的需求來理解AMQP所提供的域模型。 

        消息中間件的主要功能是消息的路由(Routing)和緩存(Buffering)。在AMQP中提供類似功能的兩種域模型：Exchange 和 Message queue。 
 

        Exchange接收消息生產者(Message Producer)發送的消息根據不同的路由算法將消息發送往Message queue。Message queue會在消息不能被正常消費時緩存這些消息，具體的緩存策略由實現者決定，當message queue與消息消費者(Message consumer)之間的連接通暢時，Message queue有將消息轉發到consumer的責任。 

       Message是當前模型中所操縱的基本單位，它由Producer產生，經過Broker被Consumer所消費。它的基本結構有兩部分: Header和Body。Header是由Producer添加上的各種屬性的集合，這些屬性有控制Message是否可被緩存，接收的queue是哪個，優先級是多少等。Body是真正需要傳送的數據，它是對Broker不可見的二進制數據流，在傳輸過程中不應該受到影響。 

        一個broker中會存在多個Message queue，Exchange怎樣知道它要把消息發送到哪個Message queue中去呢? 這就是上圖中所展示Binding的作用。Message queue的創建是由client application控制的，在創建Message queue后需要確定它來接收并保存哪個Exchange路由的結果。Binding是用來關聯Exchange與Message queue的域模型。Client application控制Exchange與某個特定Message queue關聯，并將這個queue接受哪種消息的條件綁定到Exchange，這個條件也叫Binding key 或是 Criteria。 

        在與多個Message queue關聯后，Exchange中就會存在一個路由表，這個表中存儲著每個Message queue所需要消息的限制條件。Exchange就會檢查它接受到的每個Message的Header及Body信息，來決定將Message路由到哪個queue中去。Message的Header中應該有個屬性叫Routing Key，它由Message發送者產生，提供給Exchange路由這條Message的標準。Exchange根據不同路由算法有不同有Exchange Type。比如有Direct類似，需要Binding key 等于Routing key；也有Binding key與Routing key符合一個模式關系；也有根據Message包含的某些屬性來判斷。一些基礎的路由算法由AMQP所提供，client application也可以自定義各種自己的擴展路由算法。 

        
        在這里有個新名詞需要介紹: Virtual Host。一個Virtual Host可持有一些Exchange和Message queue。它是一個虛擬概念，一個Virtual Host可以是一臺服務器，也可以是由多臺服務器組成的集群。同步擴展下，Exchange與Message queue的部署也可以是一臺或是多臺服務器上。 

        Message的產生者和消費者可能是同一個應用。整個AMQP定義的就是Client application與Broker之間的交互。在粗略介紹完AMQP的域模型后，可以關注下Client是怎樣與Broker建立起連接的。 

        在AMQP中，Client application想要與Broker溝通，就需要建立起與Broker的connection，這種connection其實是與Virtual Host相關聯的，也就是說，connection是建立在client與Virtual Host之間。可以在一個connection上并發運行多個channel，每個channel執行與Broker的通信，我們前面提供的session就是依附于channel上的。 

        這里的Session可以有多種定義，既可以表示AMQP內部提供的command分發機制，也可以說是在宏觀上區別與域模型的接口。正常理解就是我們平時所說的交互context，主要作用就是在網絡上可靠地傳遞每一個command。在AMQP的設計中，應當是借鑒了TCP的各種設計，用于保證這種可靠性。 

        在Session層，為上層所需要交互的每個command分配一個惟一標識符(可以是一個UUID)，是為了在傳輸過程中可以對command做校驗和重傳。Command發送端也需要記錄每個發送出去的command到Replay Buffer，以期得到接收方的回饋，保證 這個command被接收方明確地接收或是已執行這個command。對于超時沒有收到反饋的command，發送方再次重傳。如果接收方已明確地回饋信息想要告知command發送方但這條信息在中途丟失或是其它問題發送方沒有收到，那么發送方不斷重傳會對接收方產生影響，為了降低這種影響，command接收方設置一個過濾器Idempotency Barrier，來攔截那些已接收過的command。 

關于如何實現amqp協議分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。