結合以前看的一些東西，閱讀RockMQ實戰與原理解析筆記

Topic有多個message queue，消息能夠並行的向各個message queue發送，消費者也能夠並行的從多個message queue讀取消息並消費

clustering模式消費一個topic裏的消息內容是哦，能夠啓動多個消費者並行消費，每一個消費者只消費Topic裏消息的一部分，以此提升消費速度，這個時候就是經過訂閱組來指明哪些消費者是同一組，同一組的消費者共同消費同一個Topic裏的內容

DefaultMQPushConsumer由系統控制讀取操做，收到消息後自動調用傳入的處理方法來處理；

DefaultMQPullConsumer讀取操做中的大部分功能由使用者自主控制

RocketMQ支持兩種消息模式，clustering和broadcasting

集羣模式下，同一個consumergroup裏的每一個consumer只消費所訂閱消息的一部份內容，同一個consumergroup裏的全部的comsumer消費的內容合起來纔是所訂閱topic內容的總體，從而達到負載均衡的目的

廣播模式下，同一個consumergroup裏的每一個consumer都能消費到所訂閱topic的所有消息，也就是一個消息會被屢次分發，被多個consumer消費

能夠指定消費某個Topic下的多個標記了某tag的消息，也能夠消費所有

Push方式是服務端接收到消息後，主動把消息推送給客戶端，實時性高，但弊端是加大了服務端工做量，並且沒法顧及到客戶端處理能力的不一樣，形成潛在問題

Pull的方式是客戶端循環從服務端拉取消息，主動權在客戶端手裏，本身拉取到必定的消息後，處理穩當了再接着取，問題是如何設置獲取間隔，過短容易浪費忙等，太長可能處理不及時

DefaultMQPushConsuer的源碼中有不少PullRequest語句，好比Default-MQPushConsumerImpl.this.executePullRequestImmediately（pullRequest）。爲何「PushConsumer」中使用「PullRequest」呢？這是經過「長輪詢」方式達到Push效果的方法，長輪詢方式既有Pull的優勢，又兼具Push方式的實時性。

服務端接受到請求後，隊列裏沒有新消息，並不急於返回，經過一個循環不斷查看狀態，每次waitForRunning一段時間，而後再check，默認狀況下，當broker一直沒有新的消息，第三次check的時候，等待時間超過request裏的brokerSuspendMaxTimeMillis,就返回空結果。在等待過程當中，若是broker收到了新的消息後悔直接調用notifyMessageArriving函數返回請求結果，長輪詢的核心就是，Broker端hold住客戶端過來的請求一小段時間，在這個時間內有新的消息到達，就利用現有的鏈接當即返回給consumer，長輪詢的主動權仍是掌握在consumer手中，broker即便有大量消息積壓也不會主動推送給consumer，缺點就是在Hold過程當中須要佔用資源，適合在消息隊列這種客戶端鏈接數可控的場景