这是我参与「第四届青训营 」笔记创作活动的第12天,这篇文章记录了我在Kafka学习时关于消息队列的理解,和结合青训营上课内容以及网上的博客整理的笔记。
Kafka概述
Kafka 是一种高吞吐、分布式、基于发布和订阅模型的消息系统,最初是由 LinkedIn 公司采用 Scala 和 java 开发的开源流处理软件平台,目前是 Apache 的开源项目。
Kafka 用于离线和在线消息的消费,将消息数据按顺序保存在磁盘上,并在集群内以副本的形式存储以防止数据丢失。Kafka 可以依赖 ZooKeeper 进行集群管理,并且受到越来越多的分布式处理系统的青睐,比如 Storm、Spark、Flink 等都支持与 Kafka 集成,用于实时流式计算。
消息队列应用场景
消息队列是一种进程间通信或者同一个进程中不同线程间的通信方式,主要解决异步处理、应用耦合、流量消峰等问题,实现高性能、高可用、可伸缩和最终一致性架构,是大型分布式系统不可缺少的中间件。
异步处理
消息队列提供了异步处理机制,因为很多时候用户并不需要立即响应来处理消息,那么通过这个机制就可以把所有消息放入 MQ 中。比如,某系统发来的数据中包含很多图片信息,如果对其中的信息都进行保存处理,用户一番操作下来可能会很久。采用异步处理之后,系统会将所有数据存放在 MQ 中,用户不需要立即处理,大大缩短了系统的响应时间。
应用解耦
消息队列可以对系统间的依赖进行解耦,降低依赖系统变更带来的影响。如果经常出现这种依赖系统迭代的情况,可以通过消息队列对依赖系统进行解耦,这样系统A无需关心其他系统的可用性。
流量削峰
流量削峰还有个形象的名字叫做削峰填谷,指当数据量激增时,能够有效地隔离上下游业务,将上游突增的流量缓存起来,真正地填到谷中,以平滑的方式传到下游系统,避免了流量的不规则冲击。比如,有个活动页面平时也就 50qps,某一特殊时刻访问量突然增多,能达到 1000qps,但是当前系统的处理能力最多为 100qps,这个时候可以通过消息队列来进行削峰填谷,如下图所示。
具体场景
MQ 消息通道
EventBridge 事件总线
Data Platform 数据流平台
主流消息队列介绍
RabbitMQ、RocketMQ、Kafka、Pulsar
Kafka 架构介绍
- Producer:生产者,负责将客户端生产的消息发送到 Kafka 中,可以支持消息的异步发送和批量发送;
- broker:服务代理节点,Kafka 集群中的一台服务器就是一个 broker,可以水平无限扩展,同一个 Topic 的消息可以分布在多个 broker 中;
- Consumer:消费者,通过连接到 Kafka 上来接收消息,用于相应的业务逻辑处理。
- ZooKeeper:提供一致性
- Consumer Group:消费者组,指的是多个消费者共同组成一个组来消费一个 Topic 中的消息
在整个 Kafka 集群中 Producer 将消息发送给 broker,然后 broker 再将接收到的消息存储到磁盘中,然后 Consumer 再从 Broker 订阅并消费消息。ZooKeeper 则是 Kafka 集群用来负责集群元数据的管理、控制器的选举等操作的。
Kafka 高可用
Kafka 为分区引入了多副本机制,同一分区的不同副本中保存的信息是相同的,通过多副本机制实现了故障的自动转移,当集群中某个 broker 失效时仍然能保证服务可用,可以提升容灾能力。
如图所示,Kafka 集群中有4个 broker,某个 Topic 有三个分区,假设副本因子也有设置为3,那么每个分区就会有一个 Leader 和两个 Follower 副本。
副本处于不同 broker 中,生产者与消费者只和 Leader 副本进行交互,而 Follower 副本只负责消息的同步。当 Leader 副本出现故障时,会从 Follower 副本中重新选举新的 Leader 副本对外提供服务。
- AR(Assigned Replicas):一个分区中的所有副本统称为 AR
- ISR(In-Sync Replicas):Leader 副本和所有保持一定程度同步的 Follower 副本(包括 Leader 本身)组成 ISR
- OSR(Out-of-Sync Raplicas):与 ISR 相反,没有与 Leader 副本保持一定程度同步的所有Follower 副本组成OSR
首先,生产者会将消息发送给 Leader 副本,然后 Follower 副本才能从 Leader 中拉取消息进行同步,在同一时刻,所有副本中的消息不完全相同,也就是说同步期间,Follower 相对于 Leader 而言会有一定程度上的滞后,当然这个滞后程度是可以通过参数来配置的。
三者的关系:AR = ISR + OSR。
Leader 负责维护和跟踪 ISR 集合中所有 Follower 副本的滞后状态,当 Follower 出现滞后太多或者失效时,Leader 将会把它从 ISR 集合中剔除。
如果 OSR 集合中有 Follower 同步范围追上了 Leader,那么 Leader 也会把它从 OSR 集合中转移至 ISR 集合。
一般情况下,当 Leader 发送故障或失效时,只有 ISR 集合中的 Follower 才有资格被选举为新的 Leader,而 OSR 集合中的 Follower 则没有这个机会(可以修改参数配置来改变)。
Kafka 未来演进之路
参考文献
(34条消息) 一文带你搞懂 Kafka 的系统架构(深度好文,值得收藏)_Data跳动的博客-CSDN博客_kafka架构