阿里P8架構師談:消息中間件介紹、典型使用場景、以及使用原則

大型分佈式架構裏必定會涉及到消息中間件,今天先談談消息中間件。前端

經常使用的消息隊列有ActiveMQ,RabbitMQ,ZeroMQ,Kafka,MetaMQ,RocketMQ。sql

1、kafka

一、不徹底符合jms規範,注重吞吐量,相似udp 和 tcp服務器

二、通常作大數據吞吐的管道 咱們如今的用途就是負責在各個idc之間通訊架構

三、量大對數據不是百分之百保證的,會有數據丟失,不是百分百送達(amq和rmq等有重發機制,而kafka沒有);在吞吐量有提高 ,在這方面就得有犧牲, 因此kafka適合大數據量流轉, 好比日誌數據 好比用做統計的數據。併發

2、activeMQ

ActiveMQ居於二者之間,相似於ZemoMQ,它能夠部署於代理模式和P2P模式。相似於RabbitMQ,它易於實現高級場景,並且只需付出低消耗。它被譽爲消息中間件的「瑞士軍刀」。異步

三:RocketMQ(阿里官方指定消息中間件)

RocketMQ 是一款開源的分佈式消息系統,基於高可用分佈式集羣技術,提供低延時的、高可靠的消息發佈與訂閱服務。同時,普遍應用於多個領域,包括異步通訊解耦、企業解決方案、金融支付、電信、電子商務、快遞物流、廣告營銷、社交、即時通訊、移動應用、手遊、視頻、物聯網、車聯網等。tcp

消息中間件使用的典型場景優四個分佈式

1.典型的異步處理高併發

2.應用解耦性能

3.流量削鋒

4.消息通信四個場景

好比:今日頭條的私信就是一個典型的消息通信場景,由於消息通信的數據不須要即便當即同步回來,不算是核心數據,能夠延時經過異步的消息發送,這樣能夠下降系統的負荷。

因此,咱們在架構設計的時候,有一個原則就是:消息原則上都是異步消息發送,除非涉及到交易的狀況才考慮數據即便同步,不然能異步的都採用異步消息設計。

再好比:流量削鋒的典型場景就有阿里的雙11秒殺、團購搶購活動等。

應用場景:秒殺活動,通常會由於流量過大,致使流量暴增,應用掛掉。爲解決這個問題,通常須要在應用前端加入消息隊列。

a、能夠控制活動的人數

b、能夠緩解短期內高流量壓垮應用

用戶的請求,服務器接收後,首先寫入消息隊列。假如消息隊列長度超過最大數量,則直接拋棄用戶請求或跳轉到錯誤頁面。

秒殺業務根據消息隊列中的請求信息,再作後續處理。

架構設計之中間件總結:

1.消息中間件的四個典型場景:典型的異步處理、應用解耦、流量削鋒、消息通信四個場景。

2.能異步就不要同步:能異步的消息原則都儘可能採用異步的方式。

3.若是消息性能要求高,用rocketMQ與kafka能夠更優,rocketMQ與kafka 比較就看技術選型了,各有利弊,看業務須要。

4.實現語言來看,RabbitMQ(阿里官方指定消息中間件)最高,緣由是它的實現語言是天生具有高併發高可用的erlang語言。綜合來看,RabbitMQ是首選。

5.典型的秒殺活動、搶購、消息通信、郵件發送、電話短信等都是典型的採用消息中間件的業務場景。

歡迎工做一到五年的Java工程師朋友們加入Java架構開發:760940986
羣內提供免費的Java架構學習資料(裏面有高可用、高併發、高性能及分佈式、Jvm性能調優、Spring源碼,MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料)合理利用本身每一分每一秒的時間來學習提高本身,不要再用"沒有時間「來掩飾本身思想上的懶惰!趁年輕,使勁拼,給將來的本身一個交代!

轉載:https://my.oschina.net/u/3906190/blog/2120665

相關文章
相關標籤/搜索