哈嘍大家好，我是咸魚(yú)

最近這段時(shí)間比較忙，將近一周沒(méi)更新文章，再不更新我那為數(shù)不多的粉絲量就要庫(kù)庫(kù)往下掉了 T﹏T

剛好最近在學(xué) Kafka，于是決定寫(xiě)篇跟 Kafka 相關(guān)的文章（文中有不對(duì)的地方歡迎大家指出）

考慮到有些小伙伴可能是第一次接觸 Kafka ，所以先簡(jiǎn)單介紹一下什么是 Kafka 吧！

Kafka 介紹

Kafka 是一個(gè)高吞吐的分布式消息系統(tǒng)，不但像傳統(tǒng)消息隊(duì)列（RaabitMQ、RocketMQ等）那樣能夠【異步處理、流量消峰、服務(wù)解耦】

圖片

還能夠把消息持久化到磁盤(pán)上，用于批量消費(fèi)。除此之外由于 Kafka 被設(shè)計(jì)成分布式系統(tǒng)，吞吐量和可用性大大提高

Kafka 角色

• kafka 客戶(hù)端

生產(chǎn)者（producer）：也叫發(fā)布者，負(fù)責(zé)創(chuàng)建消息

消費(fèi)者（consumer）：也叫訂閱者，負(fù)責(zé)消費(fèi)（讀取）消息

• Kafka 服務(wù)端（broker）

• leader：對(duì)外提供讀寫(xiě)服務(wù)

• follower：不提供服務(wù)，負(fù)責(zé)向 leader 同步數(shù)據(jù)

Topic（主題）和 partition（分區(qū)）

topic 就是消息發(fā)布的地方，消費(fèi)者通過(guò)訂閱 topic 來(lái)消費(fèi)到對(duì)應(yīng)的消息

為了提高吞吐量，實(shí)現(xiàn) topic 的負(fù)載均衡，Kafka 在 topic 下又引用了分區(qū)（partition）的概念，每個(gè) topic 可以被劃分成多個(gè)分區(qū)

分區(qū)允許消息在 Topic 下水平分割和存儲(chǔ)，每個(gè)分區(qū)都是一個(gè)有序且不可變的消息隊(duì)列，消費(fèi)者可以以并行的方式消費(fèi)同一個(gè) topic 中的消息

PS：topic 是邏輯上的概念，消息真正是存儲(chǔ)到 partition 中去的

圖片

例如某個(gè) topic 下被劃分成 n 個(gè)分區(qū)，那么這個(gè) topic 的并發(fā)度就提高 n，同時(shí)可以支持 n 個(gè) consumer 并行消費(fèi)該 topic 中的消息

log（日志）

對(duì)于每一個(gè) topic ，Kafka 都會(huì)維護(hù)一個(gè)分區(qū)日志

圖片

每個(gè)分區(qū)都是一個(gè)有序的、不可變的消息隊(duì)列，且可以持續(xù)地添加消息。消息在分區(qū)中分配了唯一的序列號(hào)，被稱(chēng)為偏移量（Offset）

offset 用來(lái)唯一的標(biāo)識(shí)分區(qū)中每一條記錄

Kafka 會(huì)保留所有分區(qū)中的消息，不會(huì)自動(dòng)刪除消息。消息的保留策略由 Kafka 配置參數(shù)控制，消息可以在一定時(shí)間或達(dá)到一定大小后過(guò)期，過(guò)期的消息會(huì)被刪除

消費(fèi)者在 Kafka 中只保留自己的 Offset，用于標(biāo)識(shí)它在分區(qū)中的位置。通常情況下，當(dāng) 消費(fèi)者消費(fèi)消息時(shí)，它的 Offset 會(huì)線性增加，表示它已經(jīng)消費(fèi)了這些消息

消費(fèi)者可以選擇將 Offset 重置為更舊的值，從而重新開(kāi)始讀取消息

每個(gè)消費(fèi)者實(shí)例唯一負(fù)責(zé)一個(gè)分區(qū)，Kafka 只保證分區(qū)內(nèi)的記錄是有序的，而不保證主題中不同分區(qū)的順序

Kafka 集群

Kafka 是分布式架構(gòu)，有集群（cluster）的概念

Kafka 中的一個(gè)實(shí)例被稱(chēng)為 broker，它接收生產(chǎn)者的消息并存入磁盤(pán)，消費(fèi)者連接 broker 消費(fèi)消息

多個(gè) broker 組成一個(gè) Kafka cluster，集群內(nèi)某個(gè) broker 會(huì)成為集群控制器（cluster controller），負(fù)責(zé)管理整個(gè) Kafka 集群，包括分配分區(qū)給 broker，監(jiān)控 broker 等

分區(qū)被復(fù)制成了多個(gè)副本（replica）然后均分在不同的 broker 上 ，其中一個(gè)副本 Leader，其他的是 Follower

創(chuàng)建副本的單位是 topic 的 分區(qū)

正常情況下，每個(gè)分區(qū)都有一個(gè) leader 和零或多個(gè) followers 。這樣即使某個(gè) broker 發(fā)生故障，其他 broker上的副本仍然可以繼續(xù)提供服務(wù)

圖片

那如何將所有的副本均勻分布在不同 broker 上呢？

分配副本的算法如下：

• 將所有 broker（假設(shè)共 n 個(gè) broker）和待分配的分區(qū)排序
• 將第 i 個(gè)分區(qū)分配到第（i mod n）個(gè) broker上
• 將第 i  個(gè)分區(qū)的第 j 個(gè)副本分配到第（(i + j) mode n）個(gè) broker 上

Kafka 如何實(shí)現(xiàn)數(shù)據(jù)同步

我們先來(lái)看下 Kafka 中的 ISR（In-Sync Replicas） 機(jī)制

既然每個(gè) leader 下面都有至少一個(gè) follower，于是便有了 ISR，ISR 就是 Kafka 動(dòng)態(tài)維護(hù)的一組同步副本集合

ISR 中所有的 follower 都與 leader 保持同步狀態(tài)，而且 leader 也在 ISR 列表中，只有在自己 ISR 列表中的副本才能參與 leader 競(jìng)選

當(dāng)生產(chǎn)者寫(xiě)入數(shù)據(jù)時(shí)，leader 更新數(shù)據(jù)，follower 是怎么知道 leader 更新然后去同步數(shù)據(jù)的呢？

follower 會(huì)通過(guò)定期向 leader  發(fā)送 fetch 請(qǐng)求來(lái)實(shí)現(xiàn)數(shù)據(jù)同步，這個(gè)是由 fetcher 線程來(lái)負(fù)責(zé)的

當(dāng)一個(gè)副本被選舉成為 follower 后，會(huì)啟動(dòng)副本的 fetcher 線程，隨后 Follower 會(huì)定期向 Leader 發(fā)送心跳請(qǐng)求，以保持連接，并發(fā)送 fetch 請(qǐng)求來(lái)獲取最新的數(shù)據(jù)。

如果 follower 發(fā)現(xiàn)自己的 LEO（Log End Offset，日志結(jié)束偏移量）與 Leader 的 LEO 有差距時(shí)，會(huì)觸發(fā)同步數(shù)據(jù)請(qǐng)求，以便將自身日志同步至 Leader 的對(duì)應(yīng)位置，確保與 Leader 的數(shù)據(jù)保持一致

如果一個(gè) follower 在指定時(shí)間內(nèi)（配置字段為 replica.lag.time.max.ms）沒(méi)有發(fā)送 fecth 請(qǐng)求或者沒(méi)有追上 leader 的 LEO，就會(huì)從 ISR 中移除

最后總結(jié)一下：

• Kafka 中的 topic 是邏輯概念，每個(gè) topic 可以被劃分為多個(gè)分區(qū)，而分區(qū)才是存儲(chǔ)消息的實(shí)體
• 每一個(gè)分區(qū)會(huì)被復(fù)制成多個(gè)副本，然后選取其中一個(gè)副本當(dāng)作 leader，剩下的則是 follower
• follower 會(huì)定期去向 leader 發(fā)送 fetch 請(qǐng)求來(lái)保證數(shù)據(jù)的同步
• leader 不會(huì)關(guān)心 follower 的數(shù)據(jù)是不是同步好了的，只要你在指定時(shí)間內(nèi)沒(méi)有找我來(lái) fetch ，我就把你從 ISR 中剔除出去（事實(shí)證明主動(dòng)點(diǎn)也并非壞事）