資訊專欄INFORMATION COLUMN
摘要：數(shù)量對吞吐量的影響可以達(dá)到幾百幾千個的級別，吞吐量會有小幅度的下降。這是的一大優(yōu)勢，可在同等數(shù)量機(jī)器下支撐大量的從幾十個到幾百個的時候，吞吐量會大幅下降。下一篇如何保證消息隊列的高可用
1.為什么使用消息隊列？（1）解耦：可以在多個系統(tǒng)之間進(jìn)行解耦，將原本通過網(wǎng)絡(luò)之間的調(diào)用的方式改為使用MQ進(jìn)行消息的異步通訊，只要該操作不是需要同步的，就可以改為使用MQ進(jìn)行不同系統(tǒng)之間的聯(lián)系，這樣項目之間不會存在耦合，系統(tǒng)之間不會產(chǎn)生太大的影響，就算一個系統(tǒng)掛了，也只是消息擠壓在MQ里面沒人進(jìn)行消費而已，不會對其他的系統(tǒng)產(chǎn)生影響。
（2）異步：加入一個操作設(shè)計到好幾個步驟，這些步驟之間不需要同步完成，比如客戶去創(chuàng)建了一個訂單，還要去客戶軌跡系統(tǒng)添加一條軌跡、去庫存系統(tǒng)更新庫存、去客戶系統(tǒng)修改客戶的狀態(tài)等等。這樣如果這個系統(tǒng)都直接進(jìn)行調(diào)用，那么將會產(chǎn)生大量的時間，這樣對于客戶是無法接收的；并且像添加客戶軌跡這種操作是不需要去同步操作的，如果使用MQ將客戶創(chuàng)建訂單時，將后面的軌跡、庫存、狀態(tài)等信息的更新全都放到MQ里面然后去異步操作，這樣就可加快系統(tǒng)的訪問速度，提供更好的客戶體驗。
（3）削峰：一個系統(tǒng)訪問流量有高峰時期，也有低峰時期，比如說，中午整點有一個搶購活動等等。比如系統(tǒng)平時流量并不高，一秒鐘只有100多個并發(fā)請求，系統(tǒng)處理沒有任何壓力，一切風(fēng)平浪靜，到了某個搶購活動時間，系統(tǒng)并發(fā)訪問了劇增，比如達(dá)到了每秒5000個并發(fā)請求，而我們的系統(tǒng)每秒只能處理2000個請求，那么由于流量太大，我們的系統(tǒng)、數(shù)據(jù)庫可能就會崩潰。這時如果使用MQ進(jìn)行流量削峰，將用戶的大量消息直接放到MQ里面，然后我們的系統(tǒng)去按自己的最大消費能力去消費這些消息，就可以保證系統(tǒng)的穩(wěn)定，只是可能要跟進(jìn)業(yè)務(wù)邏輯，給用戶返回特定頁面或者稍后通過其他方式通知其結(jié)果。
2.消息隊列有什么優(yōu)點和缺點？
優(yōu)點：1、對結(jié)構(gòu)復(fù)雜、設(shè)計系統(tǒng)多的操作進(jìn)行解耦操作，降低系統(tǒng)的操作復(fù)雜度、降低系統(tǒng)的維護(hù)成本。
???2、對一個可以進(jìn)行異步操作的一些系統(tǒng)操作進(jìn)行異步，減小操作的響應(yīng)時間，提供更好的用戶體驗。
???3、可對高流量進(jìn)行削峰，保證系統(tǒng)的平穩(wěn)運行。
缺點：1、系統(tǒng)可用性降低。比如在系統(tǒng)中引入MQ，那么萬一MQ掛了怎么辦呢？一般而言，引入的外部依賴越多，系統(tǒng)越
????脆弱，每一個依賴出問題都會導(dǎo)致整個系統(tǒng)的崩潰。
???2、系統(tǒng)復(fù)雜度提高。需要考慮MQ的各種情況，比如：消息的重復(fù)消費、消息丟失、保證消費順序等等......
???3、數(shù)據(jù)一致性問題。比如A系統(tǒng)已經(jīng)給客戶返回操作成功，這時候操作BC都成功了，操作D卻失敗了，導(dǎo)致數(shù)據(jù)不
????一致。
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | kafka |
|---|---|---|---|---|
| 單機(jī)吞吐量 | 萬級，吞吐量比RocketMQ和kafka要低一個數(shù)量級 | 萬級，吞吐量比RocketMQ和kafka要低一個數(shù)量級 | 10萬級，RocketMQ也是可以支撐高吞吐的一種MQ | 10萬級別，kafka最大優(yōu)點就是吞吐量大，一般配合大數(shù)據(jù)類的系統(tǒng)來進(jìn)行實時數(shù)據(jù)計算、日志采集等場景。 |
| topic數(shù)量對吞吐量的影響 | topic可以達(dá)到幾百、幾千個的級別，吞吐量會有小幅度的下降。這是RocketMQ的一大優(yōu)勢，可在同等數(shù)量機(jī)器下支撐大量的topic | topic從幾十個到幾百個的時候，吞吐量會大幅下降。所以在同等機(jī)器數(shù)量下，kafka盡量保證topic數(shù)量不要過多。如果支撐大規(guī)模topic需要增加更多的機(jī)器 | ||
| 時效性 | ms級 | 微秒級，這是rabbitmq的一大特點，延遲是最低的 | ms級 | 延遲在ms級以內(nèi) |
| 可用性 | 高，基于主從架構(gòu)實現(xiàn)可用性 | 高，基于主從架構(gòu)實現(xiàn)可用性 | 非常高，分布式架構(gòu) | 非常高，kafka是分布式的，一個數(shù)據(jù)多個副本，少數(shù)機(jī)器宕機(jī)，不會丟失數(shù)據(jù)，不會導(dǎo)致不可用 |
| 消息可靠性 | 有較低的概率丟失數(shù)據(jù) | 經(jīng)過參數(shù)優(yōu)化配置，可以做到0丟失 | 經(jīng)過參數(shù)配置，消息可以做到零丟失 | |
| 功能支持 | MQ領(lǐng)域的功能及其完備 | 基于erlang開發(fā)，所以并發(fā)性能極強(qiáng)，性能極好，延時低 | MQ功能較為完備，分布式擴(kuò)展性好 | 功能較為簡單，主要支持加單MQ功能 |
| 優(yōu)勢 | 非常成熟，功能強(qiáng)大，在業(yè)內(nèi)大量公司和項目中都有應(yīng)用 | erlang語言開發(fā)，性能極好、延時很低，吞吐量萬級、MQ功能完備，管理界面非常好，社區(qū)活躍；互聯(lián)網(wǎng)公司使用較多 | 接口簡單易用，阿里出品有保障，吞吐量大，分布式擴(kuò)展方便、社區(qū)比較活躍，支持大規(guī)模的topic、支持復(fù)雜的業(yè)務(wù)場景，可以基于源碼進(jìn)行定制開發(fā) | 超高吞吐量，ms級的時延，極高的可用性和可靠性，分布式擴(kuò)展方便 |
| 劣勢 | 偶爾有較低概率丟失消息，社區(qū)活躍度不高 | 吞吐量較低，erlang語音開發(fā)不容易進(jìn)行定制開發(fā)，集群動態(tài)擴(kuò)展麻煩 | 接口不是按照標(biāo)準(zhǔn)JMS規(guī)范走的，有的系統(tǒng)遷移要修改大量的代碼，技術(shù)有被拋棄的風(fēng)險 | 有可能進(jìn)行消息的重復(fù)消費 |
| 應(yīng)用 | 主要用于解耦和異步，較少用在大規(guī)模吞吐的場景中 | 都有使用 | 用于大規(guī)模吞吐、復(fù)雜業(yè)務(wù)中 | 在大數(shù)據(jù)的實時計算和日志采集中被大規(guī)模使用，是業(yè)界的標(biāo)準(zhǔn) |
綜上所述，總結(jié)如下： 一般業(yè)務(wù)系統(tǒng)要引入MQ，最早大家都用ActiveMQ，但現(xiàn)在用的不多了。沒有經(jīng)過大規(guī)模吞吐場景的驗證，社區(qū)也不活躍，不推薦再使用。 后來大家開始用rabbitMQ，但是它是使用erlang語言開發(fā)的，如果不精通erlang，對公司而言，幾乎處于不可控的狀態(tài)，單其是開源的，社區(qū)活躍度高，擁有比較穩(wěn)定的支持。 現(xiàn)在越來越多的公司開始使用RocketMQ，但是要小心被拋棄的風(fēng)險。如果公司有實力自己去維護(hù)開發(fā)，推薦使用。否則還是選擇RabbitMQ。 如果實在大數(shù)據(jù)的實時計算、日志采集等領(lǐng)域，用kafka是業(yè)界標(biāo)準(zhǔn)。
所以，對于中小型公司，技術(shù)實力一般的，應(yīng)該用rabbitmq，對于大公司，基礎(chǔ)架構(gòu)研發(fā)能力強(qiáng)大的，推薦使用RocketMQ。
下一篇《如何保證消息隊列的高可用》
文章版權(quán)歸作者所有，未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址：http://systransis.cn/yun/7221.html
摘要：能不能支持?jǐn)?shù)據(jù)丟失啊可以的，參考我們之前說的那個數(shù)據(jù)零丟失方案其實一個肯定是很復(fù)雜的，其實這是個開放題，就是看看你有沒有從架構(gòu)角度整體構(gòu)思和設(shè)計的思維以及能力。其實回答這類問題，說白了，起碼不求你看過那技術(shù)的源碼，起碼你大概知道那個技術(shù)的基本原理，核心組成部分，基本架構(gòu)構(gòu)成，然后參照一些開源的技術(shù)把一個系統(tǒng)設(shè)計出來的思路說一下就好 比如說這個消息隊列系統(tǒng)，我們來從以下幾個角度來考慮一下 （1...
摘要：緊接著征用倍的機(jī)器來部署，每一批消費一個臨時的消息。這種做法相當(dāng)于臨時將資源和資源擴(kuò)大倍，以正常速度的倍來消費消息。解決方案這種情況下，實際上沒有什么消息擠壓，而是丟了大量的消息。 1.大量消息在mq里積壓了幾個小時了還沒解決 場景： 幾千萬條數(shù)據(jù)在MQ里積壓了七八個小時，從下午4點多，積壓到了晚上很晚，10點多，11點多。線上故障了，這個時候要不然就是修復(fù)consumer的問題，讓他恢復(fù)消...
摘要：一個對應(yīng)一個，但是里面進(jìn)行了多線程消費，這樣也會造成消息消費順序錯誤。保證消息的消費順序拆分多個，每個一個，就是多一些而已，確實是麻煩點這樣也會造成吞吐量下降，可以在消費者內(nèi)部采用多線程的方式取消費。 1.為什么要保證順序 消息隊列中的若干消息如果是對同一個數(shù)據(jù)進(jìn)行操作，這些操作具有前后的關(guān)系，必須要按前后的順序執(zhí)行，否則就會造成數(shù)據(jù)異常。舉例： 比如通過mysql binlog進(jìn)行兩個數(shù)據(jù)...
摘要：消費端弄丟了數(shù)據(jù)關(guān)閉自動提交，在自己處理完畢之后手動提交，這樣就不會丟失數(shù)據(jù)。弄丟了數(shù)據(jù)一般要求設(shè)置個參數(shù)來保證消息不丟失給設(shè)置參數(shù)這個值必須大于，表示要求每個必須至少有個副本。上一篇如何保證消息不重復(fù)消費下一篇如何保證消息按順序執(zhí)行 1.mq原則 數(shù)據(jù)不能多，也不能少，不能多是說消息不能重復(fù)消費，這個我們上一節(jié)已解決；不能少，就是說不能丟失數(shù)據(jù)。如果mq傳遞的是非常核心的消息，支撐核心的業(yè)...
摘要：這個是類似的一種結(jié)構(gòu)，這個一般就是可以將結(jié)構(gòu)化的數(shù)據(jù)，比如一個對象前提是這個對象沒嵌套其他的對象給緩存在里，然后每次讀寫緩存的時候，可以就操作里的某個字段。 1.string 這是最基本的類型了，就是普通的set和get，做簡單的kv緩存。 2.hash 這個是類似map的一種結(jié)構(gòu)，這個一般就是可以將結(jié)構(gòu)化的數(shù)據(jù)，比如一個對象（前提是這個對象沒嵌套其他的對象）給緩存在redis里，然后每次...
閱讀 3509·2021-11-19 09:40
閱讀 1528·2021-10-13 09:41
閱讀 2709·2021-09-29 09:35
閱讀 2751·2021-09-23 11:21
閱讀 1748·2021-09-09 11:56
閱讀 860·2019-08-30 15:53
閱讀 862·2019-08-30 15:52
閱讀 623·2019-08-30 12:47
