詳解Kafka如何保證消息可靠性

????????Kafka 通過多個環節的精心設計和配置，能夠提供高可靠的消息傳遞保證，最大限度地減少消息丟失的可能性。這需要生產者、Broker 和消費者三方的協同配置才能實現端到端的不丟失。以下是關鍵機制：

一、核心原則：副本機制 (Replication)

????????這是 Kafka 高可靠性的基石。每個主題分區（Partition）可以有多個副本（Replica），分布在不同的 Broker 上。其中一個副本是 Leader，負責處理讀寫請求；其他副本是 Follower，從 Leader 復制數據。

二、生產者 (Producer) 端保證：確保消息成功寫入 Broker

2.1?acks?配置 (確認機制):

  • acks=0:?風險最高。生產者發送消息后不等待 Broker 任何確認。如果 Broker 沒收到或寫入失敗，消息即丟失。

  • acks=1:?默認值。生產者等待 Leader 副本成功寫入本地日志即返回確認。如果 Leader 寫入后但 Follower 尚未開始復制（或復制很少）時 Leader 崩潰，新 Leader 可能不包含這條消息（如果它不在 ISR 中），則消息丟失。

  • acks=all?(或?acks=-1):?最安全。生產者等待 Leader 收到消息，并且所有處于 ISR (In-Sync Replicas) 列表中的 Follower 副本都成功復制了該消息后，才返回確認。即使 Leader 立即崩潰，新 Leader 也一定包含這條消息（因為它在所有 ISR 中都已存在）。

  • 關鍵配置：?acks=all?是防止生產者端消息丟失的核心配置。

2.2?重試機制 (retries):

  • 設置?retries?> 0 (默認?retries=INTEGER_MAX_VALUE)，允許生產者在遇到可重試錯誤（如網絡抖動、Leader 選舉）時自動重試發送消息。

  • 結合?retry.backoff.ms（默認100）?設置合理的重試間隔。

2.3?同步發送或正確處理回調：

  • 同步發送 (send().get()):?阻塞直到收到確認。簡單但性能低。

  • 異步發送 (send(..., Callback)):?性能高，但必須實現并正確處理?Callback。在?onCompletion()?方法中檢查?exception != null，根據業務邏輯進行重試或記錄錯誤。忽略回調會導致發送失敗而不知情。

2.4 冪等生產者 (Idempotent Producer) (Kafka >= 0.11):

  • 設置?enable.idempotence=true（默認開啟）。

  • 防止生產者重試時導致的消息重復（即使 Broker 收到多次相同的消息，也只寫入一次）。

  • 雖然主要解決重復問題，但簡化了重試邏輯，間接提高了可靠性（可以更安全地無限重試）。

2.5?事務生產者 (Transactional Producer) (Kafka >= 0.11):

  • 用于實現跨分區或“精確一次”語義的場景。

  • 在需要將消息發送和消費者位移提交綁定在一個原子操作時特別有用，防止“消費-處理-生產”模式中的丟失或重復。

三、Broker 端保證：確保消息持久化存儲和可用

3.1?副本機制與 ISR:

  • replication.factor?>= 3：通常設置為 3，意味著每個分區有 1 個 Leader 和 2 個 Follower。提供冗余。

  • ISR (In-Sync Replicas):?Leader 維護一個與其同步的 Follower 副本列表。Follower 需要在一定時間(replica.lag.time.max.ms)(默認：30 seconds)內追上 Leader 最新的位移才能留在 ISR 中。

  • unclean.leader.election.enable = false(默認)：至關重要！禁止從非 ISR 副本中選舉 Leader。如果設置為?true，當所有 ISR 副本都宕機時，一個落后的非 ISR 副本可能成為新 Leader，導致丟失那些未復制到該副本的最新消息。

3.2?min.insync.replicas?配置:

  • 當生產者設置?acks=all?時，此配置才生效。

  • 它定義了成功寫入的副本數（包括 Leader）的最小值，Broker 才會認為?acks=all?的寫入請求是成功的。

  • 例如，設置?min.insync.replicas=2。這意味著：

    • 如果 ISR 中有 >=2 個副本（包括 Leader），生產者?acks=all?的寫入需要至少成功寫入 2 個副本（Leader + 1 Follower）才算成功。

    • 如果 ISR 中只剩 1 個副本（Leader），那么即使生產者設置?acks=all，Broker 也無法滿足?min.insync.replicas=2?的要求，寫入會失敗（拋出?NotEnoughReplicasException?或其子類），從而避免在只有一個副本存活時寫入導致的高丟失風險。

  • 最佳實踐：?min.insync.replicas = replication.factor - 1?(例如 RF=3, min.insync=2)。這樣允許最多 1 個 Broker 宕機而不影響寫入可用性，同時保證至少有兩個副本（包括 Leader）持有數據。

3.3?持久化存儲：

  • Kafka 依賴操作系統的頁緩存 (Page Cache)?進行高性能寫入。消息首先寫入頁緩存。

  • Broker 配置?log.flush.interval.messages?和?log.flush.interval.ms?控制強制將頁緩存中的數據刷盤 (fsync)?到物理磁盤的頻率。默認 Kafka 依賴操作系統后臺刷盤。

  • 可靠性權衡：?更頻繁的刷盤（如每條消息或每秒）減少崩潰時丟失窗口期，但極大降低吞吐量。Kafka 的設計理念是依賴多副本冗余來保證高可用和持久化，而非單個 Broker 的磁盤強一致性。在副本數足夠且?min.insync.replicas?配置合理的情況下，即使單個 Broker 崩潰丟失未刷盤數據，數據依然可以從其他副本恢復。

3.4 Leader 均衡：

  • 確保 Leader 分區在 Broker 間分布均勻，避免單個 Broker 成為瓶頸或單點故障影響范圍過大。

四、消費者 (Consumer) 端保證：確保消息被成功處理

4.1?手動提交位移 (Disable Auto-Commit):

  • 設置?enable.auto.commit=false（默認為true）。這是防止消費者端丟失消息的關鍵。

  • 自動提交 (enable.auto.commit=true) 在后臺周期性地提交位移。如果在提交間隔內消費者崩潰，或者位移提交后但在處理完該位移之前的消息之前消費者崩潰，會導致：

    • 消息丟失：?崩潰時正在處理但尚未提交位移的消息，在新進程啟動或再均衡后會從上次提交的位移開始消費，這些消息永遠不會被處理。

    • 消息重復：?提交位移后但在處理消息前崩潰，消息會被重新消費。

  • 最佳實踐：?在消息被成功處理后（例如，業務邏輯完成、數據安全落庫），手動提交位移。

4.2 正確處理位移提交時機和順序：

  • 同步提交 (commitSync()):?阻塞直到提交成功或遇到不可恢復錯誤。簡單可靠，但影響吞吐。

  • 異步提交 (commitAsync()):?非阻塞，性能好。但必須提供回調?(OffsetCommitCallback) 來處理提交失敗（如網絡問題、再均衡）。在回調中應實現重試邏輯（注意：異步提交的重試可能導致位移覆蓋，需謹慎處理順序）。

  • 順序保證：?位移提交的順序必須與消息處理的順序一致。通常建議在單線程中順序處理消息并在處理成功后立即提交（或累積一批后提交），避免多線程處理導致位移提交超前于實際處理進度。

4.3?處理再均衡 (Rebalance) -?ConsumerRebalanceListener:

  • 當消費者組內成員變化（加入、離開、崩潰）或訂閱主題分區變化時，會發生再均衡，分區會被重新分配。

  • 實現?ConsumerRebalanceListener?接口：

    • onPartitionsRevoked(Collection): 在分區被回收前調用。在此方法中提交已處理消息的位移（同步提交?commitSync()?最安全），確保回收的分區上已處理的消息位移被提交。

    • onPartitionsAssigned(Collection): 在獲得新分區分配后調用。通常用于初始化狀態（如數據庫連接）。

五、總結：端到端不丟失的最佳實踐配置

環節關鍵配置/實踐說明
生產者acks=all必須等待所有 ISR 副本確認
retries?設為較大值 (如?Integer.MAX_VALUE)無限重試可恢復錯誤
正確處理異步發送的回調 / 或使用同步發送確保發送失敗能被感知并處理
enable.idempotence=true?(Kafka >= 0.11)防止重試導致重復 (間接提升可靠性)
Brokerreplication.factor >= 3?(推薦)提供足夠副本冗余
min.insync.replicas = replication.factor - 1?(如 RF=3 則設 2)定義?acks=all?成功所需的最小同步副本數
unclean.leader.election.enable = false禁止從非同步副本選 Leader，防止數據丟失
消費者enable.auto.commit=false禁用自動提交位移
在處理消息后手動提交位移?(commitSync()?或帶回調/重試的?commitAsync())確保只有成功處理的消息才提交位移
實現?ConsumerRebalanceListener，在?onPartitionsRevoked?中同步提交位移應對再均衡，防止分區被回收時位移未提交
保證位移提交順序與消息處理順序一致避免位移提交超前導致未處理消息被跳過

重要提醒：

  • “不丟失”是相對的：?在極端故障場景下（如所有副本所在的 Broker 同時永久損壞），數據仍然可能丟失。Kafka 提供的是極高的持久性保證，而非絕對。

  • 性能與可靠性的權衡：?更高的可靠性配置（如?acks=all,?min.insync.replicas=2, 同步提交/刷盤）通常會降低吞吐量和增加延遲。需要根據業務需求進行權衡。

  • 監控：?密切監控 Kafka 集群健康（Broker 狀態、ISR 收縮、Under Replicated Partitions）、生產者錯誤率/重試率、消費者 Lag (滯后) 和提交失敗情況。

  • 測試：?模擬各種故障場景（Broker 宕機、網絡分區、消費者崩潰、再均衡）以驗證系統的健壯性。

本文來自互聯網用戶投稿，該文觀點僅代表作者本人，不代表本站立場。本站僅提供信息存儲空間服務，不擁有所有權，不承擔相關法律責任。
如若轉載，請注明出處：http://www.pswp.cn/pingmian/87259.shtml
繁體地址，請注明出處：http://hk.pswp.cn/pingmian/87259.shtml
英文地址，請注明出處：http://en.pswp.cn/pingmian/87259.shtml

如若內容造成侵權/違法違規/事實不符，請聯系多彩編程網進行投訴反饋email:809451989@qq.com，一經查實，立即刪除！

相關文章

華為云Flexus+DeepSeek征文 | Word辦公軟件接入華為云ModelArts Studio大模型，實現AI智能辦公

華為云Flexus+DeepSeek征文 | Word辦公軟件接入華為云ModelArts Studio大模型，實現AI智能辦公

前言 在數字化辦公時代，人工智能技術正深刻改變著傳統辦公軟件的使用體驗和功能邊界。將 Word 辦公軟件與華為云 ModelArts Studio 大模型進行深度融合，借助 AI 的強大能力實現智能化優化，不僅能大幅提升辦公效率，還能為用戶帶來…
閱讀更多...
基于開源AI大模型AI智能名片S2B2C商城小程序的流量轉化與價值沉淀研究

基于開源AI大模型AI智能名片S2B2C商城小程序的流量轉化與價值沉淀研究

摘要：在數字化商業生態中，公域流量轉化已成為企業競爭的核心戰場。本文以開源AI大模型AI智能名片S2B2C商城小程序為研究對象，結合服裝、健康食品、快時尚等行業的實踐案例，系統分析其通過技術賦能實現精準獲客、用戶留存與商業閉環…
閱讀更多...
創客匠人拆解知識變現困局：創始人 IP 打造的底層邏輯與實踐路徑

創客匠人拆解知識變現困局：創始人 IP 打造的底層邏輯與實踐路徑

在知識付費行業競爭愈發激烈的當下，許多內容創作者面臨 “流量增長停滯、變現效率低下” 的困境。創客匠人通過對 5 萬 知識博主的服務經驗，總結出創始人 IP 打造與知識變現的底層邏輯 —— 其核心在于將 “個人影響力” 轉化為 “商業閉環”&#xff0…
閱讀更多...
LabVIEW遠程面板交互控制

LabVIEW遠程面板交互控制

基于LabVIEW 遠程面板（Remote Panel）技術，實現服務器端 VI 與客戶端的遠程交互控制，涵蓋服務器配置、客戶端連接請求、VI 執行狀態監測及控制權交接等流程，支持跨 LabVIEW 實例（可跨設備）的遠程…
閱讀更多...
S7-1200 CPU 與 CP343-1 S7 通信（S7-1200 作為服務器）

S7-1200 CPU 與 CP343-1 S7 通信（S7-1200 作為服務器）

S7-1200 CPU 與 CP343-1 S7 通信（S7-1200 作為服務器） S7-1200 CPU 與 CP343-1 之間的以太網通信通過 S7 通信來實現。當 CP343-1（至少標準版）作為客戶端，S7-1200 作為服務器，需在客戶端單邊組態連接和編程…
閱讀更多...
旋轉不變子空間( ESPRIT) 算法

旋轉不變子空間( ESPRIT) 算法

旋轉不變子空間( ESPRIT) 算法 1.1 ESPRIT 算法模型 以均勻線陣為研究背景，假設有陣元數為，陣元間距為的平面等間距線性天線陣列。設窄帶遠場信號的 DOA 估計的數學模型為 (1) 式中，為陣列流型陣( 導向矢量陣) 。 1.2 ESPRIT 算法原理 …
閱讀更多...
HarmonyOS學習記錄1

HarmonyOS學習記錄1

HarmonyOS學習記錄1 本文為個人學習記錄，僅供參考，如有錯誤請指出。本文主要記錄HarmonyOS基礎概念合核心技術理念。 核心技術理念： 一次開發，多端部署： 其含義是一套代碼工程，一次開發上架，…
閱讀更多...
C++特殊類設計 單例模式

C++特殊類設計 單例模式

在C編程中，特殊類設計和單例模式是兩個非常重要的高級主題。特殊類設計涉及到一些特定功能類的實現，如不可拷貝類、不可移動類等。而單例模式是一種創建型設計模式，保證一個類只有一個實例，并提供全局訪問點。本文將詳細介紹這兩個…
閱讀更多...
springboot集成達夢數據庫，取消MySQL數據庫，解決問題和沖突

springboot集成達夢數據庫，取消MySQL數據庫，解決問題和沖突

一、驅動與連接配置 更換JDBC驅動 在pom.xml中移除MySQL驅動&#xff0c;添加達夢驅動&#xff08;版本根據DM數據庫選擇&#xff09;&#xff1a; <dependency><groupId>com.dameng</groupId><artifactId>DmJdbcDriver</artifactId><versi…
閱讀更多...
Git 使用快速入門：從基礎命令到倉庫管理全解析

Git 使用快速入門：從基礎命令到倉庫管理全解析

Git 使用快速入門&#xff1a;從基礎命令到倉庫管理全解析 在軟件開發和團隊協作的世界里&#xff0c;版本控制系統是不可或缺的工具。而 Git&#xff0c;憑借其強大的功能、高效的性能以及分布式的特性&#xff0c;已然成為當下最受歡迎的版本控制系統。無論是個人開發者管理項…
閱讀更多...
Go語言項目工程化 —— 日志、配置、錯誤處理規范

Go語言項目工程化 —— 日志、配置、錯誤處理規范

在Go語言中&#xff0c;項目工程化的日志、配置、錯誤處理規范是保障項目可維護性、可觀測性與健壯性的核心實踐之一。本章將從三個方面進行詳解&#xff1a; 一、日志規范 1. 日志的重要性 ? 問題排查的唯一“現場還原”? 性能瓶頸的定位手段? 安全審計的依據 2. 日志庫…
閱讀更多...
day58python打卡

day58python打卡

知識點回顧&#xff1a; 時序建模的流程時序任務經典單變量數據集ARIMA&#xff08;p&#xff0c;d&#xff0c;q&#xff09;模型實戰SARIMA摘要圖的理解處理不平穩的2種差分 n階差分---處理趨勢季節性差分---處理季節性 建立一個ARIMA模型&#xff0c;通常遵循以下步驟&…
閱讀更多...
centos9安裝

centos9安裝

centos-stream-9-stream-BaseOS-x86_64-iso安裝包下載_開源鏡像站-阿里云 用NAT 默認root用戶不能登錄 vim /etc/ssh/sshd_config PermitRootLogin yes 去掉注釋,改為yes 這樣root用戶可以登錄 因為用的NAT模式 這樣可以通過宿主機的50022端口訪問虛擬機 宿主機 ipconfig…
閱讀更多...
60天python訓練營打卡day‘47

60天python訓練營打卡day‘47

學習目標&#xff1a; 60天python訓練營打卡 學習內容&#xff1a; DAY 47 注意力熱圖可視化 昨天代碼中注意力熱圖的部分順移至今天 知識點回顧&#xff1a; 熱力圖 學習時間&#xff1a; 2025.06.30 浙大疏錦行
閱讀更多...
GO字符串處理面試題及參考答案（精選60道題）

GO字符串處理面試題及參考答案（精選60道題）

如何將一個字符串反轉？實現 Reverse("abc") => "cba" 在Go語言中實現字符串反轉需要考慮字符串的編碼方式。Go語言的字符串是基于UTF-8編碼的，而UTF-8是一種變長編碼，每個Unicode碼點（rune）可能由1到4個字節表示。因此，簡單地按字節反轉會破壞多字…
閱讀更多...
在線swagger 導出 PDF文檔

在線swagger 導出 PDF文檔

1.獲取swagger文檔json 點擊左上角的url&#xff0c;下載json文件 2.apifox轉換JSON到Markdown json文件導入 MD文件導出 3.用Mark Text 導入后轉換成PDF
閱讀更多...
【Linux基礎知識系列】第四十篇 - 定制彩色終端與 Prompt

【Linux基礎知識系列】第四十篇 - 定制彩色終端與 Prompt

在使用Linux終端時&#xff0c;一個清晰、易讀且個性化的命令提示符&#xff08;Prompt&#xff09;可以顯著提升工作效率和用戶體驗。通過定制終端的顏色和提示符&#xff0c;用戶可以更直觀地獲取系統信息&#xff0c;同時也能讓終端界面更具個性化。本文將介紹如何通過PS1變…
閱讀更多...
Spark從入門到熟悉（篇二）

Spark從入門到熟悉（篇二）

本文介紹Spark的RDD編程&#xff0c;并進行實戰演練&#xff0c;加強對編程的理解&#xff0c;實現快速入手 知識脈絡 包含如下8部分內容&#xff1a; 創建RDD 常用Action操作 常用Transformation操作 針對PairRDD的常用操作 緩存操作 共享變量 分區操作 編程實戰 創…
閱讀更多...
ADSP-CM408CSWZ-BF高精度ADI雙核精密控制神器 賦能工業4.0核心系統！

ADSP-CM408CSWZ-BF高精度ADI雙核精密控制神器 賦能工業4.0核心系統！

ADSP-CM408CSWZ-BF&#xff08;ADI&#xff09;產品解析與推廣文案 1. 產品概述 ADSP-CM408CSWZ-BF 是 Analog Devices Inc.&#xff08;ADI&#xff09; 推出的一款 混合信號控制處理器&#xff0c;屬于 ADSP-CM40x系列&#xff0c;集成了 雙核ARM Cortex-M4 高精度ADC&…
閱讀更多...
Unity GPU Timeline性能熱點分析與優化指南

Unity GPU Timeline性能熱點分析與優化指南

一、GPU Timeline技術背景與性能挑戰 1. GPU Timeline核心架構 層級組件性能影響應用層PlayableGraph指令生成效率驅動層CommandBuffer提交開銷硬件層GPU管線并行利用率 2. 典型性能瓶頸 圖表 代碼 下載 性能問題 過度繪制 資源切換 同步等待 FillRate受限 狀態切換…
閱讀更多...
最新文章

Copyright @ 2022~2023