前言
10多年的浠水網(wǎng)站建設(shè)經(jīng)驗(yàn)，針對(duì)設(shè)計(jì)、前端、開發(fā)、售后、文案、推廣等六對(duì)一服務(wù)，響應(yīng)快，48小時(shí)及時(shí)工作處理。網(wǎng)絡(luò)營銷推廣的優(yōu)勢是能夠根據(jù)用戶設(shè)備顯示端的尺寸不同，自動(dòng)調(diào)整浠水建站的顯示方式，使網(wǎng)站能夠適用不同顯示終端，在瀏覽器中調(diào)整網(wǎng)站的寬度，無論在任何一種瀏覽器上瀏覽網(wǎng)站，都能展現(xiàn)優(yōu)雅布局與設(shè)計(jì)，從而大程度地提升瀏覽體驗(yàn)。成都創(chuàng)新互聯(lián)從事“浠水網(wǎng)站設(shè)計(jì)”,“浠水網(wǎng)站推廣”以來，每個(gè)客戶項(xiàng)目都認(rèn)真落實(shí)執(zhí)行。
公司的項(xiàng)目一直都是在使用MQ的，但是由于使用的功能很簡單，所以一直都是知其然不知其所以然，作為一個(gè)程序猿有必要了解每一個(gè)使用的技術(shù)，為什么使用它？它的優(yōu)點(diǎn)是什么？缺點(diǎn)是什么？等等。。。
使用mq的好處
解耦與復(fù)用
系統(tǒng)A要發(fā)送一個(gè)消息到多個(gè)系統(tǒng)，如果此時(shí)每增加一個(gè)系統(tǒng)，系統(tǒng)A都需要通過修改源碼來增加接口，此時(shí)耦合非常高，但是如果中間使用消息隊(duì)列的話，系統(tǒng)只需要發(fā)送一次到消息隊(duì)列，別的系統(tǒng)就能復(fù)用該信息，當(dāng)增加或刪除系統(tǒng)調(diào)用接口的時(shí)候，不需要額外的更新代碼。
異步
用戶調(diào)用一個(gè)接口的時(shí)候，可能該接口調(diào)用了別的方法。例如：用戶注冊(cè)的時(shí)候，后臺(tái)可能需要調(diào)用：查詢數(shù)據(jù)庫，插入數(shù)據(jù)庫，發(fā)送郵件，發(fā)送用戶指南等等...
但是用戶可能并不需要后臺(tái)將所有的任務(wù)執(zhí)行完畢，那么此時(shí)在初入數(shù)據(jù)口后面加入mq隊(duì)列，用戶就能很快得到注冊(cè)成功的響應(yīng)而去做一些別的事情。mq的機(jī)制又能保證最終的一致性，所以使用起來很安全很穩(wěn)定。
消峰
何為消峰，就是當(dāng)系統(tǒng)壓力過大的時(shí)候，讓系統(tǒng)壓力減小。如何做？
加入數(shù)據(jù)庫的讀寫每秒3000，在高峰期，系統(tǒng)的訪問達(dá)到了每秒10000。此時(shí)由于加入了消息隊(duì)列，所以不會(huì)出現(xiàn)激增的訪問導(dǎo)致系統(tǒng)奔潰。
（注意，曉峰并不會(huì)讓用戶的等待時(shí)間減少，所以一般會(huì)跟異步搭配來使用）
使用mq的缺點(diǎn)
增加了復(fù)雜度與降低了可用性
本來系統(tǒng)之間直接通行調(diào)用接口就行了，但是引入了mq導(dǎo)致系統(tǒng)的復(fù)雜度大大增加，并且如果mq掛掉了，那么系統(tǒng)之間的通信就中斷了，導(dǎo)致整個(gè)系統(tǒng)的全部掛掉。
一致性問題
A系統(tǒng)處理完了發(fā)送到消息對(duì)流后直接返回成功了，用戶以為你這個(gè)請(qǐng)求就成功了；但是問題是，其他系統(tǒng)消費(fèi)該消息后，如果當(dāng)中有一個(gè)系統(tǒng)出現(xiàn)了問題，導(dǎo)致數(shù)據(jù)丟失。最后就會(huì)發(fā)生數(shù)據(jù)不一致等問題。
常見的mq的區(qū)別
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 單機(jī)吞吐量 | 萬級(jí)，吞吐量比RocketMQ和Kafka要低了一個(gè)數(shù)量級(jí) | 萬級(jí)，吞吐量比RocketMQ和Kafka要低了一個(gè)數(shù)量級(jí) | 10萬級(jí)，RocketMQ也是可以支撐高吞吐的一種MQ | 10萬級(jí)別，這是kafka最大的優(yōu)點(diǎn)，就是吞吐量高。一般配合大數(shù)據(jù)類的系統(tǒng)來進(jìn)行實(shí)時(shí)數(shù)據(jù)計(jì)算、日志采集等場景 |
| topic數(shù)量對(duì)吞吐量的影響 | topic可以達(dá)到幾百，幾千個(gè)的級(jí)別，吞吐量會(huì)有較小幅度的下降這是RocketMQ的一大優(yōu)勢，在同等機(jī)器下，可 | topic可以達(dá)到幾百，幾千個(gè)的級(jí)別，吞吐量會(huì)有較小幅度的下降這是RocketMQ的一大優(yōu)勢，在同等機(jī)器下，可 | ||
| 時(shí)效性 | ms級(jí) | 微秒級(jí)，這是rabbitmq的一大特點(diǎn)，延遲是最低的 | ms級(jí) | 延遲在ms級(jí)以內(nèi) |
| 可用性 | 高，基于主從架構(gòu)實(shí)現(xiàn)高可用性 | 高，基于主從架構(gòu)實(shí)現(xiàn)高可用性 | 非常高，分布式架構(gòu) | 非常高，kafka是分布式的，一個(gè)數(shù)據(jù)多個(gè)副本，少數(shù)機(jī)器宕機(jī)，不會(huì)丟失數(shù)據(jù)，不會(huì)導(dǎo)致不可用 |
| 消息可靠性 | 有較低的概率丟失數(shù)據(jù) | 經(jīng)過參數(shù)優(yōu)化配置，可以做到0丟失 | 經(jīng)過參數(shù)優(yōu)化配置，消息可以做到0丟失 | |
| 功能支持 | MQ領(lǐng)域的功能極其完備 | 基于erlang開發(fā)，所以并發(fā)能力很強(qiáng)，性能極其好，延時(shí)很低 | MQ功能較為完善，還是分布式的，擴(kuò)展性好 | 功能較為簡單，主要支持簡單的MQ功能，在大數(shù)據(jù)領(lǐng)域的實(shí)時(shí)計(jì)算以及日志采集被大規(guī)模使用，是事實(shí)上的標(biāo)準(zhǔn) |
| 優(yōu)劣勢總結(jié) | 非常成熟，功能強(qiáng)大，在業(yè)內(nèi)大量的公司以及項(xiàng)目中都有應(yīng)用偶爾會(huì)有較低概率丟失消息而且現(xiàn)在社區(qū)以及國內(nèi)應(yīng)用都越來越少，官方社區(qū)現(xiàn)在對(duì)ActiveMQ 5.x維護(hù)越來越少，幾個(gè)月才發(fā)布一個(gè)版本而且確實(shí)主要是基于解耦和異步來用的，較少在大規(guī)模吞吐的場景中使用 | erlang語言開發(fā)，性能極其好，延時(shí)很低；吞吐量到萬級(jí)，MQ功能比較完備而且開源提供的管理界面非常棒，用起來很好用社區(qū)相對(duì)比較活的。RabbitMQ吞吐量會(huì)低一些，這是因?yàn)樗龅膶?shí)現(xiàn)機(jī)制比較重。erlang開發(fā)很難去看懂源碼，你公司對(duì)這個(gè)東西的掌控很弱，基本職能依賴于開源社區(qū)的快速維護(hù)和修復(fù)bug。 | 接口簡單易用，而且畢竟在阿里大規(guī)模應(yīng)用過，可以做到大規(guī)模吞吐，性能也非常好，分布式擴(kuò)展也很方便，社區(qū)維護(hù)還可以，可靠性和可用性是ok的，還可以支撐大規(guī)模的topic數(shù)量。阿里出品都是java系的，我們可以自己閱讀源碼。 | kafka的特點(diǎn)其實(shí)很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms級(jí)的延遲，極高的可用性以及可靠性，而且分布式可以任意擴(kuò)展同時(shí)kafka最好是支撐較少的topic數(shù)量即可，保證其超高吞吐量而且kafka唯一的一點(diǎn)劣勢是有可能消息重復(fù)消 |
總結(jié)
所以在軟件的正常功能開發(fā)中，并不需要去刻意的尋找消息隊(duì)列的使用場景，而是當(dāng)出現(xiàn)性能瓶頸時(shí)，去查看業(yè)務(wù)邏輯是否存在可以異步處理的耗時(shí)操作，如果存在的話便可以引入消息隊(duì)列來解決。否則盲目的使用消息隊(duì)列可能會(huì)增加維護(hù)和開發(fā)的成本卻無法得到可觀的性能提升，那就得不償失了。
以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持創(chuàng)新互聯(lián)。
重慶分公司
重慶分公司
