Kafka的三高设计原理

2024-09-07 05:04
文章标签 设计 原理 kafka 三高

本文主要是介绍Kafka的三高设计原理,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

1.生产者缓存机制--高性能

生产者缓存机制的主要目的是将消息打包,减少网络IO频率

kafka生产者端存在消息累加器RecordAccumulator,它会对每个Partition维护一个双端队列,队列中消息到达一定数量后 或者 到达一定时间后,通过sender线程批量的将消息发送给kafka服务端。(批量发送)

2.发送应答机制--高可用

发送应发机制保证了消息可以安全到达服务端

Producer端一个不太起眼的属性ACKS_CONFIG:

  • acks = 0,生产者不关心broker的应答;不安全,但是速度快
  • acks = all or -1,生产者需要所有partition的应答;最安全,但是效率低一些
  • acks = 1,生产者只需要Leader partition的应答;中和

3.生产者消息幂等性--高可用

防止消息重复发送到服务端Broker

(解决了单分区发送的问题)

每个Producer发送消息到Broker的时候,会携带<PID,SN>给Broker,PID是该Producer的唯一标识,SN是消息序号。Broker端会维护这个SN的序列号。如果发送端SN<=服务端SN,则重复应答即可;如果发送端SN>服务端SN,则说明发送的消息有丢失!如果发送端SN=服务端SN+1,则正常接收消息。

(多分区发送的幂等性问题需要事务机制来保证)

4.Controller Broker和Leader Partition--高可用

监控作用

基于Zookeeper的Controller选举机制,Controller Broker管理所有Broker的健康状态;

Leader Partition管理该Topic下的所有partition;

当一个broker中存在多个Leader partition的时候,会触发Leader partition的自平衡机制,涉及到大量消息的转移和同步。

5.Partition的故障恢复机制--高可用

保证各partition的数据一致性

  • LEO(Log End Offset): 每个Partition的最后一个Offset
  • HW(High Watermark): 一组Partiton中最小的LEO

当follower partition故障时,该Follower节点会读取本地记录的上一次的HW,将自己的日志中高于HW的部分信息全部删除掉,然后从HW开始,向Leader进行消息同步。

当Leader partition故障时,会选举出新的Leader partition,其他Follower会将各自的Log文件中高于HW的部分全部清理掉,然后从新的Leader中同步数据。

如果follower partition的HW不一致,那kafka通过epoch机制来进行数据同步。

(每个Leader Partition在上任之初,都会新增一个新的Epoch记录。这个记录包含更新后的epoch版本号,以及当前Leader Partition写入的第一个消息的偏移量。接下来其他Follower Partition要更新数据时,就可以不再依靠自己记录的HW值判断拉取消息的起点,而是根据这个最新的epoch条目来同步

6.消息存储--高性能

三个日志文件存储kafka的消息,.log存储实际消息,.index以偏移量为索引,.timeindex以时间戳为索引

.log只可以进行消息顺序写的追加,不支持修改和删除!顺序写的效率很高

.index类似于跳表!<offset,pos>,跳表的查询效率高,redis也用到跳表!

7.零拷贝--高性能

producer发送给broker的消息通过mmap持久化到磁盘;

consumer通过sendfile方式拉取broker的消息;

8.消费者防止消息重新消费--高性能

1)消费者通过订单的id去查看该消息是否已被消费过(消息如果被消费了,则该id已存在)

2)通过redis维持offset,消费时将消息的offset与redis中的offset进行比较

9.kafka消息零丢失方案--高可用

  • 生产者发送消息到broker不丢失:acks = -1或者all;或者1。
  • broker保证消息不丢失:1)配置多备份因子;2)合理刷盘频率
  • 消费者防止异步处理丢失消息:手动提交offset更安全一些

10.消息积压问题--高可用

  1. 如果业务正常,只是因为消费者消费太慢,则增加partition数量,增加消费者数量即可。
  2. 发送消息时,尽量保证消息在各个Partition分布均匀;
  3. 如果业务异常,则降级处理,人工介入分析该问题。

这篇关于Kafka的三高设计原理的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1144128

相关文章

Python中随机休眠技术原理与应用详解

《Python中随机休眠技术原理与应用详解》在编程中,让程序暂停执行特定时间是常见需求,当需要引入不确定性时,随机休眠就成为关键技巧,下面我们就来看看Python中随机休眠技术的具体实现与应用吧... 目录引言一、实现原理与基础方法1.1 核心函数解析1.2 基础实现模板1.3 整数版实现二、典型应用场景2

Java的IO模型、Netty原理解析

《Java的IO模型、Netty原理解析》Java的I/O是以流的方式进行数据输入输出的,Java的类库涉及很多领域的IO内容:标准的输入输出,文件的操作、网络上的数据传输流、字符串流、对象流等,这篇... 目录1.什么是IO2.同步与异步、阻塞与非阻塞3.三种IO模型BIO(blocking I/O)NI

JAVA封装多线程实现的方式及原理

《JAVA封装多线程实现的方式及原理》:本文主要介绍Java中封装多线程的原理和常见方式,通过封装可以简化多线程的使用,提高安全性,并增强代码的可维护性和可扩展性,需要的朋友可以参考下... 目录前言一、封装的目标二、常见的封装方式及原理总结前言在 Java 中,封装多线程的原理主要围绕着将多线程相关的操

kotlin中的模块化结构组件及工作原理

《kotlin中的模块化结构组件及工作原理》本文介绍了Kotlin中模块化结构组件,包括ViewModel、LiveData、Room和Navigation的工作原理和基础使用,本文通过实例代码给大家... 目录ViewModel 工作原理LiveData 工作原理Room 工作原理Navigation 工

Java的volatile和sychronized底层实现原理解析

《Java的volatile和sychronized底层实现原理解析》文章详细介绍了Java中的synchronized和volatile关键字的底层实现原理,包括字节码层面、JVM层面的实现细节,以... 目录1. 概览2. Synchronized2.1 字节码层面2.2 JVM层面2.2.1 ente

MySQL的隐式锁(Implicit Lock)原理实现

《MySQL的隐式锁(ImplicitLock)原理实现》MySQL的InnoDB存储引擎中隐式锁是一种自动管理的锁,用于保证事务在行级别操作时的数据一致性和安全性,本文主要介绍了MySQL的隐式锁... 目录1. 背景:什么是隐式锁?2. 隐式锁的工作原理3. 隐式锁的类型4. 隐式锁的实现与源代码分析4

MySQL中Next-Key Lock底层原理实现

《MySQL中Next-KeyLock底层原理实现》Next-KeyLock是MySQLInnoDB存储引擎中的一种锁机制,结合记录锁和间隙锁,用于高效并发控制并避免幻读,本文主要介绍了MySQL中... 目录一、Next-Key Lock 的定义与作用二、底层原理三、源代码解析四、总结Next-Key L

一文详解kafka开启kerberos认证的完整步骤

《一文详解kafka开启kerberos认证的完整步骤》这篇文章主要为大家详细介绍了kafka开启kerberos认证的完整步骤,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 目录一、kerberos安装部署二、准备机器三、Kerberos Server 安装1、配置krb5.con

Spring Cloud Hystrix原理与注意事项小结

《SpringCloudHystrix原理与注意事项小结》本文介绍了Hystrix的基本概念、工作原理以及其在实际开发中的应用方式,通过对Hystrix的深入学习,开发者可以在分布式系统中实现精细... 目录一、Spring Cloud Hystrix概述和设计目标(一)Spring Cloud Hystr

Debezium 与 Apache Kafka 的集成方式步骤详解

《Debezium与ApacheKafka的集成方式步骤详解》本文详细介绍了如何将Debezium与ApacheKafka集成,包括集成概述、步骤、注意事项等,通过KafkaConnect,D... 目录一、集成概述二、集成步骤1. 准备 Kafka 环境2. 配置 Kafka Connect3. 安装 D