从零开始学Kafka（一）初识

本文主要面向研发同学

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

注： 每个 ConsumerGroup 最好只对应一个 Topic
不然当其中一个 Topic 产生 Rebalance 影响的时候
会影响该 ConsumerGroup 对其他 Topic 的消费
至于什么是 Rebalance 等云天河同学有空再写了

需要安装的相关服务

以下服务的下载及安装细节 本文不作重点
请自行

Kafka 服务

以下很重要！！！
因为不同版本之间，可能差异较大
云天河将以 2.7.0 Kafka 版本作为教学版本
读者请使用与云天河一致的 Kafka 版本

Kafka Manager - 现在叫 CMAK

地址 https://github.com/yahoo/CMAK
用于查看集群、分区、offset等 , 如图 3-1

图 3-1
因为这个是 雅虎 很多年前做的开源了
对于 kafka 版本的支持也不那么全面

DiDi-Kafka-Manager

推荐用这个
地址 https://github.com/didi/LogiKM
支持用于查看、设置消费者组消费位移、数据情况、网络流量等

下期预告

这期我们大致了解 Kafka 是怎样一个运作方式
下期我们重点讲下 Kafka 消息为何可以持久化、Kafka 的瓶颈是啥、怎么实现的高吞吐