kafka如何保证消息不丢失

今天我们来分析一下这个问题。

先来回忆一下kafka 中消息传输的整个过程

1、kafka 在producer 端产生消息,调用kafka producer client send方法发送消息

2、kafka producer client 使用一个单独的线程,异步的将消息发送给kafka server

3、kafka server收到消息以后,保存数据,并同步至副本

4、消息保存完成以后,返回给kafka producer client 端 【消息发送成功】

5、kafka consumer client 调用poll 方法,循环 从kafka server 端获取消息列表

6、kafka consumer 端 从kafka server获取到消息以后,开始消费消息

7、kafka consumer 消费消息完毕以后,向kafka server(topic为 _offset_consumer的消息队列) 发送偏移量

在上述的整个流程中,消息丢失的情况分为以几种可能性:

1、producer 端 发送消息给kafka server 端,中间网络出现问题,消息无法送达

2、kafka server端 在收到消息以后,保存消息时发生异常,异常分为三种

(1)可重试错误,通过重试来解决

(2) 网络连接错误

(3)无主(no leader)错误

3、consumer 在消费消息时发生异常,导致consumer端消费失败

注:当然这里还可能发生另一种错误,就是在producer发送消息到kafka server端时,消息体过大,producer client 直接抛出异常,导致发送失败

如何解决
1、producer 端的发送方式优化
我们先来了解一下,producer端发送消息的方式:

1.1    简单发送,无需关心结果

ProducerRecord<String,String> record = new ProducerRecord<>(
     "topicName","key","value"  
);
try{
    //这里只是把消息放进了一个缓冲区中,然后使用单独的线程将消息发送到服务端
    producer.send(record);
}
catch(Exception){
    e.printStackTrace();
}

1.2    同步发送

ProducerRecord<String,String> record = new ProducerRecord<>(
     "topicName","key","value"  
);
try{
    //send方法返回的是Future<RecordMetaData> 对象,然后我们可以调用get()方法等待响应
    Future<RecordMetaData> future = producer.send(record); 
    future.get();
}
catch(Exception){
    e.printStackTrace();
}

1.3    异步发送

private class DemoProducerCallback implements Callback{
    @override
    public void onCompletion(RecordMetadata recordMetadata,Exception e){
        //发生错误的回调方法,可以写入日志,或写入DB通过其它线程重重试,保证最终的数据送达
    }
}
ProducerRecord<String,String> record = new ProducerRecord<>(
     "topicName","key","value"  
);
producer.send(record,new DemoProducerCallback()))


总结:从以上的三种发送方式中,我们可以知道,采用第一种方式发送时,消息丢失时我们的应用程序是无感知的,如果需要保证消息的不丢失,那么必须要选择第二种或者第三种(需要配合下一节中讲到的acks 参数),当然这里更推荐第三方种方式。

2、producer端的配置优化
在producer 端的配置项中有很多的配置项,我们摘出几种比较重要的来一一解读:

acks:该参数指定了,kafka server的多少个副本收到消息以后才算真的正消息发送成功。取值范围:

acks = 0 表示producer 在将消息成功写入到 kafka server 之前不会收任消息
acks = 1 表示只要kafka server 集群中的leader节点收到消息,producer 端就会收到kafka server的成功响应
acks = all 表示只有当消息到leader节点,并且这条数据也同步到了所有副本中,producer 才会收到kafka server的成功响应。
buffer.memory:生产端 缓冲区的大小设置

compression type:生产端采用的数据压缩方式,取值 snappy,gzip,lz4,默认不会压缩。(启用压缩意味着,需要producer 和kafka server要占用更多的cpu资源)

retries:生产端发送消息到kafka server时,发生临时性错误以后,生产者发送消息到kafka server端重试的次数。如果重试超过该次数,则发生异常

batch.size: 当多个消息被发送至同一分区时,生产者会把它们发送到同一批。该参数指定了同一批次可以使用的内存大小,按字节数计算(而不是消息条数)。

linger.ms:该参数指定了生产者在发送批次之前等待更多消息加入批次的时间,producer client 会在批次填满(batch.size) 或linger.ms 到上限时,将消息发送至kafka server.

max.in.flight.requests.per.connection:该参数指定了生产者在收到kafka server 的成功响应之前,可以发送多少消息。(可以利用该配置让kafka server中的消息变得有序)

max.request.size:该参数用来控制生产者发送单个请求的数据大小。对于消费端也有相同的配置(message.max.bytes),建议两边设置相同。

总结:我们的问题,可以通过设置配置项 acks 、retries 来保证数据的不丢失。acks=1时,lead节点只要收到消息就会告诉producer消息接收成功,假如此时lead 挂掉了开始重新选主,选主成功后之前lead收到的那条消息就会丢失,如果需要保证消息的绝对不丢失,建议设置 acks =all

3、kafka server
这里需要补充一个知识点,kafka的server端同一个topic下有多个分区,单个分区会有不同的副本。如果producer 发送消息么kafka server端,leader收到了消息以后,告诉producer 发送成功,此时再同步消息到多个副本,但由于某一个副本同步较慢,此时leader挂了,需要选主,选主的过程中,一旦那个较慢的副本成为新的leader,那么新的leader中就不包含了原leader收到的那条最新数据,导致消息丢失。

broker中的配置项,unclean.leader.election.enable = false,表示不允许非ISR中的副本被选举为首领,以免数据丢失。

ISR:是指与leader保持一定程度(这种范围是可通过参数进行配置的)同步的副本和 leader 共同被称为ISR

OSR:与leader同步时,滞后很多的副本(不包括leader)被称为OSR

AR,分区中所有的副本统称为AR。AR = ISR + OSR

4、kafka consumer端的优化
kafka consumer的配置中,默认的enable.auto.commit = true,表示在kafka consumer 通过poll方法 获取到消息以后,每过5秒(通过配置项可修改)会自动获取poll中得到的最大的offset, 提交给kafka server 中的_offset_consumer(存储 offset 的特定topic )

如果enable.auto.commit = false时,则关闭了自动提交,你可以手动的通过应用程序代码进行提交,这里我来梳理一下,consumer 消费消息的整个流程

 consumer端循环向kafka server请求获取信息
如果kafka server中的分区中没有消息,则阻塞指定秒数(consumer端配置)后,返回给consumer端
 如果 kafka server中有消息 或是在阻塞等待的过程中有消息写入,则立即返回给consumer端
consumer开始消费消息
consumer消费消息完毕以后,提交偏移量到topic为 _offset_consumer(kafka server端) 的消息队列
我们来看一下,enale.auto.commit = false时,如何手动提交的

public void consumerMsg(){
    while(true){
        //这里的poll(100)指的是kafka server端没有消息时,连接等待的时间,超过该时间立即返回空给consumer
        ConsumerRecords<String,String> records = consomer.poll(100);
        for(ConsumerRecord<String,String> record : records){
            // 这里是消费消息的逻辑(简单逻辑输入到控制台)
            System.out.printIn(record.value));
            //提交偏移量
            try{
                consumer.commitSync();  //同步提交 如果异步的话,可以使用 consumer.commitAsync();
            }
            catch(CommitFailedException ex){
                log.error("commit fail");
            }
        }
    }
}

consumer端消息丢失的情况分为两种:

consumer 端启用了 enable.auto.commit= true,在消费消息时发生了异常
consumer 端 enable.auto.commit= false,但是在消息消费之前,提交了offset
针对这两种丢失的情况,我们做以下处理:

1、设置 enable.auto.commit = false

2、在consumer端消费消息操作完成以后 再提交 offset,类似于上文中的代码示例

写在最后:
以上的我们从producer 、 kafka server、 consumer 端出发,通过相关的优化手段保证消息的不丢失,当然业界还有一些其它的办法,比如在三种 send 的 调用方式中,callback时将消息写入到mysql 或日志中,当consumer 消费消息成功以后,我们从mysql 或 日志中删除消息,未成功消费的消息,可以启动一个线程,将消息重新入队让consumer收到消息以后重新消费(rabbit mq中 可以 利用死信队列和备用交换机来完成)

参考资料:《kafka 权威指南》第四章
————————————————
版权声明:本文为CSDN博主「长风dad」的原创文章

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值