一、kafka基本介紹

1概念：是一個分布式的基于發(fā)布/訂閱模式的消息隊列，應(yīng)用于大數(shù)據(jù)實時處理

1.消息隊列(topic):

優(yōu)點：解耦 可恢復(fù)性 緩沖 削峰 異步通信

兩種模式：

點對點模式：一對一，消費者主動拉去數(shù)據(jù)，消息收到后消息清除

發(fā)布/訂閱模式：一對多、消費者消費數(shù)據(jù)后不會清除數(shù)據(jù)

二、kafka架構(gòu)

kafka cluster：kafka集群管理消息

broker：一臺kafka服務(wù)器就是一個broker

topic：消息隊列主題

partition:分區(qū)

1.kafka基礎(chǔ)架構(gòu)：

1).kafka架構(gòu)中涉及到kafka集群（多個broker）生產(chǎn)者（生產(chǎn)消息）、消費者（消費消息）、zookeeper(注冊消息)

2).kafka集群

kafka集群由多個broker組成，每個broker都有一個唯一id

kafka內(nèi)部維護topics，每個topic可以有多個分區(qū)（partition)，每個分區(qū)可以有多個副本（replication）

一個topic的多個分區(qū)可以存在到一個broker

一個topic的一個分區(qū)的多個副本必須在不同的broker

kafka中所有的讀和寫都是由leader負責(zé)

3).生產(chǎn)者：

生產(chǎn)者的主要作用就是面向topic生產(chǎn)數(shù)據(jù)，

4).消費者

消費者主要是以消費者組的名義面向topic進行消息的消費

一個消費者組中的一個消費者可以同時消費一個topic主題中的多個分區(qū)的數(shù)據(jù)

一個topic主題中的一個分區(qū)只能被一個消費者組中的一個消費者消費

消費者在消費數(shù)據(jù)的過程中需要實時記錄offset（消費的位置），記錄的方式為：group+topic+partition

5).zookeeper

zookeeper 主要作用是讓kafka去注冊消息，例如，每個broker啟動后會在zookeeper中注冊，并產(chǎn)生出controller

在0.9版本之前，消費者維護的offset存儲在zookeeper中

在0.9版本以后，消費者維護的offset存儲在kafka本地

2.kafka啟停腳本

腳本的使用: Welcome to nginx! start | stop

#!/bin/bashif [ $# -lt 1 ] thenecho "usage: Welcome to nginx! {start | stop}"exit ficase $1 in start)bash /home/atguigu/bin/zk.sh $1sleep 5000for i in hadoop102 hadoop103 hadoop104doecho "==================> start $i kafka <======================"ssh $i /opt/module/kafka-2.4.1/bin/kafka-server-start.sh -daemon /opt/module/kafka-2.4.1/config/server.propertiesdone ;; stop)bash /home/atguigu/bin/zk.sh $1sleep 5000for i in hadoop102 hadoop103 hadoop104doecho "==================> stop $i kafka <======================"ssh $i /opt/module/kafka-2.4.1/bin/kafka-server-stop.sh stopdone ;;*)echo "input args error..."exit ;; esac

3.kafka命令行操作

1）查看當(dāng)前服務(wù)器中所有的topic

--bootstrap-server == --zookepper 注意后面的端口號不一樣

kafka-topics.sh --bootstrap-server hadoop102:9092 --list kafka-topics.sh --zookepper hadoop102:2181 --list

2）創(chuàng)建topic

kafka-topics.sh --bootstrap-server hadoop102:9092 --create --topic t_name replication-factor 3 partition 2

3）查看某個topic的詳情

kafka-topic.sh --bootstrap-server hadoop102:9092 --describe --topic t_name

4）修改分區(qū)數(shù)

kafka-topics.sh --zookeeper hadoop102:2181 --alter --topic t_name --partitions 2

5）刪除topic

kafka-topics.sh --bootstrap-server hadoop102:9092 --delete --topic t_name

6）發(fā)送消息

kafka-console-producer.sh --broker-list hadoop102:9092 --topic t_name

7）消費消息

消費連接topic后接收的數(shù)據(jù)，前面已有的不消費

kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic t_name

消費所有topic隊列中的數(shù)據(jù)，前面已有的按分區(qū)消費讀取

kafka-console_consumer.sh --bootstrap-server hadoop102:9092 --topic t_name --from-beginning

8）消費者組

通過修改配置文件創(chuàng)建 consumer.properties

group.id=mygroup

kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic t_name --consumer.config config/consumer.properties

通過命令行創(chuàng)建

kafka-console-consumer.sh --bootstrap-server hadoop102:9092 --topic t_name --group group_name

三、kafka架構(gòu)深入

1.工作流程及文件存儲機制

1）工作流程：

kafak是基于生產(chǎn)者-消費者模型來工作的，生產(chǎn)者生產(chǎn)消息，消費者消費消息，而兩者不直接連接，通過一個阻塞消息隊列topic來進行聯(lián)系

2）文件存儲機制：

topic只是個邏輯上的概念，每個topic可以有多個分區(qū)partition，真正在磁盤上存儲是以partition來進行存儲的，每個partition對應(yīng)一個log文件，producer生產(chǎn)的數(shù)據(jù)會不斷追加到該log文件末端，而且每條數(shù)據(jù)都有自己的offset(group+topic+partition),實際上為了防止該log文件過大，每個partition又會分片為多個segment，每個segment對應(yīng)兩個文件——“.index”文件和“.log”文件。

注意：每個log文件的文件名，是以offset+1來命名的

2.生產(chǎn)者

1）分區(qū)策略

分區(qū)原因:分區(qū)是為了能夠在集群中橫向擴展

提高并發(fā)，提高吞吐量

2）分區(qū)原則

將producer發(fā)送的數(shù)據(jù)分裝成一個ProducerRecord對象。

（1） 指明 partition 的情況下，直接將指明的值直接作為 partiton 值；

（2） 沒有指明 partition 值但有 key 的情況下，將 key 的 hash 值與 topic 的 partition 數(shù)進行取余得到 partition 值；

（3） 既沒有 partition 值又沒有 key 值的情況下， kafka采用Sticky Partition(黏性分區(qū)器)，會隨機選擇一個分區(qū)，并盡可能一直使用該分區(qū)，待該分區(qū)的batch已滿或者已完成，kafka再隨機一個分區(qū)進行使用.

3）數(shù)據(jù)可靠性的保證

• 生產(chǎn)者發(fā)送到topic partition的可靠性保證：

生產(chǎn)者向topic發(fā)送數(shù)據(jù)，topic收到數(shù)據(jù)后會返回一個ack（acknowledgement 確認收到）producer收到ack后則進行下一輪的發(fā)送，否則重新發(fā)送數(shù)據(jù)

• topic partition存儲數(shù)據(jù)的可靠性

kafka采用的同步策略為當(dāng)全部的flower完成數(shù)據(jù)同步后集群才返回ack，但是如果有一個follower出現(xiàn)了故障leader也不能一直等下去啊，為了解決這個問題，kafka讓leader維護了一個動態(tài)的ISR（in-sync-replica set),是一個和leader保持同步的follower的集合，當(dāng)次集合里面的所有follower完成同步則leader給producer發(fā)送ack，如果follower出現(xiàn)故障不能向leader同步數(shù)據(jù)，則該follower會被踢出ISR，如果leader發(fā)生了故障，就會在ISR中重新選舉出新的leader

• leader是什么時候向producer發(fā)送ack的呢？

有三種情況，這與ack的參數(shù)配置有關(guān)

acks=0 ：leader接收到數(shù)據(jù)但未寫入磁盤就返回ack，此時leader故障可能會丟失數(shù)據(jù)

acks=1:leader落盤成功返回ack，但follower還未同步，此時leader故障會丟失數(shù)據(jù)

acks=-1：leader和follower都落盤成功返回ack，但在發(fā)送前l(fā)eader故障則ack未被接收，producer會重新發(fā)送數(shù)據(jù)，會造成數(shù)據(jù)重復(fù)

• leader和follower怎么同步數(shù)據(jù)的呢？

首先要明白兩個概念：

LEO:指的是每個副本最大的offset

HW:指的是消費者能見到的最大的offset，ISR隊列中最小的LEO

leader中的LEO肯定是最大的，follower向leader同步數(shù)據(jù)，而在HW之前的數(shù)據(jù)才是向消費者可見的，這是因為HW之前的數(shù)據(jù)才是leader真正ack響應(yīng)后的數(shù)據(jù)

當(dāng)follower發(fā)生故障時，則就會被臨時踢出ISR中，待恢復(fù)后，則follower會讀取本地磁盤里記錄的HW值，并將log文件高于HW的部分去掉，從HW開始向leader進行同步數(shù)據(jù)，當(dāng)該follower的LEO的值大于該partition的HW時，則重新加入ISR中

當(dāng)leader發(fā)生故障時，會從ISR中選出一個新的leader，此時leader和follower都會先將各自log文件中高于HW的部分去掉，然后等待向leader同步數(shù)據(jù)

• Exactly Once = At Least Once + 冪等性

保證數(shù)據(jù)的不重不漏

冪等性：無論操作了多少次，其結(jié)果都與一次操作相同

通過PID來保證其數(shù)據(jù)冪等性

3.消費者

1）消費方式

push(推)模式很難適應(yīng)不同消費速率的消費者，所有kafka采用的是pull（拉）模式從broker中讀取數(shù)據(jù)，但是pull實際是一個長輪詢的過程，可以傳入一個timeout參數(shù)來避免空轉(zhuǎn)

2）分區(qū)分配策略

主要問題是哪個partition被哪個consumer消費的問題

三種分配策略：

RoundRobin：根據(jù)consumer的數(shù)量把分區(qū)partition輪詢方式分配，當(dāng)consumer或partition有數(shù)量上的變動時則所有數(shù)據(jù)進行重新分配

Range:根據(jù)consumer的訂閱來進行分配，當(dāng)訂閱相同，則根據(jù)consumer的數(shù)據(jù)分成連續(xù)幾份進行分配

Sticky:首次跟RoundRobin分配方式相同，當(dāng)有consumer數(shù)據(jù)變化時，只需要將此consumer對應(yīng)的分區(qū)進行分配即可

3）offset的維護

Kafka 0.9版本之前，consumer默認將offset保存在Zookeeper中，從0.9版本開始，consumer默認將offset保存在Kafka一個內(nèi)置的topic中，該topic為__consumer_offsets。

4）kafka為什么能高效讀寫？

• 順序?qū)懘疟P：kafka寫的過程都是追加寫到文件末尾，順序?qū)?#xff0c;省去了大量的磁頭尋址的時間
• 應(yīng)用Pagecache：頁緩存將小塊寫組裝成大塊寫，并在頁緩存中進行簡單的排序處理，讀取數(shù)據(jù)是如果頁緩存中有則直接讀取，大大節(jié)省了讀寫時間
• 零復(fù)制技術(shù)：拷貝過程由磁盤到內(nèi)核態(tài)后直接寫入到目的磁盤，不再進入用戶態(tài)，提高了效率

5）zookepper在kafka中的作用

當(dāng)kafka剛啟動時broker都會向zookeeper去注冊，爭搶選舉出Controller，再有Controller負責(zé)管理topic的分區(qū)分配和leader選舉等工作

6）kafka的事務(wù)

producer端事務(wù):引入全局唯一TransactionID與Producer的PID進行綁定

consumer端事務(wù):借助于其他支持事務(wù)的框架來實現(xiàn)

與50位技術(shù)專家面對面20年技術(shù)見證，附贈技術(shù)全景圖

總結(jié)

以上是生活随笔為你收集整理的kafka修改分区数_Kafka笔记的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。