Kafka消费者端
可靠性保证
作为消费端,消费数据需要考虑的是:
1、不重复消费消息
2、不缺失消费消息
分区分配策略
一个 consumer group 中有多个 consumer,一个 topic 有多个 partition,所以必然会涉及到 partition 的分配问题,即确定那个 partition 由哪个 consumer 来消费。 Kafka 有两种分配策略,一是 RoundRobin(轮询调度算法(Round-Robin Scheduling)),一是 Range。
https://blog.csdn.net/u013256816/article/details/81123600 朱小厮的博客(《深入理解Kafka:核心设计与实践原理》和《RabbitMQ实战指南》作者)
offset
消费者端的可靠性需要依靠offect来进行保证,这里的offset不是broker的offect,而是consumer的消费位移偏移量,它在broker中被维护。由于 consumer 在消费过程中可能会出现断电宕机等故障, consumer 恢复后,需要从故 障前的位置的继续消费,所以 consumer 需要实时记录自己消费到了哪个 offset,以便故障恢复后继续消费。
Kafka 0.9 版本之前, consumer 默认将 offset 保存在 Zookeeper 中,从 0.9 版本开始,consumer 默认将 offset 保存在 Kafka 一个内置的 topic 中,该 topic 为__consumer_offsets。
Consumer 消费数据时的可靠性是很容易保证的,因为数据在 Kafka 中是持久化的,故不用担心数据丢失问题.
所以 offset 的维护是 Consumer 消费数据是必须考虑的问题
为了使我们能够专注于自己的业务逻辑, Kafka 提供了自动提交 offset 的功能。
自动提交 offset 的相关参数:
enable.auto.commit: 是否开启自动提交 offset 功能(true) auto.commit.interval.ms: 自动提交 offset 的时间间隔 (1000ms = 1s)
这种方式让消费者来管理位移,应用本身不需要显式操作。当我们将enable.auto.commit设置为true, 那么消费者会在poll方法调用后每隔5秒(由auto.commit.interval.ms指定)提交一次位移。和很多其 他操作一样,自动提交也是由poll()方法来驱动的;在调用poll()时,消费者判断是否到达提交时间,如 果是则提交上一次poll返回的最大位移。
需要注意到,这种方式可能会导致消息重复消费。假如,某个消费者poll消息后,应用正在处理消息,在3秒后Kafka进行了重平衡,那么由于没有更新位移导致重平衡后这部分消息重复消费。
虽然自动提交 offset 十分简介便利,但由于其是基于时间提交的, 开发人员难以把握offset 提交的时机。因此 Kafka 还提供了手动提交 offset。
手动提交 offset 的方法有两种:分别是 commitSync(同步提交) 和 commitAsync(异步提交) 。两者的相同点是,都会将本次 poll 的一批数据最高的偏移量提交;不同点是,commitSync 阻塞当前线程,一直到提交成功,并且会自动失败重试(由不可控因素导致,也会出现提交失败);而 commitAsync 则没有失败重试机制,故有可能提交失败。 由于同步提交 offset 有失败重试机制,故更加可靠 .
手动提交offset 的相关参数:
enable.auto.commit: 是否开启自动提交 offset 功能(false)
异步提交也有个缺点,那就是如果服务器返回提交失败,异步提交不会进行重试。相比较起来,同步提交会进行重试直到成功或者最后抛出异常给应用。异步提交没有实现重试是因为,如果同时存在多个异步提交,进行重试可能会导致位移覆盖。举个例子,假如我们发起了一个异步提交commitA,此时的提交位移为2000,随后又发起了一个异步提交commitB且位移为3000;commitA提交失败但commitB提交成功,此时commitA进行重试并成功的话,会将实际上将已经提交的位移从3000回滚到2000,导致消息重复消费。
虽然同步提交 offset 更可靠一些,但是由于其会阻塞当前线程,直到提交成功。因此吞吐量会收到很大的影响。因此更多的情况下,会选用异步提交 offset 的方式。
无论是同步提交还是异步提交 offset,都有可能会造成数据的漏消费或者重复消费。先提交 offset 后消费,有可能造成数据的漏消费;而先消费后提交 offset,有可能会造成数据的重复消费 。所以,在保证数据完整性的前提下,选择同步提交同时尽量能在消费端进行消息去重的操作。
spring-kafka消费者端
spring-consumer.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:context="http://www.springframework.org/schema/context"
xmlns="http://www.springframework.org/schema/beans" xmlns:aop="http://www.springframework.org/schema/aop"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd">
<context:component-scan base-package="listener" />
<!--<context:component-scan base-package="concurrent" />-->
<bean id="consumerProperties" class="java.util.HashMap">
<constructor-arg>
<map>
<!--broker集群-->
<entry key="bootstrap.servers" value="192.168.25.10:9092,192.168.25.11:9092,192.168.25.12:9092"/>
<!--groupid-->
<entry key="group.id" value="group1"/>
<!--earliest :当各分区下有已提交的offset时,从提交的offset开始消费;无提交的offset时,从头开始消费-->
<entry key="auto.offset.reset" value="earliest "/>
<!--自动提交-->
<entry key="enable.auto.commit" value="false"/>
<!--自动提交重试等待时间-->
<entry key="auto.commit.interval.ms" value="1000"/>
<!--检测消费者故障的超时-->
<entry key="session.timeout.ms" value="30000"/>
<!--key反序列化-->
<entry key="key.deserializer" value="org.apache.kafka.common.serialization.IntegerDeserializer"/>
<!--value反序列化-->
<entry key="value.deserializer" value="org.apache.kafka.common.serialization.StringDeserializer"/>
</map>
</constructor-arg>
</bean>
<!--consumer工厂-->
<bean id="consumerFactory" class="org.springframework.kafka.core.DefaultKafkaConsumerFactory">
<constructor-arg>
<ref bean="consumerProperties"/>
</constructor-arg>
</bean>
<bean id="containerProperties" class="org.springframework.kafka.listener.config.ContainerProperties">
<constructor-arg >
<list>
<value>topic1</value>
<value>topic2</value>
</list>
</constructor-arg>
<property name="messageListener" ref="kafkaConsumerListener"/>
<property name="pollTimeout" value="1000"/>
<property name="AckMode" value="MANUAL"/>
</bean>
<bean id="messageListenerContainer" class="org.springframework.kafka.listener.KafkaMessageListenerContainer" >
<constructor-arg ref="consumerFactory"/>
<constructor-arg ref="containerProperties"/>
</bean>
<!-- 并发消息监听容器,执行doStart()方法 -->
<!-- <bean id="messageListenerContainer" class="org.springframework.kafka.listener.ConcurrentMessageListenerContainer" init-method="doStart" >
<constructor-arg ref="consumerFactory" />
<constructor-arg ref="containerProperties" />
<!–#消费监听器容器并发数–>
<!–concurrency = 3–>
<property name="concurrency" value="3" />
</bean>-->
</beans>
AckMode RECORD每处理一条commit一次
BATCH(默认)每次poll的时候批量提交一次,频率取决于每次poll的调用频率
TIME 每次间隔ackTime的时间去commit(跟auto commit interval有什么区别呢?)
COUNT 累积达到ackCount次的ack去commit
COUNT_TIMEackTime或ackCount哪个条件先满足,就commit
MANUAL listener负责ack,但是背后也是批量上去
MANUAL_IMMEDIATE listner负责ack,每调用一次,就立即commit
KafkaConsumerListener类
(同步提交)
@Component
public class KafkaConsumerListener implements AcknowledgingMessageListener<String, String> {
@Override
public void onMessage(ConsumerRecord<String, String> stringStringConsumerRecord, Acknowledgment acknowledgment) {
System.out.printf("offset= %d, key= %s, value= %s,topic= %s,partition= %s\n",
stringStringConsumerRecord.offset(),
stringStringConsumerRecord.key(),
stringStringConsumerRecord.value(),
stringStringConsumerRecord.topic(),
stringStringConsumerRecord.partition());
acknowledgment.acknowledge();
}
}
测试
@Test
public void consumer() {
ApplicationContext context = new ClassPathXmlApplicationContext("listener.xml");
System.out.printf("启动listener");
while (true) {
}
}
结果:
offset= 57, key= null, value= 2019-11-19 03:40:45,topic= topic1,partition= 0
offset= 4929, key= null, value= 2019-11-19 03:40:47,topic= topic2,partition= 2