一、kafka基本介紹

1概念：是一個分布式的基于發布/訂閱模式的消息隊列，應用于大數據實時處理

1.消息隊列(topic):

優點：解耦 可恢復性 緩沖 削峰 異步通信

兩種模式：

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

發布/訂閱模式：一對多、消費者消費數據后不會清除數據

二、kafka架構

kafka cluster：kafka集群管理消息

broker：一臺kafka服務器就是一個broker

topic：消息隊列主題

partition:分區

1.kafka基礎架構：

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

2).kafka集群

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

kafka內部維護topics，每個topic可以有多個分區（partition)，每個分區可以有多個副本（replication）

一個topic的多個分區可以存在到一個broker

一個topic的一個分區的多個副本必須在不同的broker

kafka中所有的讀和寫都是由leader負責

3).生產者：

生產者的主要作用就是面向topic生產數據，

4).消費者

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

一個消費者組中的一個消費者可以同時消費一個topic主題中的多個分區的數據

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

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

5).zookeeper

zookeeper 主要作用是讓kafka去注冊消息，例如，每個broker啟動后會在zookeeper中注冊，并產生出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）查看當前服務器中所有的topic

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

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

2）創建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）修改分區數

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）發送消息

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

7）消費消息

消費連接topic后接收的數據，前面已有的不消費

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

消費所有topic隊列中的數據，前面已有的按分區消費讀取

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

8）消費者組

通過修改配置文件創建 consumer.properties

group.id=mygroup

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

通過命令行創建

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

三、kafka架構深入

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

1）工作流程：

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

2）文件存儲機制：

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

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

2.生產者

1）分區策略

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

提高并發，提高吞吐量

2）分區原則

將producer發送的數據分裝成一個ProducerRecord對象。

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

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

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

3）數據可靠性的保證

• 生產者發送到topic partition的可靠性保證：

生產者向topic發送數據，topic收到數據后會返回一個ack（acknowledgement 確認收到）producer收到ack后則進行下一輪的發送，否則重新發送數據

• topic partition存儲數據的可靠性

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

• leader是什么時候向producer發送ack的呢？

有三種情況，這與ack的參數配置有關

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

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

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

• leader和follower怎么同步數據的呢？

首先要明白兩個概念：

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

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

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

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

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

• Exactly Once = At Least Once + 冪等性

保證數據的不重不漏

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

通過PID來保證其數據冪等性

3.消費者

1）消費方式

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

2）分區分配策略

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

三種分配策略：

RoundRobin：根據consumer的數量把分區partition輪詢方式分配，當consumer或partition有數量上的變動時則所有數據進行重新分配

Range:根據consumer的訂閱來進行分配，當訂閱相同，則根據consumer的數據分成連續幾份進行分配

Sticky:首次跟RoundRobin分配方式相同，當有consumer數據變化時，只需要將此consumer對應的分區進行分配即可

3）offset的維護

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

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

• 順序寫磁盤：kafka寫的過程都是追加寫到文件末尾，順序寫，省去了大量的磁頭尋址的時間
• 應用Pagecache：頁緩存將小塊寫組裝成大塊寫，并在頁緩存中進行簡單的排序處理，讀取數據是如果頁緩存中有則直接讀取，大大節省了讀寫時間
• 零復制技術：拷貝過程由磁盤到內核態后直接寫入到目的磁盤，不再進入用戶態，提高了效率

5）zookepper在kafka中的作用

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

6）kafka的事務

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

consumer端事務:借助于其他支持事務的框架來實現

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。