柚子快報(bào)激活碼778899分享：學(xué)習(xí) 筆記 kafka架構(gòu)深入

http://yzkb.51969.com/

kafka架構(gòu)

3.1 kafka工作流程及文件存儲(chǔ)

kafka中消息是以topic進(jìn)行分類的，生產(chǎn)消費(fèi)都面向topic。topic是一個(gè)邏輯上的概念，而partition是一個(gè)物理上的概念，每個(gè)partition對(duì)應(yīng)一個(gè)log文件，該log文件存儲(chǔ)的就是生產(chǎn)者產(chǎn)生的數(shù)據(jù)。producer生產(chǎn)的數(shù)據(jù)會(huì)不斷追加到該log文件末尾，而且每條數(shù)據(jù)都有自己的offset。消費(fèi)者組中的消費(fèi)者，都會(huì)實(shí)時(shí)記錄自己的offset，方便出錯(cuò)恢復(fù)時(shí)，從上次的位置繼續(xù)消費(fèi)。

由于生產(chǎn)者的消息一直追加到log文件末尾，為了防止log文件過大導(dǎo)致定位效率低，kafka采用了分區(qū)和索引機(jī)制。文件夾命名規(guī)范：主題名稱+分區(qū)號(hào)，具體文件以當(dāng)前第一條消息的segment的offset命名。index文件存儲(chǔ)大量索引信息，log文件存儲(chǔ)大量的數(shù)據(jù)。

3.2 kafka生產(chǎn)者

3.2.1 分區(qū)策略

1）分區(qū)的原因

①方便在集群中擴(kuò)展，每個(gè)partition可以通過調(diào)整適應(yīng)所在的機(jī)器，而topic又由多個(gè)partition組成，因此整個(gè)集群就可以適應(yīng)任意大小數(shù)據(jù)。

②提高并發(fā)，以partition為單位讀寫。

2）分區(qū)的原則

我們需要把Producer發(fā)送的數(shù)據(jù)封裝成一個(gè)ProducerRecord對(duì)象，如圖：

（1）指定分區(qū) 按分區(qū)走 （2）key key的hashcode值%分區(qū)數(shù) （3）沒有指定key 沒有指定分區(qū) 第一隨機(jī)

3.2.2 數(shù)據(jù)可靠性保證

? 為保證 producer 發(fā)送的數(shù)據(jù)，能可靠的發(fā)送到指定的 topic，topic 的每個(gè) partition 收到producer 發(fā)送的數(shù)據(jù)后，都需要向 producer 發(fā)送 ack (acknowledgement 確認(rèn)收到)，如果producer 收到 ack，就會(huì)進(jìn)行下一輪的發(fā)送，否則重新發(fā)送數(shù)據(jù)。

1）.同樣為了容忍 n臺(tái)節(jié)點(diǎn)的故障，第一種方案需要 2n+1 個(gè)副本，而第二種方案只需要 n+1個(gè)副本，而 Kafka 的每個(gè)分區(qū)都有大量的數(shù)據(jù)，第一種方案會(huì)造成大量數(shù)據(jù)的冗余。

2）.雖然第二種方案的網(wǎng)絡(luò)延遲會(huì)比較高，但網(wǎng)絡(luò)延遲對(duì) Kafka 的影響較小。

ISR

? 采用第二種方案之后，設(shè)想以下情景: leader 收到數(shù)據(jù)，所有 follower 都開始同步數(shù)據(jù)但有一個(gè) follower,因?yàn)槟撤N故障,遲遲不能與 leader 進(jìn)行同步，那leader 就要一直等下去直到它完成同步，才能發(fā)送 ack。這個(gè)問題怎么解決呢?“ ? Leader 維護(hù)了一個(gè)動(dòng)態(tài)的 in-sync replica set(ISR)，意為和 leader 保持同步的 follower 集合。當(dāng)ISR 中的 follower 完成數(shù)據(jù)的同步之后,leader 就會(huì)給 follower 發(fā)送 ack。如果 follower長時(shí)間未向 leader 同步數(shù)據(jù)，則該 follower 將被踢出 ISR，該時(shí)間闕值由replica.lag.time.max,ms 參數(shù)設(shè)定。Leader 發(fā)生故障之后，就會(huì)從ISR 中選舉新的 leader。

ack應(yīng)答機(jī)制

前提：對(duì)于某些不太重要的數(shù)據(jù)，對(duì)數(shù)據(jù)的可靠性要求不是很高，能夠容忍數(shù)據(jù)的少量丟失，所以沒必要等ISR中的 follower 全部接收成功，所以 Kaka 為用戶提供了三種可靠性級(jí)別，用戶根據(jù)對(duì)可靠性和延遲的要求進(jìn)行權(quán)衡，選擇以下的配置。

0: producer 不等待 broker 的 ack，這一操作提供了一個(gè)最低的延遲，broker 一接收到還沒有寫入磁盤就已經(jīng)返回，當(dāng) broker 故障時(shí)有可能丟失數(shù)據(jù); ? l: producer 等待 broker 的 ack，partition 的 leader 落盤成功后返回 ack，如果在 follower同步成功之前 leader 故障，那么將會(huì)丟失數(shù)據(jù)；

-1(all): producer 等待 broker 的 ack，partition 的 leader 和 follower 全部落盤成功后才返回 ack。但是如果在 follower 同步完成后，broker 發(fā)送 ack 之前，leader 發(fā)生故障，那么會(huì)造成數(shù)據(jù)重復(fù)。

3.2.3 數(shù)據(jù)一致性

LEO:指的是每個(gè)副本最大的 offset;

HW:指的是消費(fèi)者能見到的最大的 offset，ISR 隊(duì)列中最小的LEO；

(1) follower 故障 follower 發(fā)生故障后會(huì)被臨時(shí)踢出 ISR，待該 follower 恢復(fù)后，follower 會(huì)讀取本地磁盤記錄的上次的 HW，并將 log 文件高于 HW 的部分截取掉，從HW 開始向 leader 進(jìn)行同步。等該 follower的LEO 大于等于該 Partition 的HW，即 follower 追上 leader 之后，就可以重新加入ISR了。

(2)leader 故障

? leader 發(fā)生故障之后，會(huì)從ISR 中選出一個(gè)新的leader，之后，為保證多個(gè)副本之間的數(shù)據(jù)一致性,其余的 follower 會(huì)先將各自的 1og 文件高于 HW 的部分截掉,然后從新的 leader同步數(shù)據(jù)。

注意:這只能保證副本之間的數(shù)據(jù)一致性，并不能保證數(shù)據(jù)不丟失或者不重復(fù)。

3.2.4 exactly once

? 將服務(wù)器的ACK 級(jí)別設(shè)置為-1，可以保證 Producer 到 Server 之間不會(huì)丟失數(shù)據(jù)，即AtLeast Once 語義。相對(duì)的，將服務(wù)器 ACK 級(jí)別置為 0，以保證生產(chǎn)者每條消息只會(huì)被發(fā)送一次，即At Most Once 語義。 ? AtLeast Once 可以保證數(shù)據(jù)不丟失，但是不能保證數(shù)據(jù)不重復(fù);相對(duì)的，AtLeast Once可以保證數(shù)據(jù)不重復(fù)，但是不能保證數(shù)據(jù)不丟失。但是，對(duì)于一些非常重要的信息，比如說交易數(shù)據(jù)，下游數(shù)據(jù)消費(fèi)者要求數(shù)據(jù)既不重復(fù)也不丟失，即 Exactly Once 語義。

? 在 0.11 版本以前的 Kafka，對(duì)此是無能為力的，只能保證數(shù)據(jù)不丟失，再在下游消費(fèi)者對(duì)數(shù)據(jù)做全局去重。對(duì)于多個(gè)下游應(yīng)用的情況,每個(gè)都需要單獨(dú)做全局去重,這就對(duì)性能造成了很大影響。0.11版本的 Kaka，引入了一項(xiàng)重大特性:冪等性。所謂的冪等性就是指 Producer 不論向Server 發(fā)送多少次重復(fù)數(shù)據(jù)，Server 端都只會(huì)持久化一條。冪等性結(jié)合 At Least Once 語義，就構(gòu)成了 Kafka的 Exactly Once 語義。

? 要啟用冪等性，只需要將 Producer 的參數(shù)中enable.idompotence 設(shè)置為 true 即可。Kafka的冪等性實(shí)現(xiàn)其實(shí)就是將原來下游需要做的去重放在了數(shù)據(jù)上游。開啟冪等性的 Producer 在初始化的時(shí)候會(huì)被分配一個(gè) PID，發(fā)往同一 Partition 的消息會(huì)附帶 Sequence Number。而Broker 端會(huì)對(duì)做緩存，當(dāng)具有相同主鍵的消息提交時(shí)，Broker只會(huì)持久化一條。

? 但是 PID重啟就會(huì)變化，同時(shí)不同的 Partition 也具有不同主鍵，所以冪等性無法保證跨分區(qū)跨會(huì)話的 Exactly Once。

3.3 kafka消費(fèi)者

3.3.1 消費(fèi)方式

? consumer 采用 pull (拉) 模式從 broker 中讀取數(shù)據(jù)。 ? push(推)模式很難適應(yīng)消費(fèi)速率不同的消費(fèi)者,因?yàn)橄l(fā)送速率是由 broker 決定的它的目標(biāo)是盡可能以最快速度傳遞消息，但是這樣很容易造成 consumer 來不及處理消息典型的表現(xiàn)就是拒絕服務(wù)以及網(wǎng)絡(luò)擁塞。而 pull 模式則可以根據(jù) consumer 的消費(fèi)能力以適當(dāng)?shù)乃俾氏M(fèi)消息?！?? pull 模式不足之處是，如果 kafka 沒有數(shù)據(jù)，消費(fèi)者可能會(huì)陷入循環(huán)中，一直返回空數(shù)據(jù)。針對(duì)這一點(diǎn)，Kafka 的消費(fèi)者在消費(fèi)數(shù)據(jù)時(shí)會(huì)傳入一個(gè)時(shí)長參數(shù) timeout，如果當(dāng)前沒有數(shù)據(jù)可供消費(fèi)，consumer 會(huì)等待一段時(shí)間之后再返回，這段時(shí)長即為 timeout。

3.3.2 分區(qū)分配策略

? 一個(gè)consumer group 中有多個(gè) consumer，一個(gè) topic 有多個(gè) partition，所以必然會(huì)涉及到partition的分配問題，即確定那個(gè) partition 由哪個(gè)consumer 來消費(fèi)。Kafka 有兩種分配策略，一是 RoundRobin（按組），一是 Range（按主題）。

3.3.3 高效讀寫

1）順序?qū)懘疟P

? Kafka的 producer 生產(chǎn)數(shù)據(jù)，要寫入到 log 文件中，寫的過程是一直追加到文件末端,為順序?qū)憽９倬W(wǎng)有數(shù)據(jù)表明，同樣的磁盤，順序?qū)懩艿?600M/s，而隨機(jī)寫只有 100K/s。這與磁盤的機(jī)械機(jī)構(gòu)有關(guān)，順序?qū)懼钥欤且驗(yàn)槠涫∪チ舜罅看蓬^尋址的時(shí)間。

2）zookeeper的作用

Kafka 集群中有一個(gè) broker 會(huì)被選舉為 Controller，負(fù)責(zé)管理集群 broker 的上下線，所有 topic 的分區(qū)副本分配和 leader 選舉等工作?！?/p>

Controller 的管理工作都是依賴于 Zookeeper 的。

柚子快報(bào)激活碼778899分享：學(xué)習(xí) 筆記 kafka架構(gòu)深入

http://yzkb.51969.com/

參考文章