kafka--基础--01--介绍
kafka–基础–01–介绍
1、Kafka介绍
- Kafka是一个分布式、分区、多副本、多生产者、多消费者的分布式消息(日志)系统
- Kafka基于ZooKeeper做高可用
- 使用场景
- 用于 日志收集
- 用于 消息服务
1.1、设计目标
- 以时间复杂度为 O(1) 的方式提供消息持久化能力，即使对 TB 级以上的数据也能保证常数时间的访问性能。
- 高吞吐率：即使在非常廉价的商用机器上也能做到单机支持 10W/每秒 消息的传输。
- 支持 Kafka Server 间的消息分区，以及分布式消费，同时保证每个 Partition 内的消息顺序传输。
- 支持离线数据处理和实时数据处理。
- 支持在线水平扩展
1.2、消息系统介绍
消息系统：负责将数据从A应用传递到B应用，应用只需关注数据，无需关心数据在两个或多个应用间是如何传递的。
分布式消息传递：基于可靠的消息队列，在客户端应用和消息系统之间异步传递消息。
有两种主要的消息传递模式：
- 点对点传递模式
- 发布-订阅模式(大部分的消息系统选用发布-订阅模式)
1.2.1、传递模式：点对点消息
- 消息持久化：消息持久化到一个队列中。
- 消费消息：一个或多个消费者消费队列中的数据。但是一条消息只能被消费一次，当一个消费者消费了队列中的某条数据之后，该条数据则从消息队列中删除。
- 优点：
- 即使有多个消费者同时消费数据，也能保证数据处理的顺序。
架构示意图如下：
1.2.2、传递模式：发布-订阅消息
- 消息持久化：消息被持久化到一个 Topic 中
- 消费消息：
- 消费者可以订阅一个或多个 Topic
- 消费者可以消费 Topic 中所有的数据
- 同一条数据可以被多个消费者消费
- 数据被消费后不会立马删除
- 发布者：消息的生产者
- 订阅者：消息的消费者
架构示意图如下：
2、术语
2.1、结构概述
上图介绍：
1个 Topic 配置了 3 个 Partition。
- Partition1：有2个Offset(0和1)。
- Partition2：有4个Offset。
- Partition3：有1个Offset。
副本的 ID 和副本所在的机器的 ID 恰好相同。
如果一个 Topic 的副本数为 3，那么 Kafka 将在集群中为每个 Partition 创建 3 个相同的副本。
集群中的每个 Broker 存储一个或多个 Partition。
多个 Producer 和 Consumer 可同时生产和消费数据。
2.2、Broker
一台 Kafka 服务器就是一个 Broker，一个集群由多个 Broker 组成，一个 Broker 可以容纳多个 Topic。
Broker 和 Broker 之间没有 Master 和 Standby 的概念，它们之间的地位基本是平等的。
Kafka 集群包含一个或者多个服务器，服务器节点称为 Broker。
Broker 存储 Topic 的数据。如果某 Topic 有 N 个 Partition，集群有 N 个 Broker，那么每个 Broker 存储该 Topic 的一个 Partition。
如果某 Topic 有 N 个 Partition，集群有 (N+M) 个 Broker，那么其中有 N 个 Broker 存储该 Topic 的一个 Partition，剩下的 M 个 Broker 不存储该 Topic 的 Partition 数据。
如果某 Topic 有 N 个 Partition，集群中 Broker 数目少于 N 个，那么一个 Broker 存储该 Topic 的一个或多个 Partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致 Kafka 集群数据不均衡。
2.3、Topic
每条发布到 Kafka 集群的消息都有一个Topic。
- 物理上：不同 Topic 的消息分开存储
- 逻辑上：一个 Topic 的消息虽然保存于一个或多个 Broker 上，但用户只需指定消息的 Topic 即可生产或消费数据而不必关心数据存于何处
2.4、Producer
生产者，向 Kafka Topic 发布消息的客户端。
2.5、Partition
- Topic 中的数据分割为一个或多个 Partition。
- 每个 Topic 至少有一个 Partition。
- 每个 Partition 中的数据使用多个 Segment 文件存储。
- Partition 中的数据是有序的，不同 Partition 间的数据丢失了数据的顺序。
- 如果 Topic 有多个 Partition，消费数据时就不能保证数据的顺序。
- 在需要严格保证消息的消费顺序的场景下，需要将 Partition 数目设为 1。
2.6、Consumer
- 消费者可以从 Broker 中读取数据。
- 消费者可以消费多个 Topic 中的数据。
2.7、Consumer Group
每个 Consumer 属于一个特定的 Consumer Group(可为每个 Consumer 指定 Group Name，若不指定 Group Name 则属于默认的 Group)。
2.8、Leader
每个 Partition 有多个副本，其中有且仅有一个作为 Leader，Leader 是当前负责数据的读写的 Partition。
2.9、Follower
- Follower 跟随 Leader，所有写请求都通过 Leader 路由，数据变更会广播给所有 Follower，Follower 与 Leader 保持数据同步。
- 如果 Leader 失效，则从 Follower 中选举出一个新的 Leader。
- 当 Follower 与 Leader 挂掉、卡住或者同步太慢，Leader 会把这个 Follower 从 “in sync replicas”(ISR)列表中删除，重新创建一个 Follower。
2.10、Offset
消息在 Topic 的 Partition 中的位置，同一个 Partition 中的消息随着消息的写入，其对应的 Offset 也自增。结构图如下：
2.11、Replica
副本的意思
Topic 的 Partition 含有 N 个 Replica，N 为副本因子。
副本的类型有Leader和Follower
Leader：只有一个，处理 Partition 的所有读写请求
Follower ：除了Leader之外的所有副本，Follower 会定期去同步 Leader 上的数据
2.12、Message
通讯的基本单位，即消息。
2.13、ZooKeeper
- 存放 Kafka 集群相关元数据的组件。
- 在 ZK 集群中会保存 Topic 的状态消息：例如
- 分区的个数
- 分区的组成
- 分区的分布情况等
- 保存 Broker 的状态消息
- 保存消费者的消息等
3、Kafka架构
3.1、拓扑结构
- Kafka 集群由若干个 Broker 组成，Topic 由若干个 Partition 组成，每个 Partition 里面的消息通过 Offset 来获取。
- 生产者：将消息发送给某个 Topic，每个Topic对应一个消息队列(Queue)
- 消费者：订阅某个Topic的消息。
3.2、消息发送简易流程
一个典型的 Kafka 集群组成
- 若干个 Producer
- 使用 Push 模式将消息发布到 Broker 上
- 若干个 Broker
- Kafka 集群支持水平扩展，一般 Broker 数量越多，整个 Kafka 集群的吞吐率也就越高
- 若干个 Consumer Group
- Consumer 使用 Pull 模式从 Broker 上订阅并消费消息
- 一个 ZooKeeper 集群。
- Kafka 通过 ZooKeeper 管理集群配置。