個人專題目錄
1. Kafka生產(chǎn)過程分析
參考Kafka架構(gòu)
寫入方式
producer采用推（push）模式將消息發(fā)布到broker，每條消息都被追加（append）到分區(qū)（patition）中龄句，屬于順序?qū)懘疟P（順序?qū)懘疟P效率比隨機寫內(nèi)存要高，保障kafka吞吐率）。
分區(qū)（Partition）
消息發(fā)送時都被發(fā)送到一個topic旨袒，其本質(zhì)就是一個目錄，而topic是由一些Partition Logs(分區(qū)日志)組成术辐，其組織結(jié)構(gòu)如下圖所示：
可以看到砚尽，每個Partition中的消息都是有序的，生產(chǎn)的消息被不斷追加到Partition log上辉词，其中的每一個消息都被賦予了一個唯一的offset值必孤。
-
分區(qū)的原因
- 方便在集群中擴展，每個Partition可以通過調(diào)整以適應(yīng)它所在的機器瑞躺，而一個topic又可以有多個Partition組成敷搪，因此整個集群就可以適應(yīng)任意大小的數(shù)據(jù)了；
- 可以提高并發(fā)幢哨，因為可以以Partition為單位讀寫了赡勘。
-
分區(qū)的原則
- 指定了patition，則直接使用捞镰；
- 未指定patition但指定key闸与，通過對key的value進行hash出一個patition；
- patition和key都未指定岸售，使用輪詢選出一個patition践樱。
副本（Replication）
同一個partition可能會有多個replication（對應(yīng) server.properties 配置中的 default.replication.factor=N）。沒有replication的情況下凸丸，一旦broker 宕機拷邢，其上所有 patition 的數(shù)據(jù)都不可被消費，同時producer也不能再將數(shù)據(jù)存于其上的patition屎慢。引入replication之后瞭稼，同一個partition可能會有多個replication，而這時需要在這些replication之間選出一個leader腻惠，producer和consumer只與這個leader交互弛姜，其它replication作為follower從leader 中復(fù)制數(shù)據(jù)。
寫入流程
producer寫入消息流程如下：
- producer先從zookeeper的 "/brokers/.../state"節(jié)點找到該partition的leader
- producer將消息發(fā)送給該leader
- leader將消息寫入本地log
- followers從leader pull消息妖枚，寫入本地log后向leader發(fā)送ACK
- leader收到所有ISR中的replication的ACK后廷臼，增加HW（high watermark，最后commit 的offset）并向producer發(fā)送ACK
2. Broker 保存消息
存儲方式
物理上把topic分成一個或多個patition（對應(yīng) server.properties 中的num.partitions=3配置），每個patition物理上對應(yīng)一個文件夾（該文件夾存儲該patition的所有消息和索引文件）荠商。
存儲策略
無論消息是否被消費寂恬，kafka都會保留所有消息。有兩種策略可以刪除舊數(shù)據(jù)：
- 基于時間：log.retention.hours=168
- 基于大欣趁弧：log.retention.bytes=1073741824
需要注意的是初肉，因為Kafka讀取特定消息的時間復(fù)雜度為O(1)，即與文件大小無關(guān)饰躲，所以這里刪除過期文件與提高 Kafka 性能無關(guān)牙咏。
Zookeeper存儲結(jié)構(gòu)
注意：producer不在zk中注冊，消費者在zk中注冊嘹裂。
3. Kafka消費過程分析
kafka提供了兩套consumer API：高級Consumer API和低級Consumer API妄壶。
高級API
- 高級API優(yōu)點
高級API 寫起來簡單
不需要自行去管理offset，系統(tǒng)通過zookeeper自行管理寄狼。
不需要管理分區(qū)丁寄，副本等情況，系統(tǒng)自動管理泊愧。
消費者斷線會自動根據(jù)上一次記錄在zookeeper中的offset去接著獲取數(shù)據(jù)（默認設(shè)置1分鐘更新一下zookeeper中存的offset）
可以使用group來區(qū)分對同一個topic 的不同程序訪問分離開來（不同的group記錄不同的offset伊磺，這樣不同程序讀取同一個topic才不會因為offset互相影響）
- 高級API缺點
不能自行控制offset（對于某些特殊需求來說）
不能細化控制如分區(qū)、副本删咱、zk等
低級API
- 低級 API 優(yōu)點
能夠讓開發(fā)者自己控制offset屑埋，想從哪里讀取就從哪里讀取。
自行控制連接分區(qū)痰滋，對分區(qū)自定義進行負載均衡
對zookeeper的依賴性降低（如：offset不一定非要靠zk存儲摘能，自行存儲offset即可，比如存在文件或者內(nèi)存中）
- 低級API缺點
太過復(fù)雜即寡，需要自行控制offset徊哑，連接哪個分區(qū)袜刷，找到分區(qū)leader 等聪富。
消費者組
消費者是以consumer group消費者組的方式工作，由一個或者多個消費者組成一個組著蟹，共同消費一個topic墩蔓。每個分區(qū)在同一時間只能由group中的一個消費者讀取，但是多個group可以同時消費這個partition萧豆。在圖中奸披，有一個由三個消費者組成的group，有一個消費者讀取主題中的兩個分區(qū)涮雷，另外兩個分別讀取一個分區(qū)阵面。某個消費者讀取某個分區(qū)，也可以叫做某個消費者是某個分區(qū)的擁有者。
在這種情況下样刷，消費者可以通過水平擴展的方式同時讀取大量的消息仑扑。另外，如果一個消費者失敗了置鼻，那么其他的group成員會自動負載均衡讀取之前失敗的消費者讀取的分區(qū)镇饮。
消費方式
consumer采用pull（拉）模式從broker中讀取數(shù)據(jù)。
push（推）模式很難適應(yīng)消費速率不同的消費者箕母，因為消息發(fā)送速率是由broker決定的储藐。它的目標是盡可能以最快速度傳遞消息，但是這樣很容易造成consumer來不及處理消息嘶是，典型的表現(xiàn)就是拒絕服務(wù)以及網(wǎng)絡(luò)擁塞钙勃。而pull模式則可以根據(jù)consumer的消費能力以適當?shù)乃俾氏M消息。
對于Kafka而言俊啼，pull模式更合適肺缕，它可簡化broker的設(shè)計，consumer可自主控制消費消息的速率授帕，同時consumer可以自己控制消費方式——即可批量消費也可逐條消費同木，同時還能選擇不同的提交方式從而實現(xiàn)不同的傳輸語義。
pull模式不足之處是跛十，如果kafka沒有數(shù)據(jù)彤路，消費者可能會陷入循環(huán)中，一直等待數(shù)據(jù)到達芥映。為了避免這種情況洲尊，我們在我們的拉請求中有參數(shù)，允許消費者請求在等待數(shù)據(jù)到達的“長輪詢”中進行阻塞（并且可選地等待到給定的字節(jié)數(shù)奈偏，以確保大的傳輸大形豚帧）。
消費者組案例
1）需求：測試同一個消費者組中的消費者惊来，同一時刻只能有一個消費者消費丽涩。
2）案例
（1）在hadoop102、hadoop103上修改/opt/module/kafka/config/consumer.properties配置文件中的group.id屬性為任意組名裁蚁。
$ vim consumer.properties
group.id=test
（2）在hadoop102矢渊、hadoop103上分別啟動消費者
$ bin/kafka-console-consumer.sh \
--zookeeper hadoop102:2181 --topic first --consumer.config config/consumer.properties
$ bin/kafka-console-consumer.sh --zookeeper hadoop102:2181 --topic first --consumer.config config/consumer.properties
（3）在hadoop104上啟動生產(chǎn)者
$ bin/kafka-console-producer.sh --broker-list hadoop102:9092 --topic first
>hello world
（4）查看hadoop102和hadoop103的接收者。
同一時刻只有一個消費者接收到消息枉证。
