赞
踩
- 0代表producer往集群发送数据不需要等到集群的返回,不确保消息发送成功。安全性最低但是效率最高。
- 1代表producer往集群发送数据只要leader应答就可以发送下一条,只确保leader发送成功。
- all代表producer往集群发送数据需要所有的follower都完成从leader的同步才会发送下一条,确保leader发送成功和所有的副本都完成备份。安全性最高,但是效率最低。
最后要注意的是,如果往不存在的topic写数据,能不能写入成功呢?kafka会自动创建topic,分区和副本的数量根据默认配置都是1。
此外,对于某些业务场景,设置max.in.flight.requests.per.connection
=1会严重降低吞吐量,如果放弃使用这种同步重试机制,则可以考虑在消费端增加失败标记的记录,然后用定时任务轮询去重试这些失败的消息并做好监控报警。
Kafka为分区(Partition)引入多副本(Replica)机制,分区(Partition)中的多个副本中有一个leader,其余称为leader的follower。我们的消息发送到leader副本,然后follower副本才能从leader副本中拉取消息进行同步。
整个同步流程是异步的,并且设计得足够高效,以便在Kafka集群中处理大量的数据和高并发的读写操作。此外,Kafka还通过一系列的优化手段(如批量拉取、压缩传输等)来减少同步过程中的网络开销和延迟。
Zookeeper主要为Kafka提供元数据的管理的功能。
- Broker注册:在 Zookeeper 上会有一个专门用来进行 Broker 服务器列表记录的节点。每个 Broker 在启动时,都会到 Zookeeper 上进行注册,即到
/brokers/ids
下创建属于自己的节点。每个 Broker 就会将自己的 IP 地址和端口等信息记录到该节点中去- Topick注册:在 Kafka 中,同一个Topic 的消息会被分成多个分区并将其分布在多个 Broker 上,这些分区信息及与 Broker 的对应关系也都是由 Zookeeper 在维护。比如我创建了一个名字为 my-topic 的主题并且它有两个分区,对应到 zookeeper 中会创建这些文件夹:
/brokers/topics/my-topic/Partitions/0
、/brokers/topics/my-topic/Partitions/1。
- 负载均衡:对于同一个 Topic 的不同 Partition,Kafka 会尽力将这些 Partition 分布到不同的 Broker 服务器上。当生产者产生消息后也会尽量投递到不同 Broker 的 Partition 里面。当 Consumer 消费的时候,Zookeeper 可以根据当前的 Partition 数量以及 Consumer 数量来实现动态负载均衡。
在Kafka2.8之前Kafka严重依赖于Zookeeper,在Kafka2.8之后引入了基于Raft协议的KRaft模式,从而使得Kafka不再严重依赖于Zookeeper,可以进行独立的部署,大大简化了Kafka的架构.
- 同步发送模式:发出消息后,必须等待阻塞队列收到通知后,才发送下一条消息;同步发送模式可以保证消息不丢失、又能保证消息的有序性。
SendResult<String, Object> sendResult = kafkaTemplate.send(topic, o).get();
if (sendResult.getRecordMetadata() != null) {
logger.info(“生产者成功发送消息到” + sendResult.getProducerRecord().topic() + "-> " + sendRe
sult.getProducerRecord().value().toString());
}
- 异步发送模式:生产者一直向缓冲区写消息,然后一起写到队列中;好处是吞吐量大,性能高。
ListenableFuture<SendResult<String, Object>> future = kafkaTemplate.send(topic, o); future.addCallback(result -> logger.info("生产者成功发送消息到topic:{} partition:{}的消息", result.getRecordMetadata().topic(), result.getRecordMetadata().partition()), ex -> logger.error("生产者发送消失败,原因:{}", ex.getMessage()));
- 1
- 2
- 3
同步模式
下,将发送消息的确认机制设置为all,使得所有节点确认后再发送下一条数据即可。异步模式
下,如果消息发送出去了,但还没有收到确定的时候,在配置文件中设置成不限制阻塞超时的时间,即让生产者一直保持等待,也可以保证数据不丢失。Kafka不基于内存,而是基于磁盘,因此消息堆积能力更强。
生产发送的消息没有收到正确的broke响应,导致producer重试。
详解:producer发出一条消息,broker落盘以后,因为网络等原因,发送端得到一个发送失败的响应或者网络中断,然后producer收到 一个可恢复的Exception重试消息导致消息重复。
解决:
enable.idempotence=true //此时会默认开启acks=all
acks=all
retries>1kafka 0.11.0.0版本之后,正式推出了idempotent producer,支持生产者的幂等。每个生产者producer都有一个唯-id,producer每发送一条数据都会带上一个sequence,当消息落盘,sequence就会递增1。只需判断当前消息的sequence是否大于当前最大sequence,大于就代表此条数据没有落盘过,可以正常消费,不大于就代表落盘过,这个时候重发的消息会被服务端拒掉从而避免消息重复。
Kafka默认先消费消息,再提交offset。如果消费者在消费了消息之后,消费者挂了,还未提交offset,那么Broker后边会重新让消费者消费。
解决:消费者进行幂等处理,消费者进行幂等处理同样可以处理生产生重复发送消息的问题。
如:可以用redis的setnx分布式锁来实现。比如操作订单消息,可以把订单id作为key,在消费消息时,通过setnx命令设置一下,offset提交完成后,在redis中删除订单id的key。setnx命令保证同样的订单消息,只有一个能被消费,可有效保证消费的幂等性!上面提到的两种方式需要结合SETNX使用。
Kafka默认消息消费失败后的重试次数为10,并且重试间隔为0s。
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数大数据工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年大数据全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上大数据开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加VX:vip204888 (备注大数据获取)
程,基本涵盖了95%以上大数据开发知识点,真正体系化!**
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加VX:vip204888 (备注大数据获取)
[外链图片转存中…(img-p3WdlTf9-1712526482326)]
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。