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