MQ介紹
為什麼要使用mq（優點）
- 應用解耦
將同步調用修改為通過mq發佈訂閱消息，當增加或減少消費者時，生產者不需要做任改動。減少系統響應時間，如果全部為同步，所有流程走完時各個系統之和，但是修改異步後，即使某個系統出現故障，也能在故障修復後重新消費消息，達到最終一致性的。 - 流量削峰
當qps超過我們數據庫的極限時，使用mq在中間作為緩衝，處理消息的速度是由消費者來決定的，雖然qps很大，但是處理請求的速度依然是按部就班，可以避免數據庫被壓垮。 - 數據分發
將同步調用修改為異步調用，增加或減少消費者不會影響生產者，生產者只需要保證生產消息到mq。
mq的缺點
- 系統可用性降低，引入外部依賴越多，系統穩定性越差，一旦mq宕機，業務會癱瘓
- 系統複雜度提高，異步調用問題，重複消費問題，消息丟失問題，消息的順序性問題。
- 一致性問題，一個子系統處理失敗，如何保證消息處理的一致性。
各種mq比較
activemq（java）、rabbitmq（erlang）、rocketmq（java）、kafka（scala）
kafka、rocketmq單機吞吐量高，10w級
rabbitmq時效性較高us級，erlang性能高
activemq、rabbitmq可以主從架構，較高可用性；rocketmq和kafka可以分佈式架構，非常高可用性
rocketmq作為消息隊列比較火，kafka在大數據領域比較火
快速入門
啟動nameServer和broker，啟動生產者消費者demo來測試
- nohup sh bin/mqnamesrv &
- tailf ~/logs/rocketmqlogs/namesrv.log
- nohup sh bin/mqbroker -n localhost:9876 &
- tailf ~/logs/rocketmqlogs/broker.log
通過runbroker.sh和runserver.sh可以調整rocketmq的虛擬機內存
rocketmq集群搭建
rocketmq角色介紹
- producer：消息的發送者，發信者
- consumer：消息的接受者，收信者
- broker：暫存和傳輸消息，郵局
- nameserver：管理broker，管理郵局的機構
- topic：區分消息的種類，一個發送者可以發送消息給一個或者多個topic；一個息接收者可以接受一個或者多個topic
- message queue：相當於topic的分區，用於並行發送和接受消息
集群搭建方式
集群特點
- nameserver是無狀態的，數據是一樣的，沒有差異，nameserver集群搭建比較方便，直接啟動多個nameserver就可以了，節點之前無任何信息同步，
- producer就是我們的應用，也是沒有狀態的，直接啟動多個實例，producer與nameserver集群中的一個節點（隨機選擇）建立長連接，定期從nameserver中獲取topic路由信息，並向提供topic服務的master建立長連接，且定時向master發送心跳。
- consumer與nameserver集群中的其中一個節點（隨機選擇）建立長連接，定期從nameserver取topic路由信息，並向提供topic服務的master和slave建立長連接，且定時向master和slave發送心跳（因為broker可以推送消息，consumer也可以主動去拉消息，需要互相知道是否存活）。consumer既可以從master訂閱消息，也可以從slave訂閱消息，訂閱規則由broker配置決定。
- broker每組都有分主從節點，主寫從讀（可配置），一個master可以對應多個slave，但是一個slave只能對應一個master。master和slave的對應關係通過指定相同的broderName，不同的BrokerID來定義，broker為0代表主節點，非0代表從節點。master可以部署多個，每個broker和nameserver集群中的所有節點建立長連接，定時註冊topic信息到所有nameserver。master和slave會進行數據複製，可以是同步的也可以是異步的。
集群模式
- 單master模式(單機模式)
這種方式風險較大，一旦broker重啟或者宕機，會導致整個服務不可用。 - 多master模式
一個集群無slave，全是master，例如兩個或3個master，這種模式優缺點如下：
優點： 配置簡單，單個master宕機或重啟對應用無影響，在磁盤配置為raid10時，即使機器宕機不可恢復的情況下，由於raid10非常可靠，消息也不會丟失（異步刷盤丟失少量消息，同步刷盤一條不丟），性能最高。
缺點： 單臺機器宕機時，這臺機器上未被消費的消息在機器恢復之前不可訂閱，消息實時性會受到影響。 - 多master多slave模式（異步）
每個master配置一個slave，有多個master-slave組合，ha（高可用）採用異步複製方式，主備有短暫的消息延遲（毫秒級），這種模式的優缺點如下：
優點： 即使磁盤損壞，消息丟失的非常少，且消息的實時性不會收到影響，同時master宕機後，消費者仍然可以從slave讀取，並且過程對應用透明，不需要人工干預，性能同多master模式幾乎一樣。
缺點： master宕機，磁盤損壞的情況下，會丟失少量消息。 - 多master多slave模式（同步）
每個master配置一個slave，有多對master-slave，ha採用同步雙寫方式，等主備都寫成功，再返回給應用結果。這種模式的優缺點如下：
優點： 數據與服務都無單點故障，master宕機的情況下，消息無延遲，服務可用性和數據可用性都非常高。
缺點： 性能比同步方式略低（大約10%），發送單個消息的rt會略高，且目前版本在主節點宕機後，備機不能自動切換為主機。
雙主雙從集群搭建
架構圖（同步雙寫）
工作流程
- 啟動nameserver，nameserver啟動監聽，等待broker、producer、consumer接，相當於一個路由控制中心
- broker啟動，跟所有的nameserver建立長連接，定時發送心跳，心跳包中包括當broker的信息（ip、端口號、存儲的所有topic信息），註冊成功後，nameserver集群就有了broker和topic的映射關係。
- 收發消息前，先創建topic，創建時要指定該topic要存儲到哪些broker上，也可以在送消息時自動創建topic（不安全）
- producer啟動，和nameserver建立長連接，發送消息時先從nameserver中獲取當發送的topic存在在哪些broker上，輪詢從隊列列表中選擇一個隊列，然後與隊列所在broker建立長連接從而發送消息。
- consumer跟producer相似，跟其中一臺nameserver建立長連接，獲取當前訂閱topi存在在哪些broker上，然後直接和broker建立長連接，開始消費消息。
分享到:
閱讀更多 evilRat 的文章
