nohup sh bin/mqbroker -n localhost:9876 &
啟動BrokerStartup類
main函數裡面比較簡單，建立了一個BrokerController，然後調用start方法，那我們先看下createBrokerController構造一個Controller
這個方法有點複雜，可以一步步講。
首先會初始化NettyServerConfig和NettyClientConfig，因為Broker在運作的時候既是Netty用戶端，又是Netty服務端。也就是既要響應别人的請求，同時又會請求其他服務，比如Namesrv。
然後把監聽端口設定成10911(broker啟動後用ps 和netstat 看一下就可以看到Broker運作的程序與監聽端口，如下圖)
lsof -iTCP -sTCP:LISTEN -nP (mac環境)
ps -ef | grep broker
判斷是否有-c參數，如果有-c參數，後面一般帶的是Broker啟動腳本檔案，那麼就可以解析Broker啟動配置檔案
如果單機玩demo的話，可以用-n參數，也就是直接指定Namesrv，也就是用如下啟動腳本
這個方法有點複雜，new大家可以自己看，就是new出一系列的相關對象，直接看controller.initialize()方法。
BrokerController.java
initialize方法首先會去load各種之前的參數，我們可以挨個看一下每個load分别對應哪個檔案。
topicConfigManager.load()
首先它會得到config檔案路徑，一般預設是在根目錄/store/config，比如我的是
/Users/huangrongwei/store/config
可以進去看一下，如下圖：
每個種類有兩個檔案，一個正常的，一個備份的；那我們加載的順序就是先加載正常的，如果不存在或者出錯，那麼就嘗試加載備份的檔案。
加載的時候執行decode()方法
decode方法
很明顯，decode是抽象方法，它的實作類如下：
很明顯，它對應了上面2.3.2.6步幾個load方法，這種應該是模版設計模式吧(父類定義了執行流程，子類實作細節)。
那我們先看topicConfigManager.decode，它對應的檔案是topics.json
其實就是解析裡面的内容，把topic的配置資訊放到topicConfigTable裡面，然後記錄一下資料版本(如果topic資料有變化，版本會遞增，Namesrv會根據版本号來決定要不要更新它的資料。)
那一個topic一般有什麼配置呢？可以看下topics.json，如下圖：
大概解釋下裡面的參數queueNumber表示隊列數，一個topic可以有多個隊列，每個消費者可能從不同的隊列去拿消息，當然生産者的消息也可能丢到一個topic的不同隊列中。
其他參數大家可以去細看。
其他幾個decode原理類似，大家可以自己看下代碼。
為什麼叫做vip通道呢？因為rocketmq監聽的這個端口的消息少一點，特别是存儲消息到磁盤的那塊邏輯，vip通道是不會做的。是以個人覺得這個通道響應速度會快點。
這一點從下面的registerProcessor()方法可以看的出來。
vip通道少了RequestCode.PULL_MESSAGE這個事件，是以可以冒昧的猜測，RequestCode.PULL_MESSAGE有可能是一個耗時的操作。
另外，有些broker可能沒有開這個vip通道，那麼就需要在生産者或者消費者手動關閉這個通道。
這裡包括
每天淩晨記錄一次昨天收發了多少消息
定時持久化消費進度
持久化comsumer fileter，這些都是開始load的那些文檔關聯的。
定時清理消費太慢的消費者，以保護Broker
列印發送消費線程運作狀态
列印分發消息比接收消息延遲多少。
定時擷取Namesrv位址
如果目前broker是slave，那麼定時從master同步消息；如果是master，那麼定時列印slave和master差别。
到這裡，createBrokerController方法就分析完了。 總之，經過這個方法之後：
和其他服務的通信管道建立了。
之前存儲的資料恢複了(topic, 消費進度，存儲的消息)。
啟動了各種定時器，用來維護Broker的正常工作。
如果是slave，那麼就定時從master同步資料
總之，所有的都準備好了。
BrokerController建立完了之後，start就比較簡單了，把建立的各種服務start起來。同時向所有的Namesrv注冊自己。
還要啟動定時器，定時向所有的Namesrv注冊自己，告訴Namesrv自己還活着，這樣消息生産者和消費者就可以通過Namesrv找到自己。
至此，Broker啟動流程分析結束。
本文轉自rongwei84n 51CTO部落格，原文連結：http://blog.51cto.com/483181/2043964，如需轉載請自行聯系原作者