柚子快報激活碼778899分享：學習 筆記 kafka架構深入

http://yzkb.51969.com/

kafka架構

3.1 kafka工作流程及文件存儲

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

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

3.2 kafka生產(chǎn)者

3.2.1 分區(qū)策略

1）分區(qū)的原因

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

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

2）分區(qū)的原則

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

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

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

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

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

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

ISR

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

ack應答機制

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

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

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

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

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

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

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

(2)leader 故障

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

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

3.2.4 exactly once

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

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

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

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

3.3 kafka消費者

3.3.1 消費方式

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

3.3.2 分區(qū)分配策略

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

3.3.3 高效讀寫

1）順序?qū)懘疟P

? Kafka的 producer 生產(chǎn)數(shù)據(jù)，要寫入到 log 文件中，寫的過程是一直追加到文件末端,為順序?qū)?。官網(wǎng)有數(shù)據(jù)表明，同樣的磁盤，順序?qū)懩艿?600M/s，而隨機寫只有 100K/s。這與磁盤的機械機構有關，順序?qū)懼钥?，是因為其省去了大量磁頭尋址的時間。

2）zookeeper的作用

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

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

柚子快報激活碼778899分享：學習 筆記 kafka架構深入

http://yzkb.51969.com/

參考文章