后端 与 Kafka | 青训营笔记

109 阅读5分钟

这是我参与「第五届青训营 」伴学笔记创作活动的第 12 天,今天学习了消息队列,让自己感悟最深的是Kafka消息队列,下面是我的收获

消息队列

1.1 背景

1.1.1 消息队列发展历程

TIB-IBM(诞生于1985年服务于金融机构和新闻机构)-MQ/WebSphere(诞生于1993年,是一个商业消息队列平台,市场主要是玩家)- MSMQ (微软发布于1997年)- JMS-AMQP/RabbitMQ-Kafka-RockerMQ-Pulsar

1.1.2 业内消息队列对比

  • Kafka:分布式的、分区的、多副本的日志提交服务,在高吞吐场景下发挥较为出色
  • RocketMQ:低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性,在一些实时场景中运用较广
  • Pulsar:是下一代云原生分布式消息流平台,集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计
  • BMQ:和Pulsar架构类似,存算分离,初期定位是承接高吞吐的离线业务场景,逐步替换掉对应的Kafka集群

1.2 Kafka

1.2.1 使用场景

搜索服务、直播服务、订单服务、支付服务产生的日志信息和用户行为,以及Metrics数据

1.2.2 如何使用

  • 首先,需要创建一个Kafka集群
  • 然后,需要在这个集群中创建—个Topic,并且设置好分片数量
  • 其次,引入对应语言的SDK,配置好集群和Topic等参数,初始化一个生产者,调用Send方法,将你的Hello World发送出去
  • 最后,引入对应语言的SDK,配置好集群和Topic等参数,初始化一个消费者,调用Poll方法,你将收到你刚刚发送的Hello World

1.2.3 基本概念

  • Topic:逻辑队列,不同Topic可以建立不同的Topic
  • Cluster:物理集群,每个集群中可以建立多个不同的Topic
  • Producer:生产者,负责将业务消息发送到Topic中
  • Consumer:消费者,负责消费Topic 中的消息
  • ConsumerGroup:消费者组,不同组Consumer消费进度互不干涉

1.2.4 基本概念-Offset

消息在partition内的相对位置信息,可以理解为唯一ID,在 partition内部严格递增

1.2.5 基本概念-Replica

每个分片有多个 Replica, Leader Replica将会从ISR中选出

  • Replica:分片的副本,分布在不同的机器上,可用来容灾,Leader对外服务,Foll we异步去拉取leder的数据进行一个同步,如果leder挂掉了,可以将Follower提升blede再堆外进行服务
  • ISR:意思是同步中的副本,对于rolwar来说,始终和ede是有一定差距的,但当这个差距比较小的时候,我们就可以将这个1ollower副本加入到SR中,不在SR中的副本是不允许提升成leade的

1.2.6 数据复制

Broker代表每一个Kafka的节点,所有的Broker节点最终组成了一个集群,例如一个集群,包含了4个Broker机器节点,集群有两个Topic分别是Topic1和Topic2 ,Topic1有两个分片,Topic2有1个分片,每个分片都是三副本的状态。中间有一个Broker同时也扮演了Controller的角色,Controller是整个集群的大脑,负责对副本和Broker进行分配

1.2.7 Kafka架构

ZooKeeper:负责存储集群元信息,包括分区分配信息等

2023-02-22-16-22-35-image.png

1.2.8 一条消息的产生

  • 首先通过Producer生产
  • 然后经过Broker处理
  • 最后给Consumer消费

1.2.9 Producer-批量发送

批量发送的好处在于减少I/O次数,从而加强发送能力

1.2.10 Prdocer-数据压缩

通过压缩可以减少消息大小

1.2.11 Broker-数据的存储

消息文件结构

2023-02-22-16-35-04-image.png

磁盘结构

移动磁头找到对应磁道,磁盘转动,找到对应扇区,最后写入。寻道成本比较高,因此顺序写可以减少寻道所带来的时间成本

顺序写

采用顺序写的方式进行写入,以便提高写入效率,即末尾添加消息

1.2.12 Broker-如何找到消息

Consumer通过发送FetchRequest请求消息数据,Broker 会将指定Offset 处的消息,按照时间窗口和消息大小窗口发送给Consumer

1.2.13 Broker偏移量索引文件

  • 文件名是文件中第一条消息的offset
  • 然后通过二分找到小于目标文件的最大文件

1.2.14 Broker时间戳索引文件

二分找到小于目标时间戳最大的索引位置,在通过寻找offset的方式找到最终数据

1.2.15 Consumer-消息的接收端

对一个Consumer Group来说,多个分片可以并发的消费,这样可以大大提高消费的效率,但需要解决的问题是Consumer和Parttion,也就是对于每一个Parttion来说,该由跟一个Consumer来消费的问题,有两种解决方法,手动分配和自动分配

1.2.16 Consumer-Low Level

通过手动进行分配,哪一个Consumer消费哪一个 Partition完全由业务来决定

1.2.17 Consumer-High Level

简单的来说们就是在Broker集群中,对于不同的Consumer Group来说,都会选取一台Broker当做Coordinator,其作用就是帮助它进行分片的分配,也叫做分片的rebalance,使用这种方式,计算Consumer Group中发生宕机也会重新分配来达到一个稳定的状态

1.2.18 Kafka-数据复制问题

对于Kafka,每一个Broker上都有不同的topic分区的不同的副本,而每一个副本都会将其数据存储到该Kafka节点上,对于不同的节点之间,通过副本直接的数据复制来保证数据的最终一致性以及集群的高可用

总结

Kafka存在的问题

  • 运维成本高
  • 对于负载不均衡的场景,解决方案复杂
  • 没有自己的缓存,完全依赖Page Cache
  • 4.Controller和Coordinator和Broker在同一进程中,大量IO会造成其性能下降