1. 摘要
以下是消息隊列以下的大綱舅逸,本文主要介紹消息隊列概述桌肴,消息隊列應(yīng)用場景和消息中間件示例(電商,日志系統(tǒng))琉历。
本次分享大綱:
- 消息隊列概述
- 消息隊列應(yīng)用場景
- 消息中間件示例
- JMS消息服務(wù)
- 常用消息隊列
- 參考(推薦)資料
本文轉(zhuǎn)載自#ITFLY8架構(gòu)師之家 的《大型網(wǎng)站架構(gòu)系列:分布式消息隊列》
2. 內(nèi)容
一坠七、消息隊列概述
消息隊列中間件是分布式系統(tǒng)中重要的組件,主要解決應(yīng)用耦合旗笔,異步消息彪置,流量削鋒等問題。實現(xiàn)高性能换团,高可用悉稠,可伸縮和最終一致性架構(gòu)。是大型分布式系統(tǒng)不可缺少的中間件艘包。
目前在生產(chǎn)環(huán)境的猛,使用較多的消息隊列有ActiveMQ,RabbitMQ想虎,ZeroMQ卦尊,Kafka,MetaMQ舌厨,RocketMQ等岂却。
二、消息隊列應(yīng)用場景
以下介紹消息隊列在實際應(yīng)用中常用的使用場景。異步處理躏哩,應(yīng)用解耦署浩,流量削鋒和消息通訊四個場景。
2.1異步處理
場景說明:用戶注冊后扫尺,需要發(fā)注冊郵件和注冊短信筋栋。傳統(tǒng)的做法有兩種1.串行的方式;2.并行方式正驻。
(1)串行方式:將注冊信息寫入數(shù)據(jù)庫成功后弊攘,發(fā)送注冊郵件,再發(fā)送注冊短信姑曙。以上三個任務(wù)全部完成后襟交,返回給客戶端。
(2)并行方式:將注冊信息寫入數(shù)據(jù)庫成功后伤靠,發(fā)送注冊郵件的同時捣域,發(fā)送注冊短信。以上三個任務(wù)完成后醋界,返回給客戶端竟宋。與串行的差別是提完,并行的方式可以提高處理的時間形纺。
假設(shè)三個業(yè)務(wù)節(jié)點每個使用50毫秒鐘,不考慮網(wǎng)絡(luò)等其他開銷徒欣,則串行方式的時間是150毫秒逐样,并行的時間可能是100毫秒。
因為CPU在單位時間內(nèi)處理的請求數(shù)是一定的打肝,假設(shè)CPU1秒內(nèi)吞吐量是100次脂新。則串行方式1秒內(nèi)CPU可處理的請求量是7次(1000/150)。并行方式處理的請求量是10次(1000/100)粗梭。
小結(jié):如以上案例描述争便,傳統(tǒng)的方式系統(tǒng)的性能(并發(fā)量,吞吐量,響應(yīng)時間)會有瓶頸。如何解決這個問題呢搀继?
引入消息隊列辰斋,將不是必須的業(yè)務(wù)邏輯,異步處理综慎。改造后的架構(gòu)如下:
按照以上約定,用戶的響應(yīng)時間相當于是注冊信息寫入數(shù)據(jù)庫的時間,也就是50毫秒兔簇。注冊郵件,發(fā)送短信寫入消息隊列后,直接返回垄琐,因此寫入消息隊列的速度很快边酒,基本可以忽略,因此用戶的響應(yīng)時間可能是50毫秒狸窘。因此架構(gòu)改變后甚纲,系統(tǒng)的吞吐量提高到每秒20 QPS。比串行提高了3倍朦前,比并行提高了兩倍介杆。
2.2應(yīng)用解耦
場景說明:用戶下單后,訂單系統(tǒng)需要通知庫存系統(tǒng)韭寸。傳統(tǒng)的做法是春哨,訂單系統(tǒng)調(diào)用庫存系統(tǒng)的接口。如下圖:
傳統(tǒng)模式的缺點:
1) 假如庫存系統(tǒng)無法訪問恩伺,則訂單減庫存將失敗赴背,從而導(dǎo)致訂單失敗晶渠;
2) 訂單系統(tǒng)與庫存系統(tǒng)耦合凰荚;
如何解決以上問題呢?引入應(yīng)用消息隊列后的方案褒脯,如下圖:
- 訂單系統(tǒng):用戶下單后便瑟,訂單系統(tǒng)完成持久化處理,將消息寫入消息隊列番川,返回用戶訂單下單成功到涂。
- 庫存系統(tǒng):訂閱下單的消息,采用拉/推的方式颁督,獲取下單信息践啄,庫存系統(tǒng)根據(jù)下單信息,進行庫存操作沉御。
- 假如:在下單時庫存系統(tǒng)不能正常使用屿讽。也不影響正常下單,因為下單后吠裆,訂單系統(tǒng)寫入消息隊列就不再關(guān)心其他的后續(xù)操作了伐谈。實現(xiàn)訂單系統(tǒng)與庫存系統(tǒng)的應(yīng)用解耦。
2.3流量削鋒
流量削鋒也是消息隊列中的常用場景硫痰,一般在秒殺或團搶活動中使用廣泛衩婚。
應(yīng)用場景:秒殺活動,一般會因為流量過大效斑,導(dǎo)致流量暴增非春,應(yīng)用掛掉。為解決這個問題,一般需要在應(yīng)用前端加入消息隊列奇昙。
- 可以控制活動的人數(shù)护侮;
- 可以緩解短時間內(nèi)高流量壓垮應(yīng)用;
- 用戶的請求储耐,服務(wù)器接收后羊初,首先寫入消息隊列。假如消息隊列長度超過最大數(shù)量什湘,則直接拋棄用戶請求或跳轉(zhuǎn)到錯誤頁面长赞;
- 秒殺業(yè)務(wù)根據(jù)消息隊列中的請求信息,再做后續(xù)處理闽撤。
2.4日志處理
日志處理是指將消息隊列用在日志處理中得哆,比如Kafka的應(yīng)用,解決大量日志傳輸?shù)膯栴}哟旗。架構(gòu)簡化如下:
- 日志采集客戶端贩据,負責日志數(shù)據(jù)采集,定時寫受寫入Kafka隊列闸餐;
- Kafka消息隊列饱亮,負責日志數(shù)據(jù)的接收,存儲和轉(zhuǎn)發(fā)舍沙;
- 日志處理應(yīng)用:訂閱并消費kafka隊列中的日志數(shù)據(jù)近上;
以下是新浪kafka日志處理應(yīng)用案例:
轉(zhuǎn)自(http://cloud.51cto.com/art/201507/484338.htm)
(1)Kafka:接收用戶日志的消息隊列。
(2)Logstash:做日志解析场勤,統(tǒng)一成JSON輸出給Elasticsearch戈锻。
(3)Elasticsearch:實時日志分析服務(wù)的核心技術(shù)歼跟,一個schemaless和媳,實時的數(shù)據(jù)存儲服務(wù),通過index組織數(shù)據(jù)哈街,兼具強大的搜索和統(tǒng)計功能留瞳。
(4)Kibana:基于Elasticsearch的數(shù)據(jù)可視化組件,超強的數(shù)據(jù)可視化能力是眾多公司選擇ELK stack的重要原因骚秦。
2.5消息通訊
消息通訊是指她倘,消息隊列一般都內(nèi)置了高效的通信機制,因此也可以用在純的消息通訊作箍。比如實現(xiàn)點對點消息隊列硬梁,或者聊天室等。
點對點通訊:
客戶端A和客戶端B使用同一隊列胞得,進行消息通訊荧止。
聊天室通訊:
客戶端A,客戶端B,客戶端N訂閱同一主題跃巡,進行消息發(fā)布和接收危号。實現(xiàn)類似聊天室效果。
以上實際是消息隊列的兩種消息模式素邪,點對點或發(fā)布訂閱模式外莲。模型為示意圖,供參考兔朦。
三偷线、消息中間件示例
3.1電商系統(tǒng)
消息隊列采用高可用,可持久化的消息中間件沽甥。比如Active MQ淋昭,Rabbit MQ,Rocket Mq安接。(1)應(yīng)用將主干邏輯處理完成后翔忽,寫入消息隊列。消息發(fā)送是否成功可以開啟消息的確認模式盏檐。(消息隊列返回消息接收成功狀態(tài)后歇式,應(yīng)用再返回,這樣保障消息的完整性)
(2)擴展流程(發(fā)短信胡野,配送處理)訂閱隊列消息材失。采用推或拉的方式獲取消息并處理。
(3)消息將應(yīng)用解耦的同時硫豆,帶來了數(shù)據(jù)一致性問題龙巨,可以采用最終一致性方式解決。比如主數(shù)據(jù)寫入數(shù)據(jù)庫熊响,擴展應(yīng)用根據(jù)消息隊列旨别,并結(jié)合數(shù)據(jù)庫方式實現(xiàn)基于消息隊列的后續(xù)處理。
3.2日志收集系統(tǒng)
分為Zookeeper注冊中心汗茄,日志收集客戶端秸弛,Kafka集群和Storm集群(OtherApp)四部分組成。
- Zookeeper注冊中心洪碳,提出負載均衡和地址查找服務(wù)递览;
- 日志收集客戶端,用于采集應(yīng)用系統(tǒng)的日志瞳腌,并將數(shù)據(jù)推送到kafka隊列绞铃;
- Kafka集群:接收,路由嫂侍,存儲儿捧,轉(zhuǎn)發(fā)等消息處理冷离;
Storm集群:與OtherApp處于同一級別,采用拉的方式消費隊列中的數(shù)據(jù)纯命;
四西剥、JMS消息服務(wù)
講消息隊列就不得不提JMS 。JMS(JAVA Message Service,java消息服務(wù))API是一個消息服務(wù)的標準/規(guī)范亿汞,允許應(yīng)用程序組件基于JavaEE平臺創(chuàng)建瞭空、發(fā)送、接收和讀取消息疗我。它使分布式通信耦合度更低咆畏,消息服務(wù)更加可靠以及異步性。
在EJB架構(gòu)中吴裤,有消息bean可以無縫的與JM消息服務(wù)集成旧找。在J2EE架構(gòu)模式中,有消息服務(wù)者模式麦牺,用于實現(xiàn)消息與應(yīng)用直接的解耦钮蛛。
4.1消息模型
在JMS標準中,有兩種消息模型P2P(Point to Point),Publish/Subscribe(Pub/Sub)剖膳。
4.1.1 P2P模式
P2P模式包含三個角色:消息隊列(Queue)魏颓,發(fā)送者(Sender),接收者(Receiver)吱晒。每個消息都被發(fā)送到一個特定的隊列甸饱,接收者從隊列中獲取消息。隊列保留著消息仑濒,直到他們被消費或超時叹话。
P2P的特點
- 每個消息只有一個消費者(Consumer)(即一旦被消費,消息就不再在消息隊列中)
- 發(fā)送者和接收者之間在時間上沒有依賴性墩瞳,也就是說當發(fā)送者發(fā)送了消息之后驼壶,不管接收者有沒有正在運行,它不會影響到消息被發(fā)送到隊列
- 接收者在成功接收消息之后需向隊列應(yīng)答成功
如果希望發(fā)送的每個消息都會被成功處理的話矗烛,那么需要P2P模式辅柴。
4.1.2 Pub/sub模式
包含三個角色主題(Topic),發(fā)布者(Publisher)瞭吃,訂閱者(Subscriber) 。多個發(fā)布者將消息發(fā)送到Topic,系統(tǒng)將這些消息傳遞給多個訂閱者涣旨。
Pub/Sub的特點
- 每個消息可以有多個消費者
- 發(fā)布者和訂閱者之間有時間上的依賴性歪架。針對某個主題(Topic)的訂閱者,它必須創(chuàng)建一個訂閱者之后霹陡,才能消費發(fā)布者的消息和蚪。
- 為了消費消息止状,訂閱者必須保持運行的狀態(tài)。
為了緩和這樣嚴格的時間相關(guān)性攒霹,JMS允許訂閱者創(chuàng)建一個可持久化的訂閱怯疤。這樣,即使訂閱者沒有被激活(運行)催束,它也能接收到發(fā)布者的消息集峦。
如果希望發(fā)送的消息可以不被做任何處理、或者只被一個消息者處理抠刺、或者可以被多個消費者處理的話塔淤,那么可以采用Pub/Sub模型。
4.2消息消費
在JMS中速妖,消息的產(chǎn)生和消費都是異步的高蜂。對于消費來說,JMS的消息者可以通過兩種方式來消費消息罕容。
(1)同步
訂閱者或接收者通過receive方法來接收消息备恤,receive方法在接收到消息之前(或超時之前)將一直阻塞;
(2)異步
訂閱者或接收者可以注冊為一個消息監(jiān)聽器锦秒。當消息到達之后烘跺,系統(tǒng)自動調(diào)用監(jiān)聽器的onMessage方法。
JNDI:Java命名和目錄接口,是一種標準的Java命名系統(tǒng)接口脂崔÷舜荆可以在網(wǎng)絡(luò)上查找和訪問服務(wù)。通過指定一個資源名稱砌左,該名稱對應(yīng)于數(shù)據(jù)庫或命名服務(wù)中的一個記錄脖咐,同時返回資源連接建立所必須的信息。
JNDI在JMS中起到查找和訪問發(fā)送目標或消息來源的作用汇歹。
4.3JMS編程模型
(1) ConnectionFactory
創(chuàng)建Connection對象的工廠屁擅,針對兩種不同的jms消息模型,分別有QueueConnectionFactory和TopicConnectionFactory兩種产弹∨筛瑁可以通過JNDI來查找ConnectionFactory對象。
(2) Destination
Destination的意思是消息生產(chǎn)者的消息發(fā)送目標或者說消息消費者的消息來源痰哨。對于消息生產(chǎn)者來說胶果,它的Destination是某個隊列(Queue)或某個主題(Topic);對于消息消費者來說,它的Destination也是某個隊列或主題(即消息來源)斤斧。
所以早抠,Destination實際上就是兩種類型的對象:Queue、Topic可以通過JNDI來查找Destination撬讽。
(3) Connection
Connection表示在客戶端和JMS系統(tǒng)之間建立的鏈接(對TCP/IP socket的包裝)蕊连。Connection可以產(chǎn)生一個或多個Session悬垃。跟ConnectionFactory一樣,Connection也有兩種類型:QueueConnection和TopicConnection甘苍。
(4) Session
Session是操作消息的接口尝蠕。可以通過session創(chuàng)建生產(chǎn)者载庭、消費者看彼、消息等。Session提供了事務(wù)的功能昧捷。當需要使用session發(fā)送/接收多個消息時闲昭,可以將這些發(fā)送/接收動作放到一個事務(wù)中。同樣靡挥,也分QueueSession和TopicSession序矩。
(5) 消息的生產(chǎn)者
消息生產(chǎn)者由Session創(chuàng)建,并用于將消息發(fā)送到Destination跋破。同樣簸淀,消息生產(chǎn)者分兩種類型:QueueSender和TopicPublisher《痉担可以調(diào)用消息生產(chǎn)者的方法(send或publish方法)發(fā)送消息租幕。
(6) 消息消費者
消息消費者由Session創(chuàng)建,用于接收被發(fā)送到Destination的消息拧簸。兩種類型:QueueReceiver和TopicSubscriber劲绪。可分別通過session的createReceiver(Queue)或createSubscriber(Topic)來創(chuàng)建盆赤。當然贾富,也可以session的creatDurableSubscriber方法來創(chuàng)建持久化的訂閱者。
(7) MessageListener
消息監(jiān)聽器牺六。如果注冊了消息監(jiān)聽器颤枪,一旦消息到達,將自動調(diào)用監(jiān)聽器的onMessage方法淑际。EJB中的MDB(Message-Driven Bean)就是一種MessageListener畏纲。
深入學(xué)習JMS對掌握JAVA架構(gòu),EJB架構(gòu)有很好的幫助春缕,消息中間件也是大型分布式系統(tǒng)必須的組件盗胀。本次分享主要做全局性介紹,具體的深入需要大家學(xué)習淡溯,實踐读整,總結(jié),領(lǐng)會咱娶。
五米间、常用消息隊列
一般商用的容器,比如WebLogic膘侮,JBoss屈糊,都支持JMS標準,開發(fā)上很方便琼了。但免費的比如Tomcat逻锐,Jetty等則需要使用第三方的消息中間件。本部分內(nèi)容介紹常用的消息中間件(Active MQ,Rabbit MQ雕薪,Zero MQ,Kafka)以及他們的特點昧诱。
5.1 ActiveMQ
ActiveMQ 是Apache出品,最流行的所袁,能力強勁的開源消息總線盏档。ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規(guī)范的 JMS Provider實現(xiàn),盡管JMS規(guī)范出臺已經(jīng)是很久的事情了燥爷,但是JMS在當今的J2EE應(yīng)用中間仍然扮演著特殊的地位蜈亩。
ActiveMQ特性如下:
⒈ 多種語言和協(xié)議編寫客戶端。語言: Java,C,C++,C#,Ruby,Perl,Python,PHP前翎。應(yīng)用協(xié)議: OpenWire,Stomp REST,WS Notification,XMPP,AMQP
⒉ 完全支持JMS1.1和J2EE 1.4規(guī)范 (持久化稚配,XA消息,事務(wù))
⒊ 對Spring的支持港华,ActiveMQ可以很容易內(nèi)嵌到使用Spring的系統(tǒng)里面去道川,而且也支持Spring2.0的特性
⒋ 通過了常見J2EE服務(wù)器(如 Geronimo,JBoss 4,GlassFish,WebLogic)的測試,其中通過JCA 1.5 resource adaptors的配置立宜,可以讓ActiveMQ可以自動的部署到任何兼容J2EE 1.4 商業(yè)服務(wù)器上
⒌ 支持多種傳送協(xié)議:in-VM,TCP,SSL,NIO,UDP,JGroups,JXTA
⒍ 支持通過JDBC和journal提供高速的消息持久化
⒎ 從設(shè)計上保證了高性能的集群冒萄,客戶端-服務(wù)器,點對點
⒏ 支持Ajax
⒐ 支持與Axis的整合
⒑ 可以很容易得調(diào)用內(nèi)嵌JMS provider赘理,進行測試
5.2 RabbitMQ
RabbitMQ是流行的開源消息隊列系統(tǒng)宦言,用erlang語言開發(fā)。RabbitMQ是AMQP(高級消息隊列協(xié)議)的標準實現(xiàn)商模。支持多種客戶端奠旺,如:Python、Ruby施流、.NET响疚、Java、JMS瞪醋、C忿晕、PHP、ActionScript银受、XMPP践盼、STOMP等鸦采,支持AJAX,持久化咕幻。用于在分布式系統(tǒng)中存儲轉(zhuǎn)發(fā)消息渔伯,在易用性、擴展性肄程、高可用性等方面表現(xiàn)不俗锣吼。
結(jié)構(gòu)圖如下:
幾個重要概念:
Broker:簡單來說就是消息隊列服務(wù)器實體。
Exchange:消息交換機蓝厌,它指定消息按什么規(guī)則玄叠,路由到哪個隊列。
Queue:消息隊列載體拓提,每個消息都會被投入到一個或多個隊列读恃。
Binding:綁定,它的作用就是把exchange和queue按照路由規(guī)則綁定起來崎苗。
Routing Key:路由關(guān)鍵字狐粱,exchange根據(jù)這個關(guān)鍵字進行消息投遞。
vhost:虛擬主機胆数,一個broker里可以開設(shè)多個vhost肌蜻,用作不同用戶的權(quán)限分離。
producer:消息生產(chǎn)者必尼,就是投遞消息的程序蒋搜。
consumer:消息消費者,就是接受消息的程序判莉。
channel:消息通道豆挽,在客戶端的每個連接里,可建立多個channel券盅,每個channel代表一個會話任務(wù)帮哈。
消息隊列的使用過程,如下:
(1)客戶端連接到消息隊列服務(wù)器锰镀,打開一個channel娘侍。
(2)客戶端聲明一個exchange,并設(shè)置相關(guān)屬性泳炉。
(3)客戶端聲明一個queue憾筏,并設(shè)置相關(guān)屬性。
(4)客戶端使用routing key花鹅,在exchange和queue之間建立好綁定關(guān)系氧腰。
(5)客戶端投遞消息到exchange。
exchange接收到消息后,就根據(jù)消息的key和已經(jīng)設(shè)置的binding古拴,進行消息路由箩帚,將消息投遞到一個或多個隊列里。
5.3 ZeroMQ
號稱史上最快的消息隊列斤富,它實際類似于Socket的一系列接口膏潮,他跟Socket的區(qū)別是:普通的socket是端到端的(1:1的關(guān)系)锻狗,而ZMQ卻是可以N:M 的關(guān)系满力,人們對BSD套接字的了解較多的是點對點的連接,點對點連接需要顯式地建立連接轻纪、銷毀連接油额、選擇協(xié)議(TCP/UDP)和處理錯誤等,而ZMQ屏蔽了這些細節(jié)刻帚,讓你的網(wǎng)絡(luò)編程更為簡單潦嘶。ZMQ用于node與node間的通信,node可以是主機或者是進程崇众。
引用官方的說法: “ZMQ(以下ZeroMQ簡稱ZMQ)是一個簡單好用的傳輸層掂僵,像框架一樣的一個socket library,他使得Socket編程更加簡單顷歌、簡潔和性能更高锰蓬。是一個消息處理隊列庫,可在多個線程眯漩、內(nèi)核和主機盒之間彈性伸縮芹扭。ZMQ的明確目標是“成為標準網(wǎng)絡(luò)協(xié)議棧的一部分,之后進入Linux內(nèi)核”∩舛叮現(xiàn)在還未看到它們的成功舱卡。但是,它無疑是極具前景的队萤、并且是人們更加需要的“傳統(tǒng)”BSD套接字之上的一 層封裝轮锥。ZMQ讓編寫高性能網(wǎng)絡(luò)應(yīng)用程序極為簡單和有趣∫”
特點是:
- 高性能舍杜,非持久化;
- 跨平臺:支持Linux盈电、Windows蝴簇、OS X等。
- 多語言支持匆帚; C熬词、C++、Java、.NET互拾、Python等30多種開發(fā)語言歪今。
- 可單獨部署或集成到應(yīng)用中使用;
- 可作為Socket通信庫使用颜矿。
與RabbitMQ相比寄猩,ZMQ并不像是一個傳統(tǒng)意義上的消息隊列服務(wù)器,事實上骑疆,它也根本不是一個服務(wù)器田篇,更像一個底層的網(wǎng)絡(luò)通訊庫,在Socket API之上做了一層封裝箍铭,將網(wǎng)絡(luò)通訊泊柬、進程通訊和線程通訊抽象為統(tǒng)一的API接口。支持“Request-Reply “诈火,”Publisher-Subscriber“兽赁,”Parallel Pipeline”三種基本模型和擴展模型。
ZeroMQ高性能設(shè)計要點:
1冷守、無鎖的隊列模型
對于跨線程間的交互(用戶端和session)之間的數(shù)據(jù)交換通道pipe刀崖,采用無鎖的隊列算法CAS;在pipe兩端注冊有異步事件拍摇,在讀或者寫消息到pipe的時亮钦,會自動觸發(fā)讀寫事件。
2授翻、批量處理的算法
對于傳統(tǒng)的消息處理或悲,每個消息在發(fā)送和接收的時候,都需要系統(tǒng)的調(diào)用堪唐,這樣對于大量的消息巡语,系統(tǒng)的開銷比較大,zeroMQ對于批量的消息淮菠,進行了適應(yīng)性的優(yōu)化男公,可以批量的接收和發(fā)送消息。
3合陵、多核下的線程綁定枢赔,無須CPU切換
區(qū)別于傳統(tǒng)的多線程并發(fā)模式,信號量或者臨界區(qū)拥知, zeroMQ充分利用多核的優(yōu)勢踏拜,每個核綁定運行一個工作者線程,避免多線程之間的CPU切換開銷低剔。
5.4 Kafka
Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)速梗,它可以處理消費者規(guī)模的網(wǎng)站中的所有動作流數(shù)據(jù)肮塞。 這種動作(網(wǎng)頁瀏覽,搜索和其他用戶的行動)是在現(xiàn)代網(wǎng)絡(luò)上的許多社會功能的一個關(guān)鍵因素姻锁。 這些數(shù)據(jù)通常是由于吞吐量的要求而通過處理日志和日志聚合來解決枕赵。 對于像Hadoop的一樣的日志數(shù)據(jù)和離線分析系統(tǒng),但又要求實時處理的限制位隶,這是一個可行的解決方案拷窜。Kafka的目的是通過Hadoop的并行加載機制來統(tǒng)一線上和離線的消息處理,也是為了通過集群機來提供實時的消費涧黄。
Kafka是一種高吞吐量的分布式發(fā)布訂閱消息系統(tǒng)篮昧,有如下特性:
- 通過O(1)的磁盤數(shù)據(jù)結(jié)構(gòu)提供消息的持久化,這種結(jié)構(gòu)對于即使數(shù)以TB的消息存儲也能夠保持長時間的穩(wěn)定性能弓熏。(文件追加的方式寫入數(shù)據(jù)恋谭,過期的數(shù)據(jù)定期刪除)
- 高吞吐量:即使是非常普通的硬件Kafka也可以支持每秒數(shù)百萬的消息。
- 支持通過Kafka服務(wù)器和消費機集群來分區(qū)消息挽鞠。
- 支持Hadoop并行數(shù)據(jù)加載。
Kafka相關(guān)概念
- Broker
Kafka集群包含一個或多個服務(wù)器狈孔,這種服務(wù)器被稱為broker[5]
- Topic
每條發(fā)布到Kafka集群的消息都有一個類別信认,這個類別被稱為Topic。(物理上不同Topic的消息分開存儲均抽,邏輯上一個Topic的消息雖然保存于一個或多個broker上但用戶只需指定消息的Topic即可生產(chǎn)或消費數(shù)據(jù)而不必關(guān)心數(shù)據(jù)存于何處)
- Partition
Parition是物理上的概念嫁赏,每個Topic包含一個或多個Partition.
- Producer
負責發(fā)布消息到Kafka broker
- Consumer
消息消費者,向Kafka broker讀取消息的客戶端油挥。
- Consumer Group
每個Consumer屬于一個特定的Consumer Group(可為每個Consumer指定group name潦蝇,若不指定group name則屬于默認的group)。
一般應(yīng)用在大數(shù)據(jù)日志處理或?qū)崟r性(少量延遲)深寥,可靠性(少量丟數(shù)據(jù))要求稍低的場景使用攘乒。
3. 參考
(1)JMS
http://blog.sina.com.cn/s/blog_3fba24680100r777.html
http://blog.csdn.net/jiuqiyuliang/article/details/46701559(深入淺出JMS(一)--JMS基本概念)
(2) RabbitMQ
http://baike.baidu.com/link?url=s2cU-QgOsXan7j0AM5qxxlmruz6WEeBQXX-Bbk0O3F5jt9Qts2uYQARxQxl7CBT2SO2NF2VkzX_XZLqU-CTaPa
http://blog.csdn.net/sun305355024sun/article/details/41913105
(3) Zero MQ
http://www.searchtb.com/2012/08/zeromq-primer.html
http://blog.csdn.net/yangbutao/article/details/8498790
http://wenku.baidu.com/link?url=yYoiZ_pYPCuUxEsGQvMMleY08bcptZvwF3IMHo2W1i-ti66YXXPpLLJBGXboddwgGBnOehHiUdslFhtz7RGZYkrtMQQ02DV5sv9JFF4LZnK
(4) KAFKA
http://baike.baidu.com/link?url=qQXyqvPQ1MVrw9WkOGSGEfSX1NHy4unsgc4ezzJwU94SrPuVnrKf2tbm4SllVaN3ArGGxV_N5hw8JTT2-lw4QK
http://www.infoq.com/cn/articles/apache-kafka/
http://www.mincoder.com/article/3942.shtml
(5) 一文詳解消息隊列的常見功能場景與使用精髓
王新棟 DBAplus社群
https://mp.weixin.qq.com/s/k_ziqIBKZQpcyEirV_U5ng
(6)分布式事務(wù)解決方案常見誤區(qū)與實用建議
Throwable DBAplus社群
https://mp.weixin.qq.com/s/yaPrpekN3B0Ro3ggoVFFeg
(7)分布式消息隊列差異化總結(jié),太全了惋鹅!
作者:28cm不含頭
https://mp.weixin.qq.com/s/FKibIkZNZG0yNT2EAmGIHA