从零开始学Kafka（一）初识

2020-07-05 18:52:54 消息队列 2028 1

本文主要面向研发同学

Kafka 是什么

是一种高吞吐量的分布式发布订阅消息系统
大致流程如 图 1-1

图 1-1

订阅者获取消息的方式有两种
如 图 1-1 中若 S 直接推(Push)给订阅者
这可能会在订阅者接收消息不及时的情况下丢失消息

Kafka 主要是使用的拉(Pull)方式
如 图 1-1 中订阅者自己从 S 中拉取消息给到自己这样数据就不会丢了

Kafka 出现的背景

用作 LinkedIn 的活动流和运营数据处理管道的基础

活动流 数据包括页面访问量、被查看内容方面的信息以及搜索情况等内容
这种数据通常的处理方式是先把各种活动以日志的形式写入某种文件，然后周期性地对这些文件进行统计分析

运营数据 是服务器的性能数据（CPU、IO 使用率、请求时间、服务日志等等数据)
运营数据的统计方法种类繁多

Kafka 有什么特性

消息可持久化
同时为发布和订阅提供高吞吐量
支持通过Kafka服务器与消费机集群来分区消息
它支持多订阅者，当失败时能自动平衡消费者

Kafka 系统结构

首先简单介绍下系统结构中会遇到的术语

Message
- 消息通信的基本单位
- 每条消息只能被 ConsumerGroup 中的一个 Consumer 消费，但是可以被多个ConsumerGroup消费
Broker
- 已发布的消息保存在一组服务器中，称之为Kafka集群。集群中的每一个服务器都是一个代理(Broker)
Topic
- Message 的一种逻辑分类每一类消息称之为一个主题
- 相同 Topic 的消息放在一个 Topic 里
Partition
- Topic 物理上的分组，一个 Topic 可以分为多个组
- 每个 Partition 是一个有序的队列
- 每个 Message 经过一系列策略计算，可以知道自己应该存储到哪个 Partition 里
Offset
- Partition 中的每条消息都会被分配一个有序ID 也叫做偏移量
Producer
- 生产者用于发布消息 --- 将 Message 发布到 Kafka 指定 Topic
Consumer
- 消费者 --- 拉取消息、提交当前 Topic 对应 Partition 最后完成处理的 Offset 在哪里
- 每个消费者都需要设置一个 GroupID
ConsumerGroup
- 相同的 GroupID 的消费者将视为同一个消费者组
- 0.9版本开始消费进度存储到 Broker 中
Leader
- 负责给定 Partition 的所有读取和写入的节点
Follower
- Leader 对应的从节点
Replication
- Partition 的备份。不读取或写入数据。它们用于防止数据丢失

此外还会涉及一个运维组件 Zookeeper
它是用于管理和协调 Kafka 代理的---维护它们的集群状态

发送消息到 Kafka

大致流程如 图 2-1

图 2-1

作为一个 MQ 当然也得处理下无消息丢失的问题

确认消息都同步成功了 acks = all
重试次数 retry > 0
发送消息一定要以 callback 形式处理

Kafka 与 Zookeeper 的基础关系

Broker 注册、Topic 注册、Follower选举Leader等都由 Zookeeper 帮助完成

大致关系如 图 2-2

图 2-2

消费端拉取消息

大致流程如 图 2-3

图 2-3

在 图 2-3 中这个业务消费端对应的 Topic 集群中只有两个 Partition
业务消费端起了两个连接去执行消息的业务消费逻辑
ConsumerGroup 里面有 3 个 Consumer
其中有一个 Consumer 就是闲置的 Consumer

Partiton、Consumer、业务消费端 Client 的关联关系如 图 2-4

图 2-4

Q：我们可以想象一下如果 ConsumerGroup 中 Consumer 数量小于对应 Topic 的 Partition 数量会怎样  
A：肯定某些 Consumer 会轮询多个 Partition 又因为 Consumer 与 业务消费端是一对一的关系 所以就算增加业务消费端数量也是无济于事

所以最好 Consumer 者数量与 Partition 数量保持一致

此外要保证消息真的是被消费了最好是设置成手动提交 ConsumerGroup 对应该 Partition 的 Offset