（一）RocketＭＱ初步認識

rocketMQ是一個消息中間件。其產生的動機在github官方文檔有以下闡述：

在早期階段，咱們在ActiveMQ 5.x（小於5.3）的基礎上構建了分佈式消息傳遞中間件。咱們的國際業務使用它來進行異步通訊，搜索，社交網絡活動流，數據管道，甚至在咱們的交易訂單流程中。隨着咱們的貿易業務吞吐量愈來愈難以想象，來自咱們的消息傳送羣集的壓力也變得愈來愈明顯。

基於咱們的觀察和研究，隨着愈來愈多的隊列和虛擬主題的使用，ActiveMQ IO模塊成爲瓶頸。在某些狀況下，較慢的消費者可能會減慢生產者。咱們盡最大努力經過節流，斷路器或降級來處理這個問題，但它不能優雅地擴展。因此咱們開始專一於當時流行的消息傳遞解決方案Kafka。不幸的是，Kafka不能知足咱們的要求，如低延遲和高可靠性，詳見這裏。

在這種狀況下，咱們決定創新一個新的消息中間件，以處理一系列普遍的用例，從傳統的發佈/訂閱場景到苛刻的大容量實時事務系統，不允許消息丟失。咱們還建立了一個基於RocketMQ的基礎產品，這是一個名爲阿里雲平臺的平臺即服務（PaaS）產品。今天，超過100家公司在他們的業務解決方案中使用RocketMQ開源版本。咱們相信RocketMQ可讓更多的人受益，因此咱們想在世界各地分享。

闡述中提到的kafka,ActiveMQ以及咱們將要研究的RocketMQ都是消息中間件，何是消息中間件？

##消息中間件

• 理解：

  • 消息中間件利用高效可靠的消息傳遞機制進行平臺無關的數據交流，分佈式系統中重要的組件，主要解決應用耦合，異步消息，流量削鋒等問題。實現高性能，高可用，可伸縮和最終一致性架構。是大型分佈式系統不可缺乏的中間件。

  • 傳統消息系統數據有較大丟失風險，消息中間件最大的做用是解耦系統之間的依賴及異步化各系統間的調用。且做爲系統間消息存儲和轉發環節，具備高可靠性。

• 特色：

  • 異步處理：發/接雙方不需同時在線，消息能夠分發，能夠堆疊。
  • 解耦合：防止引入過多的API給系統的穩定性帶來風險；調用方使用不當會給被調用方系統形成壓力，被調用方處理不當會下降調用方系統的響應能力。

理解完消息中間件，咱們來看一下RocketMQ的特色：

##Rocket MQ 特色：

官方解釋：

產品基於高可用分佈式集羣技術，提供消息發佈訂閱、消息軌跡查詢、定時（延時）消息、資源統計、監控報警等一系列消息雲服務，是企業級互聯網架構的核心產品

這裏提到集羣和分佈式，再理解下：

##分佈式和集羣

• 概念：

  • 分佈式：一個業務分拆多個子業務，部署在不一樣的服務器上。
  • 集羣：同一個業務，部署在多個服務器上，將幾臺服務器集中在一塊兒，實現同一業務

• 區別

  分佈式的每個節點，都完成不一樣的業務，一個節點垮了，這個節點的業務就不可訪問了。而集羣，有一個組織性，一臺服務器垮了，其它的服務器能夠頂上來。 因此說，分佈式中的每個節點，均可以作集羣。而集羣並不必定就是分佈式的

舉例：如新浪網，訪問的人多了，他能夠作一個集羣，前面放一個響應服務器，後面幾臺服務器完成同一業務，若是有業務訪問的時候，響應服務器看哪臺服務器的負載不是很重，就將給哪一臺去完成。

到這裏，對於RocketMQ是個什麼東西有一個模糊的理解，在具體實踐前咱們須要瞭解一些概念（我僅介紹單機搭建時會涉及的知識點）

##Rocket MQ架構及術語理解

圖A中有四個角色，也是Rocket MQ中的重要概念。概念以下：

• Producer
  • 消息生產者，負責產生消息，通常由業務系統負責產生消息。

• Consumer
  • 消息消費者，負責消費消息，通常是後臺系統負責異步消費。
• NameServer
  • 無狀態節點，用來保存活躍的 broker 列表，和topic列表。
• Broker
  • 消息中轉角色，負責存儲消息，轉發消息。

producer和consumer很好理解一個發送消息，一個接受消息。nameserver和broker是重點要說的，它們是服務器層，構成了集羣的邏輯。這裏先解釋一個概念。

無狀態節點 無狀態和狀態的區別，即爲服務器應答過程當中是否基於上次請求所構築的上下文環境，我的理解：無狀態就是發送過來的請求結果都同樣，和上一次沒啥因果關係。有狀態就是我這一次發的請求和上一次有必定關係，服務器得保留每次的請求，以便對下一次請求產生影響

nameserver是無狀態節點，因此能夠擴展成集羣。

• topic
  • 消息的邏輯管理單位。

實際生產模式下（關閉了broker的自動建立、訂閱topic的功能）

• broker控制topic的增刪，發送未知topic的producer會報錯（autoCreateTopicEnable=false）
• broker控制topic的訂閱，未指定的訂閱組，consumer沒法拉取消費該topic的信息（autoCreateSubscriptionGroup=false ）

##工做流程

1. 首先須要搭建一個NameServer節點，就像一個信號塔，producer，consumer以及broker之間的聯繫都須要經過訪問NameServer，獲取到各自須要的路由信息後才能進行聯繫。
2. NameServer節點搭建成功後，啓動Broker。啓動前能夠修改Broker的默認配置文件，包括前文說到的topic相關的參數等，修改完成後，啓動Broker，配置即生效。
3. 啓動完NameServer和Broker後，能夠在控制檯裏進行topic的增長和訂閱（具體控制檯的操做後文再說）。而後producer就能夠發送已有的topic類型的消息，另外一邊consumer（訂閱組）被broker准許後，每當consumer訂閱的topic下接收到消息（消息從producer發送到broker中），consumer即可以成功拉取到此消息（消息從broker到consumer）並進行消費。

該段簡要的描述了RocketMQ工做的流程，更多更復雜的概念我們後文再涉及...

下一篇：Rocket MQ單機環境搭建