獲取上雲幫助文檔：http://rocketmq.cloud/zh-cn/blog/tocloud-catalog.html

本期文章為Apache RocketMQ原理系列文章第一篇，主要介紹RocketMQ服務端的三種組件：NameServer，Broker，FilterServer（可選，部署於和Broker同一台機器）

服務端組件架構示例圖

Name Server

Name Server是RocketMQ的定址服務。用於把Broker的路由資訊做聚合。客戶端依靠Name Server決定去獲取對應topic的路由資訊，從而決定對哪些Broker做連接。

Broker

Broker是處理消息存儲，轉發等處理的伺服器。

Broker以group分開，每個group只允許一個master，若干個slave。
只有master才能進行寫入操作，slave不允許。
slave從master中同步數據。同步策略取決於master的配置，可以採用同步雙寫，非同步複製兩種。
客戶端消費可以從master和slave消費。在默認情況下，消費者都從master消費，在master掛後，客戶端由於從Name Server中感知到Broker掛機，就會從slave消費。
Broker向所有的NameServer結點建立長連接，註冊Topic資訊。

Filter Server（可選）

RocketMQ可以允許消費者上傳一個Java類給Filter Server進行過濾。

Filter Server只能起在Broker所在的機器
可以有若干個Filter Server進程
拉取消息的時候，消息先經過Filter Server，Filter Server靠上傳的Java類過濾消息後才推給Consumer消費。
客戶端完全可以消費消息的時候做過濾，不需要Filter Server
FilterServer存在的目的是用Broker的CPU資源換取網卡資源。因為Broker的瓶頸往往在網卡，而且CPU資源很閑。在客戶端過濾會導致無需使用的消息在佔用網卡資源。
使用 Java 類上傳作為過濾表達式是一個雙刃劍，一方面方便了應用的過濾操作且節省網卡資源，另一方面也帶來了伺服器端的安全風險，這需要足夠謹慎，消費端上傳的class要保證過濾的程式碼足夠安全——例如在過濾程式里儘可能不做申請大記憶體，創建執行緒等操作，避免 Broker 伺服器資源泄漏。

本期關於RocketMQ服務端組件的介紹就到這裡，接下來三期我們將分別介紹RocketMQ的核心概念及術語、水平擴展和負載均衡、消息ACK機制及消費進度管理相關的內容，敬請期待～

作者介紹：

Jaskey Lam， Apache RocketMQ committer，知乎專欄RocketMQ詳解作者，曾工作於Oracle，網易，微眾銀行，現任OPPO消費金融業務高級軟體工程師；具備用戶思維的程式設計師，王者榮耀單排王者選手