來源：https://www.cnblogs.com/bainianminguo/p/12247158.html
標(biāo)題：kafka概念掃盲
作者：bainianminguo
一巩趁、kafka概述
1.1、定義
Kakfa是一個分布式的基于發(fā)布/訂閱模式的消息隊(duì)列（message queue）淳附，主要應(yīng)用于大數(shù)據(jù)的實(shí)時處理領(lǐng)域
1.2议慰、消息隊(duì)列
1.2.1、傳統(tǒng)的消息隊(duì)列&新式的消息隊(duì)列的模式
上面是傳統(tǒng)的消息隊(duì)列燃观，比如一個用戶要注冊信息褒脯，當(dāng)用戶信息寫入數(shù)據(jù)庫后，后面還有一些其他流程缆毁，比如發(fā)送短信番川，則需要等這些流程處理完成后，在返回給用戶
而新式的隊(duì)列是脊框，比如一個用戶注冊信息颁督，數(shù)據(jù)直接丟進(jìn)數(shù)據(jù)庫，就直接返回給用戶成功
1.2.2浇雹、使用消息隊(duì)列的好處
A沉御、 解耦
B、 可恢復(fù)性
C昭灵、 緩沖
D吠裆、 靈活性&峰值處理能力
E、 異步通信
1.2.3烂完、消息隊(duì)列的模式
A试疙、點(diǎn)對點(diǎn)模式
消息生產(chǎn)者發(fā)送消息到消息隊(duì)列中，然后消息消費(fèi)者從隊(duì)列中取出并且消費(fèi)消息抠蚣，消息被消費(fèi)后祝旷，隊(duì)列中不在存儲。所以消息消費(fèi)者不可能消費(fèi)到已經(jīng)被消費(fèi)的消息；隊(duì)列支持存在多個消費(fèi)者怀跛，但是對于一個消息而言距贷，只會
有一個消費(fèi)者可以消費(fèi)；如果想發(fā)給多個消費(fèi)者吻谋，則需要多次發(fā)送該條消息
B】發(fā)布/訂閱模式（一對多忠蝗，消費(fèi)者消費(fèi)數(shù)據(jù)之后不會清除消息）
消息生產(chǎn)者將消息發(fā)布到topic中，同時有多個消息消費(fèi)者（訂閱）消費(fèi)該消息滨溉，和點(diǎn)對點(diǎn)的方式不同什湘，發(fā)布到topic的消息會被所有的訂閱者消費(fèi)；但是數(shù)據(jù)保留是期限的晦攒，默認(rèn)是7天，因?yàn)樗皇谴鎯ο到y(tǒng)得哆；kafka就是這種模式的脯颜；有兩種方式，一種是是消費(fèi)者去主動去消費(fèi)（拉确肪荨）消息栋操，而不是生產(chǎn)者推送消息給消費(fèi)者；另外一種就是生產(chǎn)者主動推送消息給消費(fèi)者饱亮，類似公眾號
1.3矾芙、kafka的基礎(chǔ)架構(gòu)
kafka的基礎(chǔ)架構(gòu)主要有broker、生產(chǎn)者近上、消費(fèi)者組構(gòu)成剔宪，當(dāng)前還包括zookeeper
生產(chǎn)者負(fù)責(zé)發(fā)送消息
broker負(fù)責(zé)緩沖消息，broker中可以創(chuàng)建topic壹无，每個topic又有partition和replication的概念
消費(fèi)者組負(fù)責(zé)處理消息葱绒，同一個消費(fèi)者組的中消費(fèi)者不能消費(fèi)同一個partition中的數(shù)據(jù)，消費(fèi)者組主要是提高消費(fèi)能力斗锭，比如之前是一個消費(fèi)者消費(fèi)100條數(shù)據(jù)地淀，現(xiàn)在是2個消費(fèi)者消費(fèi)100條數(shù)據(jù)，可以提高消費(fèi)能力岖是；所以消費(fèi)者組的消費(fèi)者的個數(shù)要小于partition的個數(shù)帮毁，不然就會有消費(fèi)者沒有partition可以消費(fèi)，造成資源的浪費(fèi)
注：但是不同的消費(fèi)者組的消費(fèi)者是可以消費(fèi)相同的partition數(shù)據(jù)
Kakfa如果要組件集群豺撑，則只需要注冊到一個zk中就可以了烈疚，zk中還保留消息消費(fèi)的進(jìn)度或者說偏移量或者消費(fèi)位置
0.9版本之前偏移量存儲在zk
0.9版本之后偏移量存儲在kafka中，kafka定義了一個系統(tǒng)的topic前硫，專用用來存儲偏移量的數(shù)據(jù)胞得；
為什么要改？主要是考慮到頻繁更改偏移量，對zk 的壓力較大阶剑，而且kafka 本身自己的處理也較復(fù)雜
1.4跃巡、kafka安裝
A、Kafka的安裝只需要解壓安裝包就可以完成安裝
tar -zxvf kafka_2.11-2.1.1.tgz -C /usr/local/
B牧愁、查看配置文件
[root@es1 config]# pwd
/usr/local/kafka/config
[root@es1 config]# ll
total 84
-rw-r--r--. 1 root root 906 Feb 8 2019 connect-console-sink.properties
-rw-r--r--. 1 root root 909 Feb 8 2019 connect-console-source.properties
-rw-r--r--. 1 root root 5321 Feb 8 2019 connect-distributed.properties
-rw-r--r--. 1 root root 883 Feb 8 2019 connect-file-sink.properties
-rw-r--r--. 1 root root 881 Feb 8 2019 connect-file-source.properties
-rw-r--r--. 1 root root 1111 Feb 8 2019 connect-log4j.properties
-rw-r--r--. 1 root root 2262 Feb 8 2019 connect-standalone.properties
-rw-r--r--. 1 root root 1221 Feb 8 2019 consumer.properties
-rw-r--r--. 1 root root 4727 Feb 8 2019 log4j.properties
-rw-r--r--. 1 root root 1925 Feb 8 2019 producer.properties
-rw-r--r--. 1 root root 6865 Jan 16 22:00 server-1.properties
-rw-r--r--. 1 root root 6865 Jan 16 22:00 server-2.properties
-rw-r--r--. 1 root root 6873 Jan 16 03:57 server.properties
-rw-r--r--. 1 root root 1032 Feb 8 2019 tools-log4j.properties
-rw-r--r--. 1 root root 1169 Feb 8 2019 trogdor.conf
-rw-r--r--. 1 root root 1023 Feb 8 2019 zookeeper.properties
C素邪、修改配置文件server.properties
設(shè)置broker.id 這個是kafka集群區(qū)分每個節(jié)點(diǎn)的唯一標(biāo)志符
D、設(shè)置kafka的數(shù)據(jù)存儲路徑
注：這個目錄下不能有其他非kafka的目錄猪半，不然會導(dǎo)致kafka集群無法啟動
E兔朦、設(shè)置是否可以刪除topic，默認(rèn)情況先kafka的topic是不允許刪除的
F磨确、Kafka的數(shù)據(jù)保留的時間沽甥，默認(rèn)是7天
G、Log文件最大的大小乏奥，如果log文件超過1g會創(chuàng)建一個新的文件
H摆舟、Kafka連接的zk的地址和連接kafka的超時時間
J、默認(rèn)的partition的個數(shù)
1.5邓了、啟動kafka
A恨诱、啟動方式1，kafka只能單節(jié)點(diǎn)啟動骗炉，所以每個kakfa節(jié)點(diǎn)都需要手動啟動照宝，下面的方式阻塞的方式啟動
B、啟動方式2句葵，守護(hù)的方式啟動厕鹃，推薦
1.6、kafka操作
A笼呆、查看當(dāng)前kafka集群已有的topic
注意：這里連接的zookeeper熊响，而不是連接的kafka
B、創(chuàng)建topic诗赌，指定分片和副本個數(shù)
注：
replication-factor：副本數(shù)
replication-factor：分區(qū)數(shù)
Topic：主題名
如果當(dāng)前kafka集群只有3個broker節(jié)點(diǎn)汗茄，則replication-factor最大就是3了，下面的例子創(chuàng)建副本為4铭若，則會報錯
C洪碳、刪除topic
D、查看topic信息
1.7叼屠、啟動生產(chǎn)者生產(chǎn)消息瞳腌，kafka自帶一個生產(chǎn)者和消費(fèi)者的客戶端
A、啟動一個生產(chǎn)者镜雨，注意此時連的9092端口嫂侍，連接的kafka集群
B、啟動一個消費(fèi)者，注意此時連接的還是9092端口挑宠，在0.9版本之前連接的還是2181端口
這里我們啟動2個消費(fèi)者來測試一下
注：如果不指定的消費(fèi)者組的配置文件的話菲盾，默認(rèn)每個消費(fèi)者都屬于不同的消費(fèi)者組
C、發(fā)送消息各淀，可以看到每個消費(fèi)者都能收到消息
D懒鉴、Kakfa中的實(shí)際的數(shù)據(jù)
二、kafka架構(gòu)深入
Kafka不能保證消息的全局有序碎浇，只能保證消息在partition內(nèi)有序临谱，因?yàn)橄M(fèi)者消費(fèi)消息是在不同的partition中隨機(jī)的
2.1、kafka的工作流程
Kafka中的消息是以topic進(jìn)行分類的奴璃，生產(chǎn)者生成消息悉默，消費(fèi)者消費(fèi)消息，都是面向topic的
Topic是一個邏輯上的概念溺健，而partition是物理上的概念
每個partition又有副本的概念
每個partition對應(yīng)于一個log文件麦牺，該log文件中存儲的就是生產(chǎn)者生成的數(shù)據(jù)，生產(chǎn)者生成的數(shù)據(jù)會不斷的追加到該log的文件末端鞭缭，且每條數(shù)據(jù)都有自己的offset，消費(fèi)者都會實(shí)時記錄自己消費(fèi)到了那個offset魏颓，以便出錯的時候從上次的位置繼續(xù)消費(fèi)岭辣，這個offset就保存在index文件中
kafka的offset是分區(qū)內(nèi)有序的，但是在不同分區(qū)中是無順序的甸饱，kafka不保證數(shù)據(jù)的全局有序
2.2沦童、kafka原理
由于生產(chǎn)者生產(chǎn)的消息會不斷追加到log文件的末尾，為防止log文件過大導(dǎo)致數(shù)據(jù)定位效率低下叹话，Kafka采用分片和索引的機(jī)制偷遗，將每個partition分為多個segment，每個segment對應(yīng)2個文件
----index文件和log文件驼壶，這2個文件位于一個相同的文件夾下氏豌，文件夾的命名規(guī)則為topic名稱+分區(qū)序號
Indx和log的文件的文件名是當(dāng)前這個索引是最小的數(shù)據(jù)的offset
Kafka如何快速的消費(fèi)數(shù)據(jù)呢？
Index文件中存儲的數(shù)據(jù)的索引信息热凹，第一列是offset泵喘，第二列這這個數(shù)據(jù)所對應(yīng)的log文件中的偏移量，就像我們?nèi)プx文件般妙，使用seek（）設(shè)置當(dāng)前鼠標(biāo)的位置一樣纪铺，可以更快的找到數(shù)據(jù)
如果要去消費(fèi)offset為3的數(shù)據(jù)，首先通過二分法找到數(shù)據(jù)在哪個index文件中碟渺，然后在通過index中offset找到數(shù)據(jù)在log文件中的offset鲜锚；這樣就可以快速的定位到數(shù)據(jù)，并消費(fèi)
所以kakfa雖然把數(shù)據(jù)存儲在磁盤中，但是他的讀取速度還是非澄叻保快的
三旺隙、kafka的生產(chǎn)者和消費(fèi)者
3.1、kafka的生產(chǎn)者
Kafka的partition的分區(qū)的作用
Kafka的分區(qū)的原因主要就是提供并發(fā)提高性能浆洗，因?yàn)樽x寫是partition為單位讀寫的催束；
那生產(chǎn)者發(fā)送消息是發(fā)送到哪個partition中呢？
A伏社、在客戶端中指定partition
B抠刺、輪詢（推薦）消息1去p1，消息2去p2摘昌，消息3去p3速妖，消息4去p1，消息5去p2聪黎，消息6去p3 罕容。。稿饰。锦秒。。喉镰。旅择。
3.2 kafka如何保證數(shù)據(jù)可靠性呢？通過ack來保證
為保證生產(chǎn)者發(fā)送的數(shù)據(jù)侣姆，能可靠的發(fā)送到指定的topic生真，topic的每個partition收到生產(chǎn)者發(fā)送的數(shù)據(jù)后，都需要向生產(chǎn)者發(fā)送ack（確認(rèn)收到），如果生產(chǎn)者收到ack，就會進(jìn)行下一輪的發(fā)送惜傲，否則重新發(fā)送數(shù)據(jù)
那么kafka什么時候向生產(chǎn)者發(fā)送ack
確保follower和leader同步完成话速，leader在發(fā)送ack給生產(chǎn)者，這樣才能確保leader掛掉之后，能再follower中選舉出新的leader后，數(shù)據(jù)不會丟失
那多少個follower同步完成后發(fā)送ack
方案1：半數(shù)已經(jīng)完成同步，就發(fā)送ack
方案2：全部完成同步痰哨，才發(fā)送ack（kafka采用這種方式）
采用第二種方案后，設(shè)想以下場景匾嘱，leader收到數(shù)據(jù)斤斧，所有的follower都開始同步數(shù)據(jù)，但是有一個follower因?yàn)槟撤N故障霎烙，一直無法完成同步撬讽，那leader就要一直等下蕊连，直到他同步完成，才能發(fā)送ack游昼，這樣就非常影響效率甘苍，這個問題怎么解決？
Leader維護(hù)了一個動態(tài)的ISR列表（同步副本的作用）烘豌，只需要這個列表的中的follower和leader同步载庭；當(dāng)ISR中的follower完成數(shù)據(jù)的同步之后，leader就會給生產(chǎn)者發(fā)送ack廊佩，如果follower長時間未向leader同步數(shù)據(jù)囚聚，則該follower將被剔除ISR，這個時間閾值也是自定義的标锄；同樣leader故障后顽铸，就會從ISR中選舉新的leader
怎么選擇ISR的節(jié)點(diǎn)呢？
首先通信的時間要快料皇，要和leader要可以很快的完成通信谓松，這個時間默認(rèn)是10s
然后就看leader數(shù)據(jù)差距，消息條數(shù)默認(rèn)是10000條（后面版本被移除）
為什么移除：因?yàn)閗afka發(fā)送消息是批量發(fā)送的践剂，所以會一瞬間leader接受完成鬼譬，但是follower還沒有拉取，所以會頻繁的踢出加入ISR逊脯，這個數(shù)據(jù)會保存到zk和內(nèi)存中拧簸，所以會頻繁的更新zk和內(nèi)存。
但是對于某些不太重要的數(shù)據(jù)男窟，對數(shù)據(jù)的可靠性要求不是很高，能夠容忍數(shù)據(jù)的少量丟失贾富，所以沒必要等ISR中的follower全部接受成功
所以kafka為用戶提供了三種可靠性級別歉眷，用戶可以根據(jù)可靠性和延遲進(jìn)行權(quán)衡，這個設(shè)置在kafka的生成中設(shè)置：acks參數(shù)設(shè)置
A颤枪、acks為0
生產(chǎn)者不等ack汗捡，只管往topic丟數(shù)據(jù)就可以了，這個丟數(shù)據(jù)的概率非常高
B畏纲、ack為1
Leader落盤后就會返回ack扇住，會有數(shù)據(jù)丟失的現(xiàn)象，如果leader在同步完成后出現(xiàn)故障盗胀，則會出現(xiàn)數(shù)據(jù)丟失
C艘蹋、ack為-1（all）
Leader和follower（ISR）落盤才會返回ack，會有數(shù)據(jù)重復(fù)現(xiàn)象票灰，如果在leader已經(jīng)寫完成女阀，且follower同步完成宅荤，但是在返回ack的出現(xiàn)故障，則會出現(xiàn)數(shù)據(jù)重復(fù)現(xiàn)象浸策；極限情況下冯键，這個也會有數(shù)據(jù)丟失的情況，比如follower和leader通信都很慢庸汗，所以ISR中只有一個leader節(jié)點(diǎn)惫确，這個時候，leader完成落盤蚯舱，就會返回ack改化，如果此時leader故障后，就會導(dǎo)致丟失數(shù)據(jù)
3.3 Kafka如何保證消費(fèi)數(shù)據(jù)的一致性晓淀？通過HW來保證
LEO：指每個follower的最大的offset
HW（高水位）：指消費(fèi)者能見到的最大的offset所袁，LSR隊(duì)列中最小的LEO，也就是說消費(fèi)者只能看到1~6的數(shù)據(jù)凶掰，后面的數(shù)據(jù)看不到燥爷，也消費(fèi)不了
避免leader掛掉后，比如當(dāng)前消費(fèi)者消費(fèi)8這條數(shù)據(jù)后懦窘，leader掛
了前翎，此時比如f2成為leader，f2根本就沒有9這條數(shù)據(jù)畅涂，那么消費(fèi)者就會報錯港华，所以設(shè)計(jì)了HW這個參數(shù)，只暴露最少的數(shù)據(jù)給消費(fèi)者午衰，避免上面的問題
3.3.1立宜、HW保證數(shù)據(jù)存儲的一致性
A、Follower故障
Follower發(fā)生故障后會被臨時提出LSR臊岸，待該follower恢復(fù)后橙数，follower會讀取本地的磁盤記錄的上次的HW，并將該log文件高于HW的部分截取掉帅戒，從HW開始想leader進(jìn)行同步灯帮，等該follower的LEO大于等于該P(yáng)artition的hw，即follower追上leader后逻住，就可以重新加入LSR
B钟哥、Leader故障
Leader發(fā)生故障后，會從ISR中選出一個新的leader瞎访，之后腻贰，為了保證多個副本之間的數(shù)據(jù)一致性，其余的follower會先將各自的log文件高于hw的部分截掉（新leader自己不會截掉）装诡，然后從新的leader同步數(shù)據(jù)
注意：這個是為了保證多個副本間的數(shù)據(jù)存儲的一致性银受，并不能保證數(shù)據(jù)不丟失或者不重復(fù)
3.3.2精準(zhǔn)一次（冪等性）践盼，保證數(shù)據(jù)不重復(fù)
Ack設(shè)置為-1，則可以保證數(shù)據(jù)不丟失宾巍，但是會出現(xiàn)數(shù)據(jù)重復(fù)（at least once）
Ack設(shè)置為0咕幻，則可以保證數(shù)據(jù)不重復(fù)，但是不能保證數(shù)據(jù)不丟失（at most once）
但是如果魚和熊掌兼得顶霞，該怎么辦肄程？這個時候就就引入了Exactl once（精準(zhǔn)一次）
在0.11版本后，引入冪等性解決kakfa集群內(nèi)部的數(shù)據(jù)重復(fù)选浑，在0.11版本之前蓝厌，在消費(fèi)者處自己做處理
如果啟用了冪等性，則ack默認(rèn)就是-1古徒，kafka就會為每個生產(chǎn)者分配一個pid拓提，并未每條消息分配seqnumber，如果pid隧膘、partition代态、seqnumber三者一樣，則kafka認(rèn)為是重復(fù)數(shù)據(jù)疹吃，就不會落盤保存蹦疑；但是如果生產(chǎn)者掛掉后，也會出現(xiàn)有數(shù)據(jù)重復(fù)的現(xiàn)象萨驶；所以冪等性解決在單次會話的單個分區(qū)的數(shù)據(jù)重復(fù)歉摧，但是在分區(qū)間或者跨會話的是數(shù)據(jù)重復(fù)的是無法解決的
3.4 kafka的消費(fèi)者
3.4.1 消費(fèi)方式
消息隊(duì)列有兩種消費(fèi)消息的方式，push（微信公眾號）腔呜、pull（kafka）叁温，push模式很難適應(yīng)消費(fèi)速率不同的消費(fèi)者，因?yàn)橄M(fèi)發(fā)送速率是由broker決定的核畴，他的目標(biāo)是盡可能以最快的的速度傳遞消息券盅，但是這樣很容易造成消費(fèi)者來不及處理消息，典型的表現(xiàn)就是拒絕服務(wù)以及網(wǎng)絡(luò)擁塞膛檀。而pull的方式可以消費(fèi)者的消費(fèi)能力以適當(dāng)?shù)乃俾氏M(fèi)消息
Pull的模式不足之處是如果kafka沒有數(shù)據(jù)，消費(fèi)者可能會陷入死循環(huán)娘侍，一直返回空數(shù)據(jù)咖刃，針對這一點(diǎn)，kafka的消費(fèi)者在消費(fèi)數(shù)據(jù)時候回傳遞一個timeout參數(shù)憾筏，如果當(dāng)時沒有數(shù)據(jù)可供消費(fèi)嚎杨，消費(fèi)者會等待一段時間在返回
3.4.2 分區(qū)分配策略
一個消費(fèi)者組有多個消費(fèi)者，一個topic有多個partition氧腰。所以必然會涉及到partition的分配問題枫浙，即確定哪個partition由哪個消費(fèi)者來消費(fèi)
Kafka提供兩種方式刨肃，一種是輪詢（RountRobin）對于topic組生效，一種是（Range）對于單個topic生效
輪訓(xùn)：前置條件是需要一個消費(fèi)者里的消費(fèi)者訂閱的是相同的topic箩帚。不然就會出現(xiàn)問題真友；非默認(rèn)的的方式
同一個消費(fèi)者組里的消費(fèi)者不能同時消費(fèi)同一個分區(qū)
比如三個消費(fèi)者消費(fèi)一個topic的9個分區(qū)
如果一個消費(fèi)者組里有2個消費(fèi)者，這個消費(fèi)者組里同時消費(fèi)2個topic紧帕，每個topic又有三個partition
首先會把2個topic當(dāng)做一個主題盔然，然后根據(jù)topic和partition做hash，然后在按照hash排序是嗜。然后輪訓(xùn)分配給一個消費(fèi)者組中的2個消費(fèi)者
如果是下面這樣的方式訂閱的呢愈案？
比如有3個topic，每個topic有3個partition鹅搪，一個消費(fèi)者組中有2個消費(fèi)者站绪。消費(fèi)者1訂閱topic1和topic2，消費(fèi)者2訂閱topic2和topic3丽柿，那么這樣的場景恢准，使用輪訓(xùn)的方式訂閱topic就會有問題
如果是下面這種方式訂閱呢
比如有2個topic，每個topic有3個partition航厚，一個消費(fèi)者組
有2個消費(fèi)者顷歌，消費(fèi)者1訂閱topic1，消費(fèi)者2訂閱topic2幔睬，這樣使用輪訓(xùn)的方式訂閱topic也會有問題
所以我們一直強(qiáng)調(diào)眯漩，使用輪訓(xùn)的方式訂閱topic的前提是一個消費(fèi)者組中的所有消費(fèi)者訂閱的主題是一樣的；
所以輪訓(xùn)的方式不是kafka默認(rèn)的方式
Range：是按照單個topic來劃分的麻顶，默認(rèn)的分配方式
Range的問題會出現(xiàn)消費(fèi)者數(shù)據(jù)不均衡的問題
比如下面的例子赦抖，一個消費(fèi)者組訂閱了2個topic，就會出現(xiàn)消費(fèi)者1消費(fèi)4個partition辅肾，而另外一個消費(fèi)者只消費(fèi)2個partition
分區(qū)策略什么時候會觸發(fā)呢队萤？當(dāng)消費(fèi)者組里的消費(fèi)者個數(shù)變化的時候，會觸發(fā)分區(qū)策略調(diào)整矫钓，比如消費(fèi)者里增加消費(fèi)者要尔，或者減少消費(fèi)者
3.4.3 offset的維護(hù)
由于消費(fèi)者在消費(fèi)過程中可能會出現(xiàn)斷電宕機(jī)等故障，消費(fèi)者恢復(fù)后新娜，需要從故障前的位置繼續(xù)消費(fèi)赵辕，所以消費(fèi)者需要實(shí)施記錄自己消費(fèi)哪個offset，以便故障恢復(fù)后繼續(xù)消費(fèi)
Offset保存的位置有2個概龄，一個zk还惠，一個是kafka
首先看下offset保存到zk
由消費(fèi)者組、topic私杜、partition三個元素確定唯一的offset
所以消費(fèi)者組中的某個消費(fèi)者掛掉之后蚕键，或者的消費(fèi)者還是可以拿到這個offset的
Controller這個節(jié)點(diǎn)和zk通信救欧，同步數(shù)據(jù)，這個節(jié)點(diǎn)就是誰先起來锣光，誰就先注冊controller笆怠，誰就是controller。其他節(jié)點(diǎn)和controller信息保持同步
3.4.5嫉晶、消費(fèi)者組的案例
修改消費(fèi)者組id
啟動一個消費(fèi)者發(fā)送3條數(shù)據(jù)
指定消費(fèi)者組啟動消費(fèi)者骑疆，啟動三個消費(fèi)者，可以看到每個消費(fèi)者消費(fèi)了一條數(shù)據(jù)
在演示下不同組可以消費(fèi)同一個topic的替废，我們看到2個消費(fèi)者的消費(fèi)者都消費(fèi)到同一條數(shù)據(jù)
再次啟動一個消費(fèi)者箍铭，這個消費(fèi)者屬于另外一個消費(fèi)者組
四、Kafka的高效讀寫機(jī)制
4.1椎镣、分布式部署
多節(jié)點(diǎn)并行操作
4.2诈火、順序?qū)懘疟P
Kafka的producer生產(chǎn)數(shù)據(jù)，要寫入到log文件中状答，寫的過程中一直追加到文件末尾冷守，為順序?qū)懀倬W(wǎng)有數(shù)據(jù)表明惊科。同樣的磁盤拍摇，順序?qū)懩艿?00M/S，而隨機(jī)寫只有100K/S馆截。這與磁盤的機(jī)械結(jié)構(gòu)有關(guān)充活，順序?qū)懼钥欤且驗(yàn)槠涫∪チ舜罅看蓬^尋址的時間
4.3蜡娶、零復(fù)制技術(shù)
正常情況下混卵，先把數(shù)據(jù)讀到內(nèi)核空間，在從內(nèi)核空間把數(shù)據(jù)讀到用戶空間窖张，然后在調(diào)操作系統(tǒng)的io接口寫到內(nèi)核空間幕随，最終在寫到硬盤中
Kafka是這樣做的，直接在內(nèi)核空間流轉(zhuǎn)io流宿接，所以kafka的性能非常高
五赘淮、 zookeeper在kafka中的作用
Kafka集群中有一個broker會被選舉為controller，負(fù)責(zé)管理集群broker的上下線睦霎，所有的topic的分區(qū)副本分配和leader選舉等工作
