概述

Kafka 是由 LinkedIn 開發(fā)一個(gè)分布式的基于發(fā)布訂閱模式的消息隊(duì)列，是一個(gè)實(shí)時(shí)數(shù)據(jù)處理系統(tǒng)，可以橫向擴(kuò)展。與 RabbitMQ、RockerMQ 等中間件一樣擁有幾大特點(diǎn)：

1、異步處理

2、服務(wù)解耦

3、流量削峰

下圖是異步處理的示例圖。

架構(gòu)

如下圖，一個(gè) Kafka 架構(gòu)包含若干個(gè) Producer，若干個(gè) Consumer，若干個(gè) Broker 和一個(gè) Zookeeper 集群。

Zookeeper：Kafka 集群通過 Zookeeper 管理集群配置。選舉 Leader、Consumer Group 發(fā)送變化是進(jìn)行 Rebalance。

Broker：消息中間件處理節(jié)點(diǎn)，一個(gè)節(jié)點(diǎn)就是一個(gè) Broker，一個(gè) Kafka 集群由一個(gè)或多個(gè) Broker 組成，一個(gè)消息可以分布在多個(gè) Broker 中。

Producer：生產(chǎn)者，負(fù)責(zé)發(fā)布消息到 Broker。

Consumer：消費(fèi)者，從 Broker 讀取消息。

Consumer Group：每個(gè) Consumer 屬于一個(gè)特定的 Consumer Group，可以為這個(gè) Group 指定名稱，不指定則屬于默認(rèn)的 Group。一條消息可以發(fā)送多個(gè) Group，但一個(gè) Group 中只能有一個(gè) Consumer 消費(fèi)這條消息。

Kafka 對消息進(jìn)行歸類，發(fā)送到集群的每一條消息都要指定一個(gè) Topic， 一個(gè) Topic 為一類消息，邏輯上被認(rèn)為是一個(gè) Queue，Producer 生產(chǎn)的每條消息必須指定一個(gè) Topic，然后 Consumer 會根據(jù)訂閱的 Topic 到對應(yīng)的 Broker 上去拉取消息。

每個(gè) Topic 包含一個(gè)或多個(gè) Partition，一個(gè) Partition 對應(yīng)一個(gè)文件夾，這個(gè)文件夾下存儲 Partition (分區(qū)) 的數(shù)據(jù)和索引文件，每個(gè) Partition 內(nèi)部是有序的。這樣一個(gè) Topic 分成一個(gè)或多個(gè) Partition，每個(gè) Partition 有多個(gè)副本分布在不同的 Broker中。

一個(gè)分區(qū)的多個(gè)副本之間是一主(Leader)多從(Follower)的關(guān)系，Leader 對外提供服務(wù)，這里的對外指的是與客戶端程序進(jìn)行交互，而 Follower 只是被動地同步 Leader 而已，不能與外界進(jìn)行交互。通過多副本機(jī)制實(shí)現(xiàn)了故障的自動轉(zhuǎn)移，當(dāng)集群中某個(gè) Broker 失效時(shí)仍然能保證服務(wù)可用，可以提升容災(zāi)能力。?

如下圖所示，Kafka 集群中有 4 個(gè) Broker，某個(gè) Topic 有三個(gè)分區(qū)，假設(shè)副本因子也設(shè)置為了 3，那么每個(gè)分區(qū)就會有一個(gè) Leader 和兩個(gè) Follower 副本。

分區(qū)副本處于不同 Broker 中，生產(chǎn)者與消費(fèi)者只和 Leader 副本進(jìn)行交互，而 Follower 副本只負(fù)責(zé)消息的同步。當(dāng) Leader 副本出現(xiàn)故障時(shí)，會從 Follower 副本中重新選舉新的 Leader 副本對外提供服務(wù)。

下面來看一下 Kafka 多副本機(jī)制中的一些重要術(shù)語。

AR(Assigned Replicas)：一個(gè)分區(qū)中的所有副本統(tǒng)稱為 AR。

ISR(In-Sync Replicas)：Leader 副本和所有保持一定程度同步的 Follower 副本（包括 Leader 本身）組成 ISR。

OSR(Out-of-Sync Raplicas)：與 ISR 相反，沒有與 Leader 副本保持一定程度同步的所有 Follower 副本組成OSR。

首先，生產(chǎn)者會將消息發(fā)送給 Leader 副本，然后 Follower 副本才能從 Leader 中拉取消息進(jìn)行同步，在同一時(shí)刻，所有副本中的消息不完全相同，也就是說同步期間，F(xiàn)ollower 相對于 Leader 而言會有一定程度上的滯后。這樣可以看到三者的關(guān)系：AR = ISR + OSR。

Leader 負(fù)責(zé)維護(hù)和跟蹤 ISR 集合中所有 Follower 副本的滯后狀態(tài)，當(dāng) Follower 出現(xiàn)滯后太多或者失效時(shí)，Leader 將會把它從 ISR 集合中剔除。當(dāng)然，如果 OSR 集合中有 Follower 同步范圍追上了 Leader，那么 Leader 也會把它從 OSR 集合中轉(zhuǎn)移至 ISR 集合。一般情況下，當(dāng) Leader 發(fā)送故障或失效時(shí)，只有 ISR 集合中的 Follower 才有資格被選舉為新的 Leader，而 OSR 集合中的 Follower 則沒有這個(gè)機(jī)會（不過可以修改參數(shù)配置來改變）。

監(jiān)控 Kafka 的關(guān)鍵指標(biāo)

接下來介紹 Kafka 指標(biāo)。包含以下指標(biāo)：

UnderReplicatedPartitions

OfflineLogDirectoryCount

IsrShrinksPerSec / IsrExpandsPerSec

ActiveControllerCount

OfflinePartitionsCount

LeaderElectionRateAndTimeMs

UncleanLeaderElectionsPerSec

TotalTimeMs

PurgatorySize

BytesInPerSec / BytesOutPerSec

RequestsPerSec

其它常用指標(biāo)

指標(biāo)詳情可查看【Kafka 可觀測最佳實(shí)踐?】

https://docs.guance.com/best-practices/monitoring/kafka/

場景視圖

在開始使用觀測云觀測 Kafka 之前，您需要先注冊一個(gè)?觀測云賬號?，注冊完成后登錄到觀測云工作空間。然后按照 Kafka 集成文檔來實(shí)現(xiàn) Kafka 的可觀測。