本文深入解析Kafka，涵盖Kafka的基本术语如topic、partition、producer、consumer、broker等，并介绍Kafka的总体数据流、生产流程、集群搭建模式，包括配置、环境准备、ZooKeeper结构等，同时讲解常用命令，如服务管理和数据操作，帮助读者全面理解Kafka运维。
目录
(一)、KAFKA简介
Kafka是一种高吞吐量的分布式发布订阅消息系统（消息引擎系统），简单点理解就是系统A发送消息给kafka（消息引擎系统），系统B从kafka中读取A发送的消息，而kafka就是个中间商。
Kafka的消息传递模式就是一种发布-订阅模式。在发布-订阅消息系统中，消息被持久化到一个topic中。与点对点消息系统不同的是，消费者可以订阅一个或多个topic，消费者可以消费该topic中所有的数据，同一条数据可以被多个消费者消费，数据被消费后不会立马删除。在发布-订阅消息系统中，消息的生产者称为发布者，消费者称为订阅者。
发布-订阅模式的示例图如下：
1、KAFKA基本术语
Kafka的相关术语及其之间的关系如下图所示：
说明：
- 上图中一个topic配置了3个partition。Partition1有两个offset：0和1。Partition2有4个offset。Partition3有1个offset。副本的id和副本所在的机器的id恰好相同。
- 如果一个topic的副本数为3，那么Kafka将在集群中为每个partition创建3个相同的副本。集群中的每个broker存储一个或多个partition。多个producer和consumer可同时生产和消费数据。
(1)、topic
- Kafka将消息分门别类，每一类的消息称之为一个主题（Topic）。一个topic可以有零个，一个或多个消费者订阅该主题的消息。一个topic实际是由多个partition组成的，遇到瓶颈时，可以通过增加partition的数量来进行横向扩容。单个parition内是保证消息有序。
- 类似于数据库的表名。
- Topic在逻辑上可以被认为是一个queue，每条消息都必须指定它的Topic，可以简单理解为必须指明把这条消息放进哪个queue里。对于传统的message queue而言，一般会删除已经被消费的消息，而Kafka集群会保留所有的消息，无论其被消费与否。
(2)、partition
- topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。
(3)、producer
- 生产者即数据的发布者，该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。
(4)、consumer
- 消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。
(5)、broker
- 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集群数据不均衡。
(6)、Consumer Group
- 每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。
- 同一Topic的一条消息只能被同一个Consumer Group内的一个Consumer消费，但多个Consumer Group可同时消费这一消息。
(7)、Leader
- 每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。
(8)、Follower
- Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。
2、KAFKA总体数据流图
一个典型的Kafka集群中包含若干Producer（可以是web前端产生的Page View，或者是服务器日志，系统CPU、Memory等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干Consumer Group，以及一个Zookeeper集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。
Producers往Brokers里面的指定Topic中写消息，Consumers从Brokers里面拉去指定Topic的消息，然后进行业务处理。图中有两个topic，topic 0有两个partition，topic 1有一个partition，三副本备份。可以看到consumer gourp 1中的consumer 2没有分到partition处理，这是有可能出现的，下面会讲到。
关于broker、topics、partitions的一些元信息用zk来存，监控和路由啥的也都会用到zk。
3、KAFKA生产流程
(1)、生产者发布消息
1）写入方式
producer 采用 push 模式将消息发布到 broker，每条消息都被 append 到 patition 中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障 kafka 吞吐率）。
2）消息路由
producer 发送消息到 broker 时，会根据分区算法选择将其存储到哪一个 partition。
其路由机制为：
- 指定了 patition，则直接使用；
- 未指定 patition 但指定 key，通过对 key 的 value 进行hash 选出一个
- patition patition 和 key 都未指定，使用轮询选出一个 patition。
3）写入流程
producer 写入消息序列图如下所示：
流程说明：
- producer 先从 zookeeper 的 "/brokers/.../state" 节点找到该 partition 的 leader
- producer 将消息发送给该 leader
- leader 将消息写入本地 log
- followers 从 leader pull 消息，写入本地 log 后 leader 发送 ACK
- leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 发送 ACK
(2)、broker保存消息
1）存储方式
物理上把 topic 分成一个或多个 patition（对应 server.properties 中的 num.partitions=3 配置），每个 patition 物理上对应一个文件夹（该文件夹存储该 patition 的所有消息和索引文件），如下：
2）存储策略
无论消息是否被消费，kafka 都会保留所有消息。有两种策略可以删除旧数据：
- 基于时间：log.retention.hours=168
- 基于大小：log.retention.bytes=1073741824
最低0.47元/天 解锁文章
扫一扫
1517
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
