KAFKA學習記錄

                                               KAFKA學習記錄

我學習kafka主要是通過《kafka權威指南》這本書,以及網上的一些博客,看書遇到不明白的地方就去網上找一些資料,包括以下幾個博客

美團的一個技術寫的:https://blog.csdn.net/lizhitao/article/details/39499283

看書的過程還是需要做一些筆記的,不然過一段時間就忘記了,先來一張思維導圖,後續還會補充

概念:

    Broker:一個獨立的Kafka服務器被稱爲broker,broker接收來自生產者的消息,爲消息設置偏移量,並提交消息到磁盤保存,broker爲消費者提供服務,對讀取分區的請求做出響應,返回已經提交到磁盤的消息。

分區首領:每個集羣都有一個broker同時充當了集羣控制器的角色(自動從集羣的活躍成員選舉出來)。控制器負責管理工作,包括將分區分配給broker和監控broker,在集羣中一個分區從屬於一個broker,該broker被稱爲分區的首領,一個分區可以分配給多個broker,這個時候就會發生分區複製

保留消息:(在一定期限內)是kafka的一個重要特性,Kafka broker默認的消息保留策略:保留一段時間(比如7天)要麼保留到一定大小的字節數(比如1GB)

主題默認配置:

num.partitions分區數量,默認爲1

log.retention.hours:決定數據可以保留多久(作用於日誌片段)

log.retention.bytes:通過保留的消息字節數判斷消息是否過期,(作用於每個分區)

log.segment.bytes

 

生產者

發送消息3種方式

發送並忘記:把消息發送給生產者,並不關心是否正常到達,生產者可以自動嘗試重發

同步發送:使用send發送消息,返回一個Future對象,調用get方法進行等待,就可以知道消息是否發送成功

異步發送:調用send方法,並指定一個回調函數,服務器在返回響應時調用該函數

生產者配置:

acks:指定必須要有多個分區副本收到消息,生產者纔會認爲消息寫入是成功的

acks=0,不等待服務器響應,因爲生產者不需要等待服務器的響應,所以它可以以網絡能夠支持的最大速度發送消息,從而達到很高的吞吐量,

acks=1只要集羣的首領收到消息

acks=all,只有當所有參與複製的節點全部收到消息時,生產者纔會受到一個來自服務器的成功響應

buffer.memory:該參數用來設置生產者內存緩衝區的大小,生產者用它緩衝要發送到服務器的消息,如果應用程序發送消息的速度超過發送到服務器的速度,會導致生產者空間不足,這個時候send方法要麼阻塞,要麼拋出異常,取決於如何設置block.on.buffer.full參數

retries消息重發次數

batch.size:該參數指定了一個批次可以使用的內存大小,按照字節數計算

linger.ms:該參數指定了生產者在發送批次之前等待更多消息加入批次的時間,kafka producer會在批次填滿或者linger.ms達到上限時把批次發送出去。

生產者分區策略:

key爲null的時候,記錄被隨機發送到主題內各個可用的分區上,分區其使用輪詢算法將消息均衡的分佈到各個分區上

key不爲空,並且使用默認分區器,kafka會對健進行散列,然後根據散列值把消息映射到特定的分區上

 

消費者:

消費者的配置:

fetch.min.bytes:指定消費者從服務器獲取記錄的最小字節數

fetch.max.wait.ms:用於指定broker的等待時間

max.partition.fetch.bytes:指定了服務器從每個分區返回給消費者的最大字節數,max.partition.fetch.bytes的值必須比broker能夠接收的最大消息的字節數大,否則消費者可能無法讀取這些消息

session.timeout.ms

該屬性指定了消費者在被認爲死亡之前可以與服務器斷開連接的時間,默認是3s,如果消費者沒有在session.timeout.ms指定的時間內發送心跳給羣組協調器,就被認爲已經死亡

heartbeat.interval.ms:指定了poll()方法想協調器發送心跳的頻率,heartbeat.interval.ms必須比session.timeout.ms小

auto.offset.reset:該屬性指定了在讀取一個沒有偏移量的分區或者偏移量無效的情況下,該做如何處理,默認值是lastest意思是說在偏移量無效的情況下,消費者將從最新的記錄開始讀取數據,另一個值是earliest,意思是說,在偏移量無效的情況下,消費者將從起始位置讀取分區的記錄

enable.auto.commit:指定了消費者是否自動提交偏移量,默認true,如果設置true,可以通過配置auto.commit.interval.ms屬性來控制提交的頻率

partition.assignment.strategy:分區策略 Range分區策略:把主題內的若干個連續的分區分配給消費者 分區策略 RoundRobin,該策略把主題的所有分區逐個分配給消費者

max.poll.records:該屬性用於控制單次調用call方法能夠返回的記錄數量

 

再均衡監聽器:

從特定偏移量開始處理記錄:

每一個消費者從屬於一個消費者羣組,多個消費者羣組可以同時讀取一個主題的數據

再均衡:分區的所有權從一個消費者轉移到另一個消費者,它爲消費者羣組帶來了高可用性和伸縮性

消費者通過向被指派爲羣組協調器的broker發送心跳來維持它們和羣組的從屬關係以及他們對分區的所有權關係,只要消費者以正常的時間時間間隔發送心跳,就被認爲是活躍的。

提交和偏移量:

提交:更新分區當前位置的操作

如何提交偏移量:消費者往一個叫做_consumer_offser的特殊主題發送消息,消息裏包含每個分區的偏移量,當觸發在均衡的時候,每個消費者可能分配到新的分區,而不是之前處理的那個,爲了能繼續之前的工作,消費者需要讀取每個分區最後一次提交的偏移量,然後從偏移量指定的地方繼續處理

提交偏移量的方式:

自動提交:消費者自動提交偏移量,設置enable.auto.commit爲tue,那麼每過5s,消費者會自動把從poll()方法接收到的最大偏移量提交上去,提交時間間隔由auto.commit.interval.ms控制,默認值是5s

自動提交會導致重複消費問題,在使用自動提交時,每次調用輪詢方法都會把上一次調用返回的偏移量提交上去

提交當前偏移量:開發者在必要的時候提交當前偏移量,而不是基於時間間隔,設置auto.commit.offset設爲false,使用commitSync()提交偏移量,這個api會提交由poll()方法返回的最新偏移量,提交成功後馬上返回(在broker對提交請求作出迴應之前,應用程序會一直阻塞,這樣會限制程序的吞吐量,可以通過降低提交頻率來提升吞吐量,但如果發生了再均衡,會增加重複i消息的數量)

異步提交:使用commitAsync()異步提交偏移量,只管發送請求,無須等待broker的響應,不會進行重試, 對於異步提交,由於不會進行失敗重試,當消費者異常關閉或者觸發了再均衡前,如果偏移量還未提交就會造成偏移量丟失。commitAsync()提交也支持回調,在broker作出反應時會執行回調

重試異步提交:可以使用一個單調遞增的序列號來維持異步提交的順序,在每次提交偏移量之後或者在回調裏提交偏移量時遞增序列號,在進行重試時,先檢查回調的序列號和即將提交的偏移量是否相等,如果相等,說明沒有新的提交,那麼可以安全的重試,如果序列號比較大,說明一個新的提交已經發送出去了,應該停止重試

異步+同步 組合的方式提交偏移量: 針對異步提交偏移量丟失的問題,通過對消費者進行異步批次提交併且在關閉時同步提交的方式,這樣即使上一次的異步提交失敗,通過同步提交還能夠進行補救,同步會一直重試,直到提交成功。

提交特定的偏移量:可以提交指定分區和偏移量

深入kafka

kafka如何進行復制?

kafka如何處理來自生產者和消費者的請求?

kafka的存儲細節,比如文件格式和索引?

 

複製:kafka的分區副本分爲leader副本和follower副本,由leader 副本處理所有來自生產者的請求和消費者的請求,首領以外的副本都是follower副本,他們唯一的任務就是從首領那裏複製消息,保持與首領一致的狀態,如果首領發生奔潰,其中一個跟隨者會被提升爲新首領。

 

存儲細節:https://www.cnblogs.com/wuzhenzhao/p/10143946.html    消息的文件存儲機制

https://mp.weixin.qq.com/s/kZcHe6FSgd5fKidGlX9i3Q 美團的

集羣的成員關係:

kafka使用zookeeper來維護集羣成員的信息,每個broker都有一個唯一的標識符,在broker啓動的時候,通過創建臨時節點把自己的id註冊到Zookeeper,Kafka組件訂閱Zookeeper的/broker/ids路徑,當有broker加入集羣或者退出集羣時,這些組件就可以獲得通知,

 

控制器:控制器其實就是一個broker,它除了具有一般broker的功能以外,還負責分區首領的選舉,集羣裏第一個啓動的broker通過在Zookeeper裏創建一個臨時節點/controller讓自己成爲控制器。其他broker在啓動時也會嘗試創建這個節點,不過會收到一個“節點已存在”的異常,也就是說集羣已經有一個controller,其他節點在控制器節點上創建zookeeper watch對象,這樣就可以收到這個節點的變更通知,這種方式可以確保這個集羣裏只有一個控制器存在

Kafka使用Zookeeper的臨時節點來選舉控制器,並在節點加入集羣或者退出集羣時通知控制器,控制器負責在節點加入或離開集羣時進行分區首領選舉,控制器使用epoch來避免腦裂。

複製:kafka使用主題來組織數據,每個主題被分爲若干分區,每個分區有多個副本,那些副本被保存在broker上,每個broker可以保存成百上千個屬於不同主題和分區的副本。

首領副本:每個分區都有一個首領副本,爲了保證一致性,所有生產者請求和消費者請求都會經過這個副本

跟隨者副本:首領以外的副本都是跟隨者副本,跟隨者副本不處理來自客戶端的請求,它們唯一的任務就是從首領那裏複製信息,保持與首領一致的狀態,如果首領發生奔潰,其中的一個副本就會被提升爲新首領

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章