本節主要內容

數據寫入流程

分區策略

ACK應答機制

leader異常處理

follower異常處理

數據寫入流程

數據寫入流程(圖1)

1、確定分區，producer確認數據寫入哪個分區

2、發送數據，到leader分區

3、leader寫入完成，follower分區從leader分區拉取數據

4、確定數據是否寫入成功

成功

5、返回ack給producer

6、producer接收到ack，數據寫入成功，繼續發送下一批數據

失敗

7、數據沒有寫入成功，producer重發數據

圖1

分區策略

分區原因

1、方便擴展

2、提高并發

分區原則

1、指明partition的情況下，直接發送數據到對應的partition

2、沒有指明partition，但有key的情況下，將key的hash值與topic的partition數進行取余得到partition值。

3、既沒有指明partition，又沒有key的情況下，第一次隨機生成一個整數，之后每次調用都在這個整數上自增，將該值與可用的partitions總數取余得到partition值，即round-robin算法

ACK應答機制

acks參數配置，提供以下三個選項

0：producer不等待ack，不管是否寫入成功，能提供最低延遲，會丟數據

1：producer等待ack，leader寫入成功返回ack，不管follower是否寫入成功，會丟失數據

-1：producer等待ack，leader和follower全部寫入成功返回ack，極端情況下，如果follower同步完成后，發送ack之前，leader發生故障，會造成數據重復。

leader異常情況處理

leader異常，需要解決兩個問題

1.讀一致性

2. 寫一致性

先解釋兩個概念： LEO與HW(圖2)

LEO - Log End Offset，每個副本最后一個offset

HW - High Watermark，所有副本中，最小的LEO

圖2

leader異常，讀一致性問題(圖3)

問題描述

leader和follower當前存儲數據狀況：leader當前數據記錄到 9, follower 0同步完成7, follower 1同步完成8

1、consumer從leader讀取數據消費到9

2、leader故障

3、重新選舉follower1 為leader

新leader中記錄數據只到8，消費者無法繼續消費9以后的數據

解決方案

Consumer只能讀取 HW之前的數據，當leader發生故障時，不會影響consumer讀取數據

圖3

leader異常，寫一致性問題(圖4)

問題描述

1、leader故障

2、重新選舉follower1 為leader

3、原來的leader恢復正常，變為follower 1，此刻，其數據是9，大于新leader的8

這種情況下follower如何從leader同步數據？

解決方案

4、follower 1讀取HW，將HW這后的數據刪除，從leader拉取數據，起始位置為8

圖4

follower異常(圖5)

問題描述

ack配置為-1時，需要確定所有follower寫成功才能返回ack，如果單個follower掛掉，leader需要一直等待，直到follower寫入成功，影響數據寫入

解決方案

Leader動態維護ISR(in-sync replica set)，記錄和leader保持正常同步的follower集合，保證ISR中的follower全部寫入成功即可發送ack。

當follower在限定時間內(通過參數replica.log.time.max.ms配置)未從leader拉取數據，則該follower將被踢出ISR。

處理流程

1、leader寫入數據完成，follower開始從leader拉取數據

2、follower 1異常，不能從leader正常拉取數據

3、leader在限定時間內未收到follower 1同步請求，確定follower 1異常，從ISR中移除follower 1

4、follower 0完成同步，ISR中記錄的follower全部成功

5、返回ack給producer

數據寫入成功，繼續發送下一批次數據

圖5

學習交流，如有問題，請指證，感謝！！！

總結

以上是生活随笔為你收集整理的拉取数据_Apache Kafka-数据写入过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。