大數(shù)據(jù)Kafka:消息隊(duì)列和Kafka基本介紹
一、什么是消息隊(duì)列
消息隊(duì)列,英文名:Message Queue,經(jīng)??s寫為MQ。從字面上來(lái)理解,消息隊(duì)列是一種用來(lái)存儲(chǔ)消息的隊(duì)列 。來(lái)看一下下面的代碼
上述代碼,創(chuàng)建了一個(gè)隊(duì)列,先往隊(duì)列中添加了一個(gè)消息,然后又從隊(duì)列中取出了一個(gè)消息。這說(shuō)明了隊(duì)列是可以用來(lái)存取消息的
總結(jié):消息隊(duì)列指的就是將數(shù)據(jù)放置到一個(gè)隊(duì)列中, 從隊(duì)列一端進(jìn)入, 然后從另一端流出的過(guò)程
二、消息隊(duì)列的應(yīng)用場(chǎng)景
消息隊(duì)列在實(shí)際應(yīng)用中包括如下四個(gè)場(chǎng)景:
1、應(yīng)用耦合:
多應(yīng)用間通過(guò)消息隊(duì)列對(duì)同一消息進(jìn)行處理,避免調(diào)用接口失敗導(dǎo)致整個(gè)過(guò)程失??;
2、異步處理:
多應(yīng)用對(duì)消息隊(duì)列中同一消息進(jìn)行處理,應(yīng)用間并發(fā)處理消息,相比串行處理,減少處理時(shí)間;
3、限流削峰:
廣泛應(yīng)用于秒殺或搶購(gòu)活動(dòng)中,避免流量過(guò)大導(dǎo)致應(yīng)用系統(tǒng)掛掉的情況;
4、消息驅(qū)動(dòng)的系統(tǒng):
系統(tǒng)分為消息隊(duì)列、消息生產(chǎn)者、消息消費(fèi)者,生產(chǎn)者負(fù)責(zé)產(chǎn)生消息,消費(fèi)者(可能有多個(gè))負(fù)責(zé)對(duì)消息進(jìn)行處理
下面詳細(xì)介紹上述四個(gè)場(chǎng)景以及消息隊(duì)列如何在上述四個(gè)場(chǎng)景中使用
異步處理
具體場(chǎng)景:用戶為了使用某個(gè)應(yīng)用,進(jìn)行注冊(cè),系統(tǒng)需要發(fā)送注冊(cè)郵件并驗(yàn)證短信。
對(duì)這兩個(gè)操作的處理方式有兩種:串行及并行。
1) 串行方式: 新注冊(cè)信息生成后 , 先發(fā)送注冊(cè)郵件, 再發(fā)送驗(yàn)證短信
注意 : 在這種方式下,需要最終發(fā)送驗(yàn)證短信后再返回給客戶端
2) 并行處理:新注冊(cè)信息寫入后,由發(fā)短信和發(fā)郵件并行處理
注意: 在這種方式下,發(fā)短信和發(fā)郵件 需處理完成后再返回給客戶端。
假設(shè)以上三個(gè)子系統(tǒng)處理的時(shí)間均為 50ms ,且不考慮網(wǎng)絡(luò)延遲
則總的處理時(shí)間: 串行: 50+50+50=150ms
并行: 50+50 = 100ms
如果引入消息隊(duì)列 , 在來(lái)看整體的執(zhí)行效率 :
在寫入消息隊(duì)列后立即返回成功給客戶端,則總的響應(yīng)時(shí)間依賴于寫入消息隊(duì)列的時(shí)間,而寫入消息隊(duì)列的時(shí)間本身是可以很快的,基本可以忽略不計(jì),因此總的處理時(shí)間相比串行提高了2倍,相比并行提高了一倍;
應(yīng)用耦合
具體場(chǎng)景:
用戶使用 QQ 相冊(cè)上傳一張圖片,人臉識(shí)別系統(tǒng)會(huì)對(duì)該圖片進(jìn)行人臉識(shí)別,一般的做法是,服務(wù)器接收到圖片后,圖片上傳系統(tǒng)立即調(diào)用人臉識(shí)別系統(tǒng),調(diào)用完成后再返回成功,如下圖所示: 如果引入消息隊(duì)列 , 在來(lái)看整體的執(zhí)行效率
該方法有如下缺點(diǎn):
1) 人臉識(shí)別系統(tǒng)被調(diào)失敗,導(dǎo)致圖片上傳失??;
2) 延遲高,需要人臉識(shí)別系統(tǒng)處理完成后,再返回給客戶端,即使用戶并不需要立即知道結(jié)果;
3) 圖片上傳系統(tǒng)與人臉識(shí)別系統(tǒng)之間互相調(diào)用,需要做耦合; 若使用消息隊(duì)列:
此時(shí)圖片上傳系統(tǒng)并不需要關(guān)心人臉識(shí)別系統(tǒng)是否對(duì)這些圖片信息的處理、以及何時(shí)對(duì)這些圖片信息進(jìn)行處理。
事實(shí)上,由于用戶并不需要立即知道人臉識(shí)別結(jié)果,人臉識(shí)別系統(tǒng)可以選擇不同的調(diào)度策略,按照閑時(shí)、忙時(shí)、正常時(shí) 間,對(duì)隊(duì)列中的圖片信息進(jìn)行處理。
限流削峰
具體場(chǎng)景:
購(gòu)物網(wǎng)站開(kāi)展秒殺活動(dòng),一般由于瞬時(shí)訪問(wèn)量過(guò)大,服務(wù)器接收過(guò)大,會(huì)導(dǎo)致流量暴增,相關(guān)系統(tǒng)無(wú)法處理請(qǐng)求甚至崩潰。而加入消息隊(duì)列后,系統(tǒng)可以從消息隊(duì)列中取數(shù)據(jù),相當(dāng)于消息隊(duì)列做了一次緩沖。
該方法有如下優(yōu)點(diǎn):
請(qǐng)求先入消息隊(duì)列,而不是由業(yè)務(wù)處理系統(tǒng)直接處理,做了一次緩沖 , 極大地減少了業(yè)務(wù)處理系統(tǒng)的壓力;
隊(duì)列長(zhǎng)度可以做限制,事實(shí)上,秒殺時(shí),后入隊(duì)列的用戶無(wú)法秒殺到商品,這些請(qǐng)求可以直接被拋棄,返回活動(dòng)已結(jié)束或商品已售完信息;
消息驅(qū)動(dòng)系統(tǒng)
具體場(chǎng)景:用戶新上傳了一批照片, 人臉識(shí)別系統(tǒng)需要對(duì)這個(gè)用戶的所有照片進(jìn)行聚類,聚類完成后由對(duì)賬系統(tǒng)重新生成用 戶的人臉?biāo)饕? 加快查詢 ) 。這三個(gè)子系統(tǒng)間由消息隊(duì)列連接起來(lái),前一個(gè)階段的處理結(jié)果放入隊(duì)列中,后一個(gè)階段從隊(duì)列中獲取消息繼續(xù)處理。
該方法有如下優(yōu)點(diǎn):
避免了直接調(diào)用下一個(gè)系統(tǒng)導(dǎo)致當(dāng)前系統(tǒng)失??;
每個(gè)子系統(tǒng)對(duì)于消息的處理方式可以更為靈活,可以選擇收到消息時(shí)就處理,可以選擇定時(shí)處理,也可以劃分時(shí)間 段按不同處理速度處理;
三、消息隊(duì)列的兩種方式
點(diǎn)對(duì)點(diǎn)模式
點(diǎn)對(duì)點(diǎn)模式下包括三個(gè)角色
- 消息隊(duì)列
- 發(fā)送者 (生產(chǎn)者)
- 接收者(消費(fèi)者)
消息發(fā)送者生產(chǎn)消息發(fā)送到 queue 中,然后消息接收者從 queue 中取出并且消費(fèi)消息。消息被消費(fèi)以后, queue 中不再有存儲(chǔ),所以消息接收者不可能消費(fèi)到已經(jīng)被消費(fèi)的消息。 點(diǎn)對(duì)點(diǎn)模式特點(diǎn):
每個(gè)消息只有一個(gè)接收者(Consumer)(即一旦被消費(fèi),消息就不再在消息隊(duì)列中);
發(fā)送者和接收者間沒(méi)有依賴性,發(fā)送者發(fā)送消息之后,不管有沒(méi)有接收者在運(yùn)行,都不會(huì)影響到發(fā)送者下次發(fā)送消息;
接收者在成功接收消息之后需向隊(duì)列應(yīng)答成功,以便消息隊(duì)列刪除當(dāng)前接收的消息;
發(fā)布/訂閱模式
發(fā)布 / 訂閱模式下包括三個(gè)角色:
- 角色主題(Topic)
- 發(fā)布者(Publisher)
- 訂閱者(Subscriber)
發(fā)布者將消息發(fā)送到 Topic, 系統(tǒng)將這些消息傳遞給多個(gè)訂閱者。 發(fā)布 / 訂閱模式特點(diǎn):
每個(gè)消息可以有多個(gè)訂閱者;
發(fā)布者和訂閱者之間有時(shí)間上的依賴性。針對(duì)某個(gè)主題(Topic)的訂閱者,它必須創(chuàng)建一個(gè)訂閱者之后,才能消費(fèi)發(fā)布者的消息。
為了消費(fèi)消息,訂閱者需要提前訂閱該角色主題,并保持在線運(yùn)行;
四、常見(jiàn)的消息隊(duì)列的產(chǎn)品
1) RabbitMQ
RabbitMQ 2007 年發(fā)布,是一個(gè)在 AMQP ( 高級(jí)消息隊(duì)列協(xié)議 ) 基礎(chǔ)上完成的,可復(fù)用的企業(yè)消息系統(tǒng),是當(dāng)前最主 流的消息中間件之一。
2) activeMQ:
ActiveMQ 是由 Apache 出品, ActiveMQ 是一個(gè)完全支持 JMS1.1 和 J2EE 1.4 規(guī)范的 JMS Provider 實(shí)現(xiàn)。它非??焖?,支持多種語(yǔ)言的客戶端和協(xié)議,而且可以非常容易的嵌入到企業(yè)的應(yīng)用環(huán)境中,并有許多高級(jí)功能, 目前市場(chǎng)的活躍 度比較低, 在 java 領(lǐng)域正在被 RabbitMQ 替代
3) RocketMQ
RocketMQ 出自 阿里公司的開(kāi)源產(chǎn)品,用 Java 語(yǔ)言實(shí)現(xiàn),在設(shè)計(jì)時(shí)參考了 Kafka ,并做出了自己的一些改進(jìn),消息可靠性上比 Kafka 更好。 RocketMQ 在阿里集團(tuán)被廣泛應(yīng)用在訂單,交易,充值,流計(jì)算,消息推送,日志流式處理 等
4) kafka
Apache Kafka 是一個(gè)分布式消息發(fā)布訂閱系統(tǒng)。它最初由 LinkedIn 公司基于獨(dú)特的設(shè)計(jì)實(shí)現(xiàn)為一個(gè)分布式的提交日志系統(tǒng)( a distributed commit log) ,之后成為 Apache 項(xiàng)目的一部分。 Kafka 系統(tǒng)快速、可擴(kuò)展并且可持久化。它的分區(qū)特性,可復(fù)制和可容錯(cuò)都是其不錯(cuò)的特性。 各種消息隊(duì)列產(chǎn)品的對(duì)比圖:
五、Kafka的基本介紹
kafka 是最初由 linkedin 公司開(kāi)發(fā)的,使用 scala 語(yǔ)言編寫, kafka 是一個(gè)分布式,分區(qū)的,多副本的,多訂閱者的日 志系統(tǒng)(分布式MQ 系統(tǒng)),可以用于搜索日志,監(jiān)控日志,訪問(wèn)日志等 Kafka is a distributed,partitioned,replicated commit logservice 。
它提供了類似于 JMS 的特性,但是在設(shè)計(jì)實(shí)現(xiàn)上完全不同,此外它并不是JMS 規(guī)范的完整實(shí)現(xiàn)。
kafka 對(duì)消息保存時(shí)根據(jù) Topic 進(jìn)行歸類,發(fā)送消息者成為 Producer, 消息 接受者成為Consumer, 此外 kafka 集群有多個(gè) kafka 實(shí)例組成,每個(gè)實(shí)例 (server) 成為 broker 。
無(wú)論是 kafka 集群,還是producer和 consumer 都依賴于 zookeeper 來(lái)保證系統(tǒng)可用性集群保存一些 meta 信息
kakfa的特點(diǎn):
- 可靠性: 分布式, 分區(qū) , 復(fù)制 和容錯(cuò)等
- 可擴(kuò)展性: kakfa消息傳遞系統(tǒng)輕松縮放, 無(wú)需停機(jī)
- 耐用性: kafka使用分布式提交日志, 這個(gè)意味著消息會(huì)盡可能快速的保存在磁盤上, 因此它是持久的
- 性能: kafka對(duì)于發(fā)布和訂閱消息都具有高吞吐量, 即使存儲(chǔ)了許多TB的消息, 他也爆出穩(wěn)定的性能-kafka非常快: 保證零停機(jī)和零數(shù)據(jù)丟失
apache kafka 是一個(gè)分布式發(fā)布 - 訂閱消息系統(tǒng)和一個(gè)強(qiáng)大的隊(duì)列,可以處理大量的數(shù)據(jù),并使能夠?qū)⑾囊粋€(gè) 端點(diǎn)傳遞到另一個(gè)端點(diǎn),kafka 適合離線和在線消息消費(fèi)。 kafka 消息保留在磁盤上,并在集群內(nèi)復(fù)制以防止數(shù)據(jù)丟失。kafka構(gòu)建在 zookeeper 同步服務(wù)之上。它與 apache 和 spark 非常好的集成,應(yīng)用于實(shí)時(shí)流式數(shù)據(jù)分析。
kafka的主要應(yīng)用場(chǎng)景:
1) 指標(biāo)分析 : kafka 通常用于操作監(jiān)控?cái)?shù)據(jù) , 這設(shè)計(jì)聚合來(lái)自分布式應(yīng)用程序和統(tǒng)計(jì)信息 , 以產(chǎn)生操作的數(shù)據(jù)集中反饋
2) 日志聚合解決方法 : kafka 可用于跨組織從多個(gè)服務(wù)器收集日志 , 并使他們一標(biāo)準(zhǔn)的合適提供給多個(gè)服務(wù)器
3) 流式處理 : 流式的處理框架 (spark, storm , flink) 從主題中讀取數(shù)據(jù) , 對(duì)其進(jìn)行處理 , 并將處理后的結(jié)果數(shù)據(jù)寫入新的主題, 供用戶和應(yīng)用程序使用 , kafka 的強(qiáng)耐久性在流處理的上下文中也非常的有用
到此這篇關(guān)于大數(shù)據(jù)Kafka:消息隊(duì)列和Kafka基本介紹的文章就介紹到這了,更多相關(guān)大數(shù)據(jù)消息隊(duì)列和Kafka內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
SpringCloud分布式鏈路追蹤組件Sleuth配置詳解
這篇文章主要介紹了SpringCloud鏈路追蹤組件Sleuth配置方法解析,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2022-11-11淺談hashmap為什么查詢時(shí)間復(fù)雜度為O(1)
這篇文章主要介紹了hashmap為什么查詢時(shí)間復(fù)雜度為O(1),具有很好的參考價(jià)值,希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2021-08-08SpringCloud之Config配置中心與Redis分布式鎖詳解
這篇文章主要給大家介紹了SpringCloud Alibaba中Config配置中心,Redis分布式鎖,文中有詳細(xì)的代碼示例供大家參考,需要的朋友可以參考閱讀2023-05-05Maven 版本管理與 flatten-maven-plugin 插件的使用解析
這篇文章主要介紹了Maven 版本管理與 flatten-maven-plugin 插件的使用解析,本文通過(guò)示例代碼給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2023-07-07Java數(shù)據(jù)結(jié)構(gòu)順序表從零基礎(chǔ)到精通進(jìn)階
程序中經(jīng)常需要將一組數(shù)據(jù)元素作為整體管理和使用,需要?jiǎng)?chuàng)建這種元素組,用變量記錄它們,傳進(jìn)傳出函數(shù)等。一組數(shù)據(jù)中包含的元素個(gè)數(shù)可能發(fā)生變化,順序表則是將元素順序地存放在一塊連續(xù)的存儲(chǔ)區(qū)里,元素間的順序關(guān)系由它們的存儲(chǔ)順序自然表示2022-03-03關(guān)于Nacos單機(jī)啟動(dòng)的兩種方式
這篇文章主要介紹了關(guān)于Nacos單機(jī)啟動(dòng)的兩種方式,具有很好的參考價(jià)值,希望對(duì)大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-08-08Spring AOP面向切面編程實(shí)現(xiàn)及配置詳解
這篇文章主要介紹了Spring AOP面向切面編程實(shí)現(xiàn)及配置詳解,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-09-09