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.lognohup 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;一個息接收者可以接受一個或者多個topicmessage 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會略高,且目前版本在主節點宕機後,備機不能自動切換為主機。