kafka消费端提交offset的方式

Kafka 提供了 3 种提交 offset 的方式

  1. 自动提交

复制

1234
// 自动提交,默认trueprops.put("enable.auto.commit", "true");// 设置自动每1s提交一次props.put("auto.commit.interval.ms", "1000");
  1. 手动同步提交 offset

复制

1
consumer.commitSync();
  1. 手动异步提交 offset

复制

1
consumer.commitAsync();

上面说了既然异步提交 offset 可能会重复消费, 那么我使用同步提交是否就可以表明这个问题呢?

复制

1234567
while(true) {  ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(100));  records.forEach(record -> {      insertIntoDB(record);      consumer.commitSync();  });}

很明显不行, 因为 insertIntoDB 和 commitSync() 做不到原子操作, 如果 insertIntoDB() 成功了,但是提交 offset 的时候 consumer 挂掉了,然后服务器重启,仍然会导致重复消费问题。

如何做到不重复消费?

只要保证处理消息和提交 offset 得操作是原子操作,就可以做到不重复消费。我们可以自己管理 committed offset, 而不让 kafka 来进行管理。

比如如下使用方式:

  1. 如果消费的数据刚好需要存储在数据库,那么可以把 offset 也存在数据库,就可以就可以在一个事物中提交这两个结果,保证原子操作。
  2. 借助搜索引擎,把 offset 和数据一起放到索引里面,比如 Elasticsearch

每条记录都有自己的 offset, 所以如果要管理自己的 offset 还得要做下面事情

  1. 设置 enable.auto.commit=false
  2. 使用每个 ConsumerRecord 提供的 offset 来保存消费的位置。
  3. 在重新启动时使用 seek(TopicPartition, long) 恢复上次消费的位置。

通过上面的方式就可以在消费端实现”Exactly Once” 的语义, 即保证只消费一次。但是是否真的需要保证不重复消费呢?这个得看具体业务, 重复消费数据对整体有什么影响在来决定是否需要做到不重复消费。

原文地址:https://www.cnblogs.com/doit8791/p/11312979.html

时间: 2024-10-03 22:07:38

kafka消费端提交offset的方式的相关文章

RabbitMQ消费端消息的获取方式(.Net Core)

1[短链接]:BasicGet(String queue, Boolean autoAck) 通过request的方式独自去获取消息,断开式,一次次获取,如果返回null,则说明队列中没有消息. 隐患:每次获取消息都会创建channel. 优点:最安全的获取方式且性能不算太差. 2[长链接]: 1).EventingBasicConsumer[订阅式] 使用这种方式消息会全部打入当前消费者中,不管是否启用确认机制. 隐患:①根据消息的长短多少将影响当前消费者的占用资源. ②如果当前消费者挂掉,那

分享一些 Kafka 消费数据的小经验

前言 之前写过一篇<从源码分析如何优雅的使用 Kafka 生产者> ,有生产者自然也就有消费者. 建议对 Kakfa 还比较陌生的朋友可以先看看. 就我的使用经验来说,大部分情况都是处于数据下游的消费者角色.也用 Kafka 消费过日均过亿的消息(不得不佩服 Kakfa 的设计),本文将借助我使用 Kakfa 消费数据的经验来聊聊如何高效的消费数据. 单线程消费 以之前生产者中的代码为例,事先准备好了一个 Topic:data-push,3个分区. 先往里边发送 100 条消息,没有自定义路由

Kafka在高并发的情况下,如何避免消息丢失和消息重复?kafka消费怎么保证数据消费一次?数据的一致性和统一性?数据的完整性?

1.kafka在高并发的情况下,如何避免消息丢失和消息重复? 消息丢失解决方案: 首先对kafka进行限速, 其次启用重试机制,重试间隔时间设置长一些,最后Kafka设置acks=all,即需要相应的所有处于ISR的分区都确认收到该消息后,才算发送成功 消息重复解决方案: 消息可以使用唯一id标识 生产者(ack=all 代表至少成功发送一次) 消费者 (offset手动提交,业务逻辑成功处理后,提交offset) 落表(主键或者唯一索引的方式,避免重复数据) 业务逻辑处理(选择唯一主键存储到R

关于IDEA开发环境下的Kafka+Spark Streaming的classpath配置方式

一.前言 在使用Spark Streaming中的Kafka Direct API进行Kafka消费的过程中,通过spark-submit的方式提交jar包,会出现如下错误信息,提示无法找到KafkaUtils. Exceptionin thread "main" java.lang.NoClassDefFoundError: org/apache/spark/streaming/kafka/KafkaUtils$ at com.zhkmxx.scala.app.KafkaStream

Dubbo高级篇_10_Dubbo消费端直连服务提供者(开发调试)

直连提供者 (+) (#) 在开发及测试环境下,经常需要绕过注册中心,只测试指定服务提供者,这时候可能需要点对点直连, 点对点直联方式,将以服务接口为单位,忽略注册中心的提供者列表, A接口配置点对点,不影响B接口从注册中心获取列表. (1) 如果是线上需求需要点对点,可在<dubbo:reference>中配置url指向提供者,将绕过注册中心,多个地址用分号隔开,配置如下:(1.0.6及以上版本支持) <dubbo:reference id="xxxService"

Dubbo服务提供端与消费端应用的搭建

Demo结构介绍 Demo使用Maven聚合功能,里面有三个模块,目录如下: 其中Consumer模块为服务消费者,里面TestConsumer和consumer.xml组成了基于Spring配置方式的服务调用,TestConsumerApi是基于Dubbo API方式的服务调用,TestConsumerApiGeneric是泛化方式的服务调用,TestConsumerAsync是异步调用的方式. 其中Provider模块为服务提供者,里面TestProvider和provider.xml组成了

服务消费端泛化调用与异步调用

本文借用dubbo.learn的Dubbo API方式来解释原理. 服务消费端泛化调用 前面我们讲解到,基于Spring和基于Dubbo API方式搭建简单的分布式系统时,服务消费端引入了一个SDK二方包,里面存放着服务提供端提供的所有接口类,之所以需要引入接口类是因为服务消费端一般是基于接口使用JDK代理实现远程调用的. 泛化接口调用方式主要在服务消费端没有API接口类及模型类元(比如入参和出参的POJO类)的情况下使用.其参数及返回值中没有对应的POJO类,所以所有POJO均转换为Map表示

消费端如何保证消息队列MQ的有序消费

消息无序产生的原因 消息队列,既然是队列就能保证消息在进入队列,以及出队列的时候保证消息的有序性,显然这是在消息的生产端(Producer),但是往往在生产环境中有多个消息的消费端(Consumer),尽管消费端在拉取消息时是有序的,但各个消息由于网络等方面原因无法保证在各个消费端中处理时有序. 场景分析 先后两次修改了商品信息,消息A和消息B先后同步写入MySQL,接着异步写入消息队列中发送消息,此时消息队列生产端(Producer)按时序先后发出了A和B两条消息(消息A先发出,消息B后发出)

监控Kafka消费进度

使用Kafka作为消息中间件消费数据时,监控Kafka消费的进度很重要.其中,在监控消费进度的过程中,主要关注消费Lag. 常用监控Kafka消费进度的方法有三种,分别是使用Kafka自带的命令行工具.使用Kafka Consumer API和Kafka自带的JMX监控指标,这里介绍前两种方法. 注: 内网IP:10.12.100.126 10.12.100.127 10.12.100.128 外网IP:47.90.133.76 47.90.133.77 47.90.133.78 用户名:ser