目录
1.Kafka的介绍
1.1介绍
Kafka是一个分布式的发布-订阅消息系统,可以快速地处理高吞吐量的数据流,并将数据实时地分发到多个消费者中。Kafka消息系统由多个broker(服务器)组成,这些broker可以在多个数据中心之间分布式部署,以提供高可用性和容错性。
Kafka的基本架构由生产者、消费者和主题(topic)组成。生产者可以将数据发布到指定的主题,而消费者可以订阅这些主题并消费其中的数据。同时,Kafka还支持数据流的处理和转换,可以在管道中通过Kafka Streams API进行流式计算,例如过滤、转换、聚合等。
1.2Kafka的概念
Kafka的消息发送者和消息消费者通过Topic这样一个逻辑概念来进行业务沟通。但是实际上,所有的消息存在服务端的Partition这样一个数据结构中。
- 客户端Client:包括消息生产者和消息消费者;
- 消费者组:每个消费者可以指定一个所属的消费者组,相同消费者组的消费者共同构成一个逻辑消费者组。每个消息会被多个感兴趣的消费者组消费,但是在同一个消费者组内部,一个消息只能被消费一次。
- 服务端Broker:一个Kafka服务器就是一个Broker;
- 话题Topic:Topic是一个逻辑概念,而Partition是实际存储消息的组件。每个Partition就是一个queue队列。所有消息以FIFO先进先出的顺序保存在这些Partition中。
1.3.Kafka实现的日志聚合
特点:
1.数据吞吐量大:能够快速收集各个渠道的海量日志。
2.功能不需要太复杂:Kafka的设计目标是高吞吐、低延迟和可扩展,主要关注消息传递而不是消息处理。所以,Kafka没有支持死信队列、顺序消息等功能。
1.4简单的收发消息
Kafka的基础工作机制是消息发送者可以将消息发送到Kafka指定的topic,而消息消费者,可以从指定的topic上消费消息。
1.5其他消费模式
Kafka提供了丰富的消息消费方式。
1.5.1指定消费进度
如果想要消费之前发送的消息,可以通过指定参数--from-begin。
如果需要更精确的消费消息,可以指定从那条消息开始消费。
1.5.2分组消费
对于每个消费者,可以指定一个消费者组。Kafka中的同一条消息,只能被同一个消费者组下的消费者消费。而不属于同一个组的消费者,也可以消费到这一条消息。
1.5.3查看消费者组的偏移量
接下来,还可以使用kafka-consumer-groups.sh观测消费者组的情况。包括他们的消费进度。
1.6基于Zookeeper的Kafka集群
1.6.1使用集群的原因
- 消息太多,需要分开存放。Kafka是面向海量消息设计的,一个Topic下的消息会非常多,单机服务很难存得下来。这些消息就需要分成不同的Partition,分布到多个不同的Broker上。这样每个Broker就只需要保存一部分数据。这些分区的个数就称为分区数。
- 服务不稳定,消息容易丢失。单机服务下,如果服务崩溃,数据就丢失了。为了保证数据安全,就需要给每个Partition配置一个或多个备份,保证数据不丢失。Kafka的集群模式下,每个Partition都有一个或多个备份。Kafka会通过一个统一的Zookeeper集群作为选举中心,给每个Partition选举出一个主节点Leader,其他节点就是从节点Follower。主节点负责响应客户端的具体业务请求,并保存消息。而从节点则负责同步主节点的数据。当主节点发生故障时,Kafka会选举出一个从节点成为新的主节点。
Kafka集群中的这些Broker信息,包括Partition的选举信息,都会保存在额外部署的Zookeeper集群当中,这样,kafka集群就不会因为某一些Broker服务崩溃而中断。Zookeeper是一种多数同意的选举机制,允许集群中少数节点出现故障。
1.6.2Kafka集群架构
1.6.3Topic下的Partition分布情况
在Broker上,与消息联系最为紧密的,就是Partition。之前在配置Kafka集群时,指定了一个log.dirs属性,指向了一个服务器上的日志目录。进入这个目录,就能看到每个Broker的实际数据承载情况。
Broker上的一个Partition对应了日志目录中的一个目录。而这个Partition上的所有消息,就保存在这个对应的目录当中。
Kafka当中,Topic是一个数据集合的逻辑单元。同一个Topic下的数据,实际上是存储在Partition分区中的,Partition就是数据存储的物理单元。而Broker是Partition的物理载体,这些Partition分区会尽量均匀的分配到不同的Broker机器上。而之前接触到的offset,就是每个消息在partition上的偏移量。
1.6.4Kafka集群的整体结构
- Topic是一个逻辑概念,Producer和Consumer通过Topic进行业务沟通。
- Topic并不存储数据,Topic下的数据分为多组Partition,尽量平均的分散到各个Broker上。每组Partition包含Topic下一部分的消息。每组Partition包含一个Leader Partion以及若干个Follower Partition进行备份。每组Partition的个数成为备份因子replica factor。
- Producer将消息发送到对应的Partition上,然后Consumer通过Partition的Offset偏移量,记录自己所属消费者组Group在当前Partition上消费消息的进度。
- Producer发送一个Topic的消息,会由Kafka推送给订阅了这个Topic的消费者组进行处理。但是在每个消费者组内部,只会有一个消费者实例处理这一条消息。
- Kafka的Broker通过Zookeeper组成集群。然后在这些Broker中,需要选举产生一个担任Controller角色的Broker。这个Controller的主要任务就是负责Topic的分配以及后续管理工作。在我们实验的集群中,这个Controller实际上是通过ZooKeeper产生的。
1.7Kraft集群
使用Kraft集群后,Kafka集群就不再需要依赖Zookeeper,将之前基于Zookeeper管理的集群数据,转为由Kafka集群自己管理。(目前用的比较少)
传统的Kafka集群,会将每个节点的状态信息统一保存在Zookeeper中,并通过Zookeeper动态选举产生一个Controller节点,通过Controller节点来管理Kafka集群,比如触发Partition的选举。而在Kraft集群中,会固定配置几台Broker节点来共同担任Controller的角色,各组Partition的Leader节点就会由这些Controller选举产生。原本保存在Zookeeper中的元数据也转而保存到Controller节点中。
补充:Raft协议是目前进行去中心化集群管理的一种常见算法,类似于之前的Paxos协议,是一种基于多数同意,从而产生集群共识的分布式算法。Kraft则是Kafka基于Raft协议进行的定制算法。