1. kafka 定义
传统定义是一个分布式的基于 发布、订阅模式的消息队列，主要应用于大数据实时处理场景；现在kafka已经定义为一个分布式流平台，用于数据处理，高性能数据管道、流分析、数据集成和关键应用。
为什么现在主流的不使用kafka作为消息队列使用了呢？
- 他的MQ的功能是不完善的，有好多功能kafka是没有的。
特性
- 消息被消费完之后，消息不会被马上删除，到了过期时间，消息才会被删除掉。
- 具有消息回溯功能。【可以根据偏移量，再消费一遍】
- 容错性，自愈能力。
- 如果要保证消息不丢失，那么就会降低性能，而且消息会重复【后面会写】
- 适合处理一些 消息不是特别重要，消息数据量非常大，通过kafka传递到其他系统做处理。【MQ功能不全】
kafka架构图
2. 核心概念
- Producer（生产者） ：
- 生产者是数据的来源，负责将数据发布到 Kafka 的主题（Topic）中。生产者可以是各种应用程序、服务或设备。
- Consumer（消费者） ：
- 消费者从 Kafka 的主题中读取数据。一个或多个消费者可以订阅一个或多个主题。【拉模型，拉取到消息，不停消费】
- Topic（主题） ：
- 主题是 Kafka 用来组织数据的分类。每个主题是一个日志数据的流记录。主题可以分为多个分区（Partition），提高并发处理能力。【是kafka下消息的类别，类似于RabbitMQ中的Exchange的概念】
- Partition（分区） ：
- 每个主题可以有多个分区，分区是 Kafka 的并发处理单元。每个分区是一个有序的、不可变的记录序列，记录被追加到分区的尾部。【是kafka下数据存储的基本单元，这个是物理上的概念。】
- Broker（代理） ：
- Kafka 集群由一个或多个代理（Broker）组成，每个代理负责存储和服务部分主题的分区。代理之间可以相互通信，以实现数据的复制和负载均衡。【代表了kafka的实体服务】
- Zookeeper：
- Kafka 使用 Zookeeper 进行分布式协调，管理代理、主题、分区和消费者组的信息。Zookeeper 负责处理 Kafka 集群的状态管理和元数据存储。
- Controlle：
- 控制器是集群中的概念，每个集群中会选出一个Broker担任控制器角色，控制器是kafka集群中心。
- Cluster：
- 集群指的是由多个Broker所共同构成的一个整体，对外提供统一的服务，这类于我们在部署系统时都会采用集群的方式来进行。
- Replication：
- 每个分区都有多个副本，副本的作用是做备胎，主分区（Leader）会将数据同步到 从分区（Follower）。
- leader & follower：
- Leader 和 Follower 是分区（Partition）复制机制的核心概念。每个分区可以有多个副本（Replica），这些副本分布在不同的 Kafka Broker 上，以确保数据的高可用性和容错性。。
3. 消费模型的区别
消息队列（Message Queue，MQ）模型中的推模型（Push Model）和拉模型（Pull Model）是两种不同的消息传递方式，它们各有优缺点，并适用于不同的应用场景，kafka是拉模型。
推模型（Push Model）
在推模型中，消息由消息队列主动推送给消费者。消费者不需要主动请求消息，而是被动地接收消息。消息队列根据一定的策略（如轮询或广播）将消息分发给消费者。
优点：
- 实时性高：消息可以立即送达消费者，减少了消息延迟。
- 简单：消费者只需要实现消息处理逻辑，不需要主动拉取消息。
缺点：
- 流量控制难：如果消费者处理速度跟不上消息推送速度，可能会导致消息积压或消费者过载。
- 适应性差：推送速度固定，无法根据消费者的处理能力动态调整。
适用场景：
- 适用于实时性要求高的场景，例如实时通知、报警系统。
- 消费者处理能力相对均衡的情况下，推模型可以简化设计。
拉模型（Pull Model）
在拉模型中，消费者主动从消息队列中拉取消息。消费者决定何时以及以何种速度拉取消息，控制权在消费者手中。
优点：
- 流量控制好：消费者可以根据自身处理能力主动拉取消息，避免过载。
- 适应性强：可以根据消费者的处理能力动态调整拉取速度。
缺点：
- 实时性差：消息的到达时间取决于消费者的拉取频率，可能会有延迟。
- 复杂性高：消费者需要实现拉取消息的逻辑，并处理拉取策略。
适用场景：
- 适用于需要严格流量控制的场景，例如批处理系统、异步任务处理。
- 消费者处理能力差异较大的情况下，拉模型可以更好地适应不同的处理速度。
