關于MQ的幾件小事（一）消息隊列的用途、優缺點、技術選型

xialong 發布于2019-05-23 16:25 / 3559人閱讀

摘要：數量對吞吐量的影響可以達到幾百幾千個的級別，吞吐量會有小幅度的下降。這是的一大優勢，可在同等數量機器下支撐大量的從幾十個到幾百個的時候，吞吐量會大幅下降。下一篇如何保證消息隊列的高可用

1.為什么使用消息隊列？

（1）解耦：可以在多個系統之間進行解耦，將原本通過網絡之間的調用的方式改為使用MQ進行消息的異步通訊，只要該操作不是需要同步的，就可以改為使用MQ進行不同系統之間的聯系，這樣項目之間不會存在耦合，系統之間不會產生太大的影響，就算一個系統掛了，也只是消息擠壓在MQ里面沒人進行消費而已，不會對其他的系統產生影響。

（2）異步：加入一個操作設計到好幾個步驟，這些步驟之間不需要同步完成，比如客戶去創建了一個訂單，還要去客戶軌跡系統添加一條軌跡、去庫存系統更新庫存、去客戶系統修改客戶的狀態等等。這樣如果這個系統都直接進行調用，那么將會產生大量的時間，這樣對于客戶是無法接收的；并且像添加客戶軌跡這種操作是不需要去同步操作的，如果使用MQ將客戶創建訂單時，將后面的軌跡、庫存、狀態等信息的更新全都放到MQ里面然后去異步操作，這樣就可加快系統的訪問速度，提供更好的客戶體驗。

（3）削峰：一個系統訪問流量有高峰時期，也有低峰時期，比如說，中午整點有一個搶購活動等等。比如系統平時流量并不高，一秒鐘只有100多個并發請求，系統處理沒有任何壓力，一切風平浪靜，到了某個搶購活動時間，系統并發訪問了劇增，比如達到了每秒5000個并發請求，而我們的系統每秒只能處理2000個請求，那么由于流量太大，我們的系統、數據庫可能就會崩潰。這時如果使用MQ進行流量削峰，將用戶的大量消息直接放到MQ里面，然后我們的系統去按自己的最大消費能力去消費這些消息，就可以保證系統的穩定，只是可能要跟進業務邏輯，給用戶返回特定頁面或者稍后通過其他方式通知其結果。

2.消息隊列有什么優點和缺點？

優點：1、對結構復雜、設計系統多的操作進行解耦操作，降低系統的操作復雜度、降低系統的維護成本。 ???2、對一個可以進行異步操作的一些系統操作進行異步，減小操作的響應時間，提供更好的用戶體驗。 ???3、可對高流量進行削峰，保證系統的平穩運行。缺點：1、系統可用性降低。比如在系統中引入MQ，那么萬一MQ掛了怎么辦呢？一般而言，引入的外部依賴越多，系統越
????脆弱，每一個依賴出問題都會導致整個系統的崩潰。 ???2、系統復雜度提高。需要考慮MQ的各種情況，比如：消息的重復消費、消息丟失、保證消費順序等等...... ???3、數據一致性問題。比如A系統已經給客戶返回操作成功，這時候操作BC都成功了，操作D卻失敗了，導致數據不
????一致。

3.kafka、activemq、rabbitmq、rocketmq都有什么優點和缺點啊？

特性	ActiveMQ	RabbitMQ	RocketMQ	kafka
單機吞吐量	萬級，吞吐量比RocketMQ和kafka要低一個數量級	萬級，吞吐量比RocketMQ和kafka要低一個數量級	10萬級，RocketMQ也是可以支撐高吞吐的一種MQ	10萬級別，kafka最大優點就是吞吐量大，一般配合大數據類的系統來進行實時數據計算、日志采集等場景。
topic數量對吞吐量的影響			topic可以達到幾百、幾千個的級別，吞吐量會有小幅度的下降。這是RocketMQ的一大優勢，可在同等數量機器下支撐大量的topic	topic從幾十個到幾百個的時候，吞吐量會大幅下降。所以在同等機器數量下，kafka盡量保證topic數量不要過多。如果支撐大規模topic需要增加更多的機器
時效性	ms級	微秒級，這是rabbitmq的一大特點，延遲是最低的	ms級	延遲在ms級以內
可用性	高，基于主從架構實現可用性	高，基于主從架構實現可用性	非常高，分布式架構	非常高，kafka是分布式的，一個數據多個副本，少數機器宕機，不會丟失數據，不會導致不可用
消息可靠性	有較低的概率丟失數據		經過參數優化配置，可以做到0丟失	經過參數配置，消息可以做到零丟失
功能支持	MQ領域的功能及其完備	基于erlang開發，所以并發性能極強，性能極好，延時低	MQ功能較為完備，分布式擴展性好	功能較為簡單，主要支持加單MQ功能
優勢	非常成熟，功能強大，在業內大量公司和項目中都有應用	erlang語言開發，性能極好、延時很低，吞吐量萬級、MQ功能完備，管理界面非常好，社區活躍；互聯網公司使用較多	接口簡單易用，阿里出品有保障，吞吐量大，分布式擴展方便、社區比較活躍，支持大規模的topic、支持復雜的業務場景，可以基于源碼進行定制開發	超高吞吐量，ms級的時延，極高的可用性和可靠性，分布式擴展方便
劣勢	偶爾有較低概率丟失消息，社區活躍度不高	吞吐量較低，erlang語音開發不容易進行定制開發，集群動態擴展麻煩	接口不是按照標準JMS規范走的，有的系統遷移要修改大量的代碼，技術有被拋棄的風險	有可能進行消息的重復消費
應用	主要用于解耦和異步，較少用在大規模吞吐的場景中	都有使用	用于大規模吞吐、復雜業務中	在大數據的實時計算和日志采集中被大規模使用，是業界的標準

綜上所述，總結如下：一般業務系統要引入MQ，最早大家都用ActiveMQ，但現在用的不多了。沒有經過大規模吞吐場景的驗證，社區也不活躍，不推薦再使用。后來大家開始用rabbitMQ，但是它是使用erlang語言開發的，如果不精通erlang，對公司而言，幾乎處于不可控的狀態，單其是開源的，社區活躍度高，擁有比較穩定的支持。現在越來越多的公司開始使用RocketMQ，但是要小心被拋棄的風險。如果公司有實力自己去維護開發，推薦使用。否則還是選擇RabbitMQ。如果實在大數據的實時計算、日志采集等領域，用kafka是業界標準。

所以，對于中小型公司，技術實力一般的，應該用rabbitmq，對于大公司，基礎架構研發能力強大的，推薦使用RocketMQ。

下一篇《如何保證消息隊列的高可用》

GPU云服務器云服務器 mq消息隊列的作用 MQ 消息隊列 mq消息隊列消息隊列mq

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/7221.html

關于MQ的幾件小事（七）如果讓你設計一個MQ，你怎么設計

摘要：能不能支持數據丟失啊可以的，參考我們之前說的那個數據零丟失方案其實一個肯定是很復雜的，其實這是個開放題，就是看看你有沒有從架構角度整體構思和設計的思維以及能力。其實回答這類問題，說白了，起碼不求你看過那技術的源碼，起碼你大概知道那個技術的基本原理，核心組成部分，基本架構構成，然后參照一些開源的技術把一個系統設計出來的思路說一下就好比如說這個消息隊列系統，我們來從以下幾個角度來考慮一下（1...

Vixb 2019-05-23 17:29 評論0 收藏0
關于MQ的幾件小事（六）消息積壓在消息隊列里怎么辦

摘要：緊接著征用倍的機器來部署，每一批消費一個臨時的消息。這種做法相當于臨時將資源和資源擴大倍，以正常速度的倍來消費消息。解決方案這種情況下，實際上沒有什么消息擠壓，而是丟了大量的消息。 1.大量消息在mq里積壓了幾個小時了還沒解決場景：幾千萬條數據在MQ里積壓了七八個小時，從下午4點多，積壓到了晚上很晚，10點多，11點多。線上故障了，這個時候要不然就是修復consumer的問題，讓他恢復消...

SwordFly 2019-05-23 17:32 評論0 收藏0
關于MQ的幾件小事（五）如何保證消息按順序執行

摘要：一個對應一個，但是里面進行了多線程消費，這樣也會造成消息消費順序錯誤。保證消息的消費順序拆分多個，每個一個，就是多一些而已，確實是麻煩點這樣也會造成吞吐量下降，可以在消費者內部采用多線程的方式取消費。 1.為什么要保證順序消息隊列中的若干消息如果是對同一個數據進行操作，這些操作具有前后的關系，必須要按前后的順序執行，否則就會造成數據異常。舉例：比如通過mysql binlog進行兩個數據...

h9911 2019-05-23 16:28 評論0 收藏0
關于MQ的幾件小事（四）如何保證消息不丟失

摘要：消費端弄丟了數據關閉自動提交，在自己處理完畢之后手動提交，這樣就不會丟失數據。弄丟了數據一般要求設置個參數來保證消息不丟失給設置參數這個值必須大于，表示要求每個必須至少有個副本。上一篇如何保證消息不重復消費下一篇如何保證消息按順序執行 1.mq原則數據不能多，也不能少，不能多是說消息不能重復消費，這個我們上一節已解決；不能少，就是說不能丟失數據。如果mq傳遞的是非常核心的消息，支撐核心的業...

stackvoid 2019-05-23 16:26 評論0 收藏0
關于redis的幾件小事(三)redis的數據類型與使用場景

摘要：這個是類似的一種結構，這個一般就是可以將結構化的數據，比如一個對象前提是這個對象沒嵌套其他的對象給緩存在里，然后每次讀寫緩存的時候，可以就操作里的某個字段。 1.string 這是最基本的類型了，就是普通的set和get，做簡單的kv緩存。 2.hash 這個是類似map的一種結構，這個一般就是可以將結構化的數據，比如一個對象（前提是這個對象沒嵌套其他的對象）給緩存在redis里，然后每次...

zhaochunqi 2019-05-23 16:24 評論0 收藏0