Kafka的ACK参数详解及ISR、HW、LEO介绍

在介绍ACK参数之前,先介绍几个概念

基本概念topic、partition、replication、leader、follower
对于kafka的每一个topic,我们都可以设置他有几个Partition,每个Partition负责存储这个Topic一部分的数据。然后Kafka的Broker集群中,每台机器上都存储了一些Partition,也就存放了Topic的一部分数据,这样就实现了Topic的数据分布式存储在一个Broker集群上。每个Partition都可以有多个副本,其中一个副本叫做leader,其他的副本叫做follower。这样的多副本冗余机制,可以保证任何一台机器挂掉,都不会导致数据彻底丢失,因为起码还是有副本在别的机器上的。KAFKA中任何一个Partition,只有Leader是对外提供读写服务的。也就是说,如果有一个客户端往一个Partition写入数据,此时就是写入这个Partition的Leader副本。然后Leader副本接收到数据之后,Follower副本会不停的给他发送请求尝试去拉取最新的数据,拉取到自己本地后,写入磁盘中。

什么是ACK?
ACK (Acknowledge character)即是确认字符,在数据通信中,接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。在TCP/IP协议中,如果接收方成功的接收到数据,那么会回复一个ACK数据。通常ACK信号有自己固定的格式,长度大小,由接收方回复给发送方。

什么是ISR?
ISR全称是“In-Sync Replicas”,也就是保持同步的副本,他的含义就是,跟Leader始终保持同步的Follower有哪些。所以每个Partition都有一个ISR,这个ISR里一定会有Leader自己,因为Leader肯定数据是最新的,然后就是那些跟Leader保持同步的Follower,也会在ISR里。Leader负责跟踪与维护ISR列表。如果一个 Follower 宕机,或者落后太多(落后多少,由参数replica.lag.time.max.ms控制),Leader 将把它从 ISR 中移除。如果Leader发生故障或挂掉,一个新Leader被选举并被接受客户端的消息成功写入。Kafka确保从同步副本列表中选举一个副本为Leader,新的Leader继续服务客户端的读写请求。

什么是HW?
HW俗称高水位,是HighWatermark的缩写。它标识了一个特定的消息偏移量(offset),消费者只能拉取到这个offset之前的消息。

什么是LEO?
LEO (Log End Offset),标识当前日志文件中下一条待写入的消息的offset。LEO 的大小相当于当前日志分区中最后一条消息的offset值加1.分区 ISR 集合中的每个副本都会维护自身的 LEO ,而 ISR 集合中最小的 LEO 即为分区的 HW,对消费者而言只能消费 HW 之前的消息。


下面具体分析一下 ISR 集合和 HW、LEO的关系。
假设某分区的 ISR 集合中有 3 个副本,即一个 leader 副本和 2 个 follower 副本,此时分区的 LEO 和 HW 都分别为 3 。消息3和消息4从生产者出发之后先被存入leader副本。

 

在消息被写入leader副本之后,follower副本会发送拉取请求来拉取消息3和消息4进行消息同步。

在同步过程中不同的副本同步的效率不尽相同,在某一时刻follower1完全跟上了leader副本而follower2只同步了消息3,如此leader副本的LEO为5,follower1的LEO为5,follower2的LEO 为4,那么当前分区的HW取最小值4,此时消费者可以消费到offset0至3之间的消息。

当所有副本都成功写入消息3和消息4之后,整个分区的HW和LEO都变为5,因此消费者可以消费到offset为4的消息了。

 

由此可见kafka的复制机制既不是完全的同步复制,也不是单纯的异步复制。事实上,同步复制要求所有能工作的follower副本都复制完,这条消息才会被确认已成功提交,这种复制方式极大的影响了性能。而在异步复制的方式下,follower副本异步的从leader副本中复制数据,数据只要被leader副本写入就会被认为已经成功提交。在这种情况下,如果follower副本都还没有复制完而落后于leader副本,然后leader副本宕机,则会造成数据丢失。kafka使用这种ISR的方式有效的权衡了数据可靠性和性能之间的关系。

ACK参数
铺垫了这么多,最后进入主题,聊一聊ACK参数。acks参数是在KafkaProducer,也就是生产者客户端里设置的。request.required.acks表示多少副本收到消息之后,生产者才会认为这条消息是成功写入。 它涉及可靠性和吞吐量之间的权衡。他有三个值:
1:leader接收到消息并成功写入,即返回成功响应。
0:生产者发送消息之后,不需要等待任何服务器的响应。
-1(all):生产者发送消息之后,需要等待ISR中所有副本都成功写入消息才能收到服务端的成功响应。

举个例子,当acks参数设置为-1时,producer写入消息流程如下:

1)producer先从zookeeper的 "/brokers/.../state"节点找到该partition的leader

2)producer将消息发送给该leader

3)leader将消息写入本地log

4)followers从leader pull消息,写入本地log后向leader发送ACK

5)leader收到所有ISR中的replication的ACK后,增加HW(high watermark,最后commit 的offset)并向producer发送ACK
 

 

 

 

<think>嗯,用户现在想获取关于中间件的常见面试题或核心概念总结。首先,我需要确定中间件涉及的主要领域,比如消息队列、分布式系统、缓存、数据库中间件等。用户提供的引用中提到了Kafka、RabbitMQ和Spring,这些都属于中间件的一部分。 接下来,我应该整理核心概念。比如消息队列中的高可用机制、可靠性传输、协议支持等。Kafka的高可用是通过分区副本和ISR机制实现的,这点在引用[1]中提到过。而RabbitMQ使用镜像队列来保证高可用,引用[2]指出它是用Erlang编写的,支持AMQP协议。需要把这些关键点列出来。 然后,常见面试题方面,用户可能想知道不同中间件的对比,比如Kafka和RabbitMQ的区别。Kafka适合高吞吐量场景,而RabbitMQ适合低延迟和复杂路由。另外,消息丢失的问题也很重要,生产者、Broker、消费者三个环节都可能出问题,需要分别解释解决方案,比如确认机制、持久化、手动提交偏移量等。 另外,引用[4]提到了HWLEO的区别,这也是Kafka中常见的考点,需要详细说明。消费者维护HW来确保消费的位置,而LEO是日志末端的位置,这对数据一致性和可靠性很关键。 用户可能还关心事务消息的实现,比如RocketMQ的二阶段提交和状态回查。这部分需要简要说明流程,帮助用户理解如何保证消息的最终一致性。 在核心概念里,分布式系统的CAP理论是基础,需要解释每个中间件在CAP中的权衡。比如Kafka侧重可用性和分区容忍性,而RabbitMQ更注重一致性和可用性。 最后,生成相关问题时要覆盖用户提到的中间件类型,比如Redis、ZooKeeper、Dubbo等,确保覆盖面广,帮助用户全面准备面试。同时,注意引用对应的参考资料,如引用[4]关于HWLEO的部分,确保信息的准确性。 总结下来,回答需要结构清晰,分点列出核心概念和常见问题,每个部分用简短的例子或机制说明,并自然地添加引用标注。这样用户能快速抓住重点,应对面试中的各种问题。</think># 中间件核心概念与面试题总结 --- ## 一、核心概念总结 ### 1. 消息队列核心机制 - **高可用机制** Kafka通过分区副本(Replica)和ISR(In-Sync Replica)机制实现高可用,当Leader副本故障时,Controller会从ISR列表中选举新Leader[^1]; RabbitMQ采用镜像队列(Mirrored Queue)实现高可用,队列数据在集群节点间同步[^2]。 - **可靠性传输** Kafka通过HW(High Watermark)和LEO(Log End Offset)管理消费进度,HW表示已提交的偏移量,LEO表示分区最新消息位置[^4]; RabbitMQ通过消息确认机制(ACK)保障可靠性,生产者需等待Broker确认,消费者手动ACK避免消息丢失[^2]。 ### 2. 分布式系统理论 - **CAP理论** 中间件需在一致性(Consistency)、可用性(Availability)、分区容忍性(Partition Tolerance)中权衡。例如: - Kafka优先满足AP(高可用+分区容忍) - ZooKeeper优先满足CP(一致性+分区容忍) --- ## 二、常见面试题解析 ### 1. Kafka vs RabbitMQ核心区别 | **维度** | **Kafka** | **RabbitMQ** | |-----------------|------------------------------------|-----------------------------------| | 设计目标 | 高吞吐量、日志处理 | 低延迟、复杂路由 | | 协议支持 | 自定义协议 | 支持AMQP、STOMP等 | | 消息存储 | 持久化到磁盘,长期保留 | 内存存储为主,支持持久化 | | 消费模式 | 消费者主动拉取(Pull) | Broker主动推送(Push) | ### 2. 如何避免消息丢失? - **生产者端**:启用`acks=all`参数,等待所有副本确认写入; - **Broker端**:设置`min.insync.replicas`最小同步副本数,防止数据丢失[^4]; - **消费者端**:关闭自动提交偏移量,业务处理完成后手动提交。 ### 3. 事务消息如何实现?(以RocketMQ为例) 1. 生产者发送半事务消息到Broker; 2. 执行本地事务并提交事务状态; 3. Broker通过二阶段提交(2PC)和事务状态回查机制保证最终一致性。 --- ## 三、扩展知识点 ### 1. 缓存中间件(Redis) - **缓存雪崩**:随机设置过期时间 + 多级缓存; - **缓存穿透**:布隆过滤器(Bloom Filter)拦截非法请求; - **数据一致性**:延迟双删策略(先删缓存→更新DB→再删缓存)。 ### 2. 服务治理中间件(ZooKeeper/Dubbo) - **服务注册与发现**:ZooKeeper通过临时节点(Ephemeral Node)感知服务状态; - **负载均衡**:Dubbo支持随机、轮询、一致性哈希等算法。 ---
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

伊一cherry大数据

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值