RabbitMQ 上手記錄-part 1-基礎概念

RabbitMQ是什麼，不用多介紹了，畢竟名聲在那，江湖地位擺着，搜索引擎收錄着。爲何忽然去學習這個框架了，畢竟工做中沒有用得上（說來也慚愧，工做中開發的項目沒有使用這個框架）。可是做爲互聯網分佈式應用必不可少的一部分——消息服務，總要補上這塊只是空白，否則每次被別人問道消息服務是幹嗎的，老是很尷尬的轉移到發郵件、短信的服務那塊去。更重要的是要有這塊知識準備，哪天用戶量上來的或者被委以重任，也可以獨當一面。

 

消息服務功能

消息服務能幹嗎呢，固然不是僅僅發送個消息那麼簡單。據我我的知道的通常分佈式系統中消息服務的有以下做用

 

1.服務解耦

咱們設計軟件時老是提倡單一職責原則，提倡組件之間的低耦合。最低級別的耦合就是僅僅經過數據或者參數關聯，那麼這裏的數據咱們能夠經過消息服務來傳遞。也就是說，服務組件之間不知道對方的存在，調用方和被調用方之間是沒有依賴關係的。調用方發佈一個消息，而後被調用方發現有消息過來而後觸發一些列動做。那麼這裏的靈活性就很大，以及可做的文章就多了。

 

舉個例子，好比常見的用戶註冊功能，一般註冊以後有發送確認郵件，分配權限，上傳圖片，觸發統計等操做。若是不適用消息服務，那麼在代碼中須要依次實現這一系列動做，若是系統簡單這些代碼糅合在一塊兒還不算複雜。可是若是這些功能分佈在不一樣系統、服務器，那麼得針對不一樣的功能提供API或者接口。調用方和被調用方都得有一套約定才能進行通信，並且這套約定還不能重用，只能用於特定的調用。一般不止這幾個調用，實際調用關係會更加複雜

 

（直接調用API）

 

那麼使用消息服務以後，如何去解耦呢？一般消息服務都提供了消息的發佈和訂閱功能。好比這裏的用戶註冊功能，在用戶註冊以後發佈一個消息，而後其餘相關的服務訂閱了這個用戶註冊的消息以後，就會執行各自的動做。用戶註冊模塊只管發佈一個消息，其餘的無論，更不用關係哪一個API和存在哪些下游服務。那麼理論上就能夠支持不少下游服務。下游服務（郵件服務、權限服務、文件服務等）也不關心消息是誰發送的，只負責處理，也不用提供一個API給上游調用。這樣就實現了調用方和被調用方的解耦。

（使用消息服務）

 

2 負載均衡

互聯網應用講究高性能，高可用，負載均衡技術是被用得最普遍的技術之一。一般作法是提供多個服務器，實現一個集羣或者主從備份等。一般實現這種技術要求能經過增長服務的方式，經過簡單的線性擴展就能達到增長處理容量的目的。傳統的技術須要在客戶端或者服務端實現負載均衡的調度算法，而消息服務，好比RabbitMQ則能夠藉助消息分發的機制實現將消息發送到多個服務羣，增長服務只須要服務訂閱相關的消息便可，是一種簡單靈活的擴展方式。

（消息服務實現的負載均衡）

 

3 服務異構

如今一個大的應用程序一般有多個不一樣服務組成，這些服務可能用不一樣的編程語言和技術實現，可充分利用各類技術的優點，有點相似於微服務。消息服務的解耦功能使得實現技術異構變得容易。因爲消息服務實現了AMQP協議，不一樣語言的實現只要遵循這個協議，就能在不一樣應用，不一樣服務器之間實現通信。這樣使得引入新技術變得更加簡單，引入新技術實現不擔憂形成依賴，更不擔憂對原有應用形成影響。

（經過AMQP實現服務異構）

 

大概知道這幾個主要的功能點，應該說大部分MQ都有的。

 

RabbitMQ基本概念

 

接下來了解一下RabbitMQ裏面的一些基本概念，便於在正式入坑以前有個大概的印象。

 

隊列(queue)

隊列是RabbitMQ種消息的載體，能夠理解爲存儲消息的地方，生產者會把消息發送到隊列，而後訂閱的該隊列的消費者會收到消息。

若是一個隊列沒有被任何服務訂閱，那麼消息會一直在隊列中直到隊列被訂閱。

若是一個隊列被多個消費者訂閱了，那麼消息會經過輪詢的方式投遞給消費者，每一個消息只會投遞給一個消費者。這個功能就是實現負載均衡的理論基礎。

消息投遞到消費者以後，都須要消費者確認才能認爲投遞成功。這個確認包含自動確認和手動確認。自動確認就是說，一旦消費者收到消息就認爲投遞成功。手動確認，就是須要手動調用確認消息的API。

 

（隊列）

 

 

交換(exchanges)與綁定(bindings)

提到隊列的時候，上面的描述都好像是生產者直接把消息放到隊列，而後消費者從隊列拿消息。實際上不是的，他們不直接跟隊列打交道，只是知道隊列的存在。負責發佈和投遞消息的是一箇中間組件，叫作交換。相似於路由器功能，負責將接收消息和轉發消息。

那麼具體按照什麼規則轉發消息？這裏的規則叫作路由key。

這個路由key其實是一種綁定信息，在使用隊列的時候，並非建立個隊列就能夠了，同時還會建立一個交換器，而後將隊列綁定到交換器中。那麼在綁定隊列的時候，是須要提供一個路由key（能夠是一個空白內容）。交換器在發佈或者投遞信息的時候，就會查找對應的綁定信息，而後根據匹配的路由key，找到對應的隊列以及隊列的訂閱者，從而實現消息發佈或者投遞。

 

RabbitMQ提供了四種類型的交換器

direct

按照路由key去匹配消息隊列

（引自RabbitMQ in Action)

 

fanout

發送到交換器的消息，都會發送到綁定的全部隊列，相似於廣播消息

（引自RabbitMQ in Action)

 

topic

相似於路由key，可是會提供模糊匹配功能，支持使用一些通配符

（引自RabbitMQ in Action)

 

headers

使用消息的header去匹配隊列

 

 

虛擬主機(vhost virtual hosts)

能夠理解爲RabbitMQ種一個用於隔離不一樣應用程序的工具，每一個vhost有獨立的queue,exchange和binding以及權限配置信息。經過vhost可讓不一樣的應用程序在一個相對安全的環境運行，至少不會致使數據的誤刪，在邏輯上將數據隔離開，同時也避免了命名衝突。

vhost是默認存在的，默認的vhost是/，不建立的話用的就是這個。vhost做爲運行環境的一個很重要的基礎部分，咱們在使用API時都必須知道要用哪一個vhost，而且指明須要鏈接的vhost，有了vhost纔能有queue,exchange和binding。

 

 

先整理到這，後續整理一些實際操做的內容。

 

（待續）