解耦

解耦：現(xiàn)場畫個圖來說明一下，A系統(tǒng)發(fā)送個數(shù)據(jù)到BCD三個系統(tǒng)，接口調(diào)用發(fā)送，那如果E系統(tǒng)也要這個數(shù)據(jù)呢？那如果C系統(tǒng)現(xiàn)在不需要了呢？現(xiàn)在A系統(tǒng)又要發(fā)送第二種數(shù)據(jù)了呢？A系統(tǒng)負責(zé)人瀕臨崩潰中。。。再來點更加崩潰的事兒，A系統(tǒng)要時時刻刻考慮BCDE四個系統(tǒng)如果掛了咋辦？我要不要重發(fā)？我要不要把消息存起來？頭發(fā)都白了啊。。。

圖片.png

異步

場畫個圖來說明一下，A系統(tǒng)接收一個請求，需要在自己本地寫庫，還需要在BCD三個系統(tǒng)寫庫，自己本地寫庫要3ms，BCD三個系統(tǒng)分別寫庫要300ms、450ms、200ms。最終請求總延時是3 + 300 + 450 + 200 = 953ms，接近1s，用戶感覺搞個什么東西，慢死了慢死了。

削峰：每天0點到11點，A系統(tǒng)風(fēng)平浪靜，每秒并發(fā)請求數(shù)量就100個。結(jié)果每次一到11點~1點，每秒并發(fā)請求數(shù)量突然會暴增到1萬條。但是系統(tǒng)最大的處理能力就只能是每秒鐘處理1000個請求啊。。。尷尬了，系統(tǒng)會死。。。

04_使用MQ進行異步化之后的接口性能優(yōu)化.png

發(fā)布訂閱消息解耦.png

消息隊列優(yōu)缺點

優(yōu)點上面已經(jīng)說了，就是在特殊場景下有其對應(yīng)的好處，解耦、異步、削峰
缺點呢？顯而易見的

系統(tǒng)可用性降低：系統(tǒng)引入的外部依賴越多，越容易掛掉，本來你就是A系統(tǒng)調(diào)用BCD三個系統(tǒng)的接口就好了，人ABCD四個系統(tǒng)好好的，沒啥問題，你偏加個MQ進來，萬一MQ掛了咋整？MQ掛了，整套系統(tǒng)崩潰了，你不就完了么。

系統(tǒng)復(fù)雜性提高：硬生生加個MQ進來，你怎么保證消息沒有重復(fù)消費？怎么處理消息丟失的情況？怎么保證消息傳遞的順序性？頭大頭大，問題一大堆，痛苦不已

一致性問題：A系統(tǒng)處理完了直接返回成功了，人都以為你這個請求就成功了；但是問題是，要是BCD三個系統(tǒng)那里，BD兩個系統(tǒng)寫庫成功了，結(jié)果C系統(tǒng)寫庫失敗了，咋整？你這數(shù)據(jù)就不一致了。（需要分布式事務(wù)）

所以消息隊列實際是一種非常復(fù)雜的架構(gòu)，你引入它有很多好處，但是也得針對它帶來的壞處做各種額外的技術(shù)方案和架構(gòu)來規(guī)避掉，最好之后，你會發(fā)現(xiàn)，媽呀，系統(tǒng)復(fù)雜度提升了一個數(shù)量級，也許是復(fù)雜了10倍。但是關(guān)鍵時刻，用，還是得用的。。。

系統(tǒng)復(fù)雜性3.png

對比kafka、activemq、 rabbitmq、 rocketmq

1.ActiveMQ
-萬級，吞吐量比RocketMQ和Kafka要低了一個數(shù)量級
-時效性，ms級
-可用性 高，基于主從架構(gòu)實現(xiàn)高可用性
-消息可靠性 有較低的概率丟失數(shù)據(jù)
-功能支持，MQ領(lǐng)域的功能極其完備
-優(yōu)劣勢總結(jié) 非常成熟，功能強大，在業(yè)內(nèi)大量的公司以及項目中都有應(yīng)用
偶爾會有較低概率丟失消息，而且現(xiàn)在社區(qū)以及國內(nèi)應(yīng)用都越來越少，官方社區(qū)現(xiàn)在對ActiveMQ 5.x維護越來越少，幾個月才發(fā)布一個版本，而且確實主要是基于解耦和異步來用的，較少在大規(guī)模吞吐的場景中使用
2.RabbitMQ
-萬級，吞吐量比RocketMQ和Kafka要低了一個數(shù)量級
-時效性 微秒級，這是rabbitmq的一大特點，延遲是最低的
-可用性 高，基于主從架構(gòu)實現(xiàn)高可用性
-功能支持 基于erlang開發(fā)，所以并發(fā)能力很強，性能極其好，延時很低
-優(yōu)劣勢 erlang語言開發(fā)，性能極其好，延時很低；吞吐量到萬級，MQ功能比較完備。
而且開源提供的管理界面非常棒，用起來很好用，社區(qū)相對比較活躍，幾乎每個月都發(fā)布幾個版本。
在國內(nèi)一些互聯(lián)網(wǎng)公司近幾年用rabbitmq也比較多一些。但是問題也是顯而易見的，RabbitMQ確實吞吐量會低一些，這是因為他做的實現(xiàn)機制比較重。而且erlang開發(fā)，國內(nèi)有幾個公司有實力做erlang源碼級別的研究和定制？如果說你沒這個實力的話，確實偶爾會有一些問題，你很難去看懂源碼，你公司對這個東西的掌控很弱，基本職能依賴于開源社區(qū)的快速維護和修復(fù)bug。而且rabbitmq集群動態(tài)擴展會很麻煩，不過這個我覺得還好。其實主要是erlang語言本身帶來的問題。很難讀源碼，很難定制和掌控。
3.RocketMQ
-10萬級，RocketMQ也是可以支撐高吞吐的一種MQ
-topic數(shù)量對吞吐的影響 topic可以達到幾百，幾千個的級別，吞吐量會有較小幅度的下降
這是RocketMQ的一大優(yōu)勢，在同等機器下，可以支撐大量的topic
-時效性 ms級
-可用性 非常高，分布式架構(gòu)
-消息可靠性 經(jīng)過參數(shù)優(yōu)化配置，可以 做到0丟失
-功能支持 MQ功能較為完善，還是 分布式的，擴展性好
-優(yōu)劣勢總結(jié) 接口簡單易用，而且畢竟在阿里大規(guī)模應(yīng)用過，有阿里品牌保障，日處理消息上百億之多，可以做到大規(guī)模吞吐，性能也非常好，分布式擴展也很方便，社區(qū)維護還可以，可靠性和可用性都是ok的，還可以支撐大規(guī)模的topic數(shù)量，支持復(fù)雜MQ業(yè)務(wù)場景，而且一個很大的優(yōu)勢在于，阿里出品都是java系的，我們可以自己閱讀源碼，定制自己公司的MQ，可以掌控社區(qū)活躍度相對較為一般，不過也還可以，文檔相對來說簡單一些，然后接口這塊不是按照標(biāo)準(zhǔn)JMS規(guī)范走的有些系統(tǒng)要遷移需要修改大量代碼。還有就是阿里出臺的技術(shù)，你得做好這個技術(shù)萬一被拋棄，社區(qū)黃掉的風(fēng)險，那如果你們公司有技術(shù)實力我覺得用RocketMQ挺好的
4.kafka
-10萬級別,這是kafka最大的優(yōu)點，就是吞吐量高。 一般配合大數(shù)據(jù)類的系統(tǒng)進行實時數(shù)據(jù)計算、日志采集等場景
-topic數(shù)量對吞吐的影響 topic從幾十個到幾百個的時候，吞吐量會大幅度下降，所以在同等機器下，kafka盡量保證topic數(shù)量不要過多。如果要支撐大規(guī)模topic，需要增加更多的機器資源
-時效性 延遲在ms級以內(nèi)
-可用性 非常高，kafka是分布式的，一個數(shù)據(jù)多個副本，少數(shù)機器宕機，不會丟失數(shù)據(jù)，不會導(dǎo)致不可用
-消息可靠性 經(jīng)過參數(shù)優(yōu)化配置，消息可以做到0丟失
-功能支持 功能較為簡單，主要支持簡單的MQ功能，在大數(shù)據(jù)領(lǐng)域的實時計算以及日志采集被大規(guī)模使用，是事實上的標(biāo)準(zhǔn)
-優(yōu)劣勢總結(jié)
kafka的特點其實很明顯，就是僅僅提供較少的核心功能，但是提供超高的吞吐量，ms級的延遲，極高的可用性以及可靠性，而且分布式可以任意擴展，同時kafka最好是支撐較少的topic數(shù)量即可，保證其超高吞吐量，
而且kafka唯一的一點劣勢是有可能消息重復(fù)消費，那么對數(shù)據(jù)準(zhǔn)確性會造成極其輕微的影響，在大數(shù)據(jù)領(lǐng)域中以及日志采集中，這點輕微影響可以忽略，這個特性天然適合大數(shù)據(jù)實時計算以及日志收集

異步.png

削峰.png

增加MQ后帶來的缺點.png