Kafka概念与基本架构

1. Kafka介绍

Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多生产者、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。

主要应用场景：日志收集系统和消息系统

Kafka主要设计目标如下：

• 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间的访问性能

• 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输

• 支持Kafka Server间的消息分区，及分布式消息，同时保证每个partition内的消息顺序传输

• 同时支持离线数据处理和实时数据处理

• 支持在线水平扩展

  
  
  image-20210312102002488.png

有两种主要消息传递模式：点对点传递模式、发布-订阅模式。大部分消息系统选用发布-订阅模式。

Kafka就是一种发布-订阅模式。

对消息中间件，消息分推拉两种模式。Kafka只有消息的拉取，没有推送，可以通过轮询实现消息的推送

Kafka 特性：

Kafka在一个或多个可以跨越多个数据中心的服务器上作为集群运行。

Kafka集群集群中按照主题分类管理，一个主题可以有多个分区，一个分区可以有多个副本分区

每个记录由一个键，一个值和一个时间戳组成

Kafka四个核心API

• Producer API

  允许应用程序将记录流发布到一个或多个Kafka主题。

• Consumer API

  允许应用程序订阅一个或多个主题并处理为其生成的记录流

• Streams API

  允许应用程序充当流处理器，使用一个或多个主题的输入流，并生成一个或多个输出主题的输出流，从而有效地将输入流换为输出流

• Connector API

  允许构建和运行将Kafka主题链接到现有应用程序或数据系统的可重用生产者或使用者

  例如：关系数据库的连接器可能会捕获对表的所有更改

2. Kafka优势

• 高吞吐量

  单机每秒处理几十上百万的消息量。即使存储了许多TB的消息，它也保持稳定的性能。

• 高性能

  单节点支持上千个客户端，并保证零停机和零数据丢失。

• 持久化数据存储

  将消息持久化到磁盘，通过将数据持久化到硬盘以及replication防止数据丢失。

  • 零拷贝

  • 顺序读，顺序写

  • 利用Linux的也缓存

• 分布式系统，易于向外扩展

  所有的Producer、Broker和Consumer都会有多个，均为分布式的。无须停机即可扩展机器。多个Producer、Consumer可能是不同的应用。

• 可靠性

  Kafka是分布式，分区、复制和容错的。

• 客户端状态维护

  消息被处理的状态是在Consumer端维护，而不是由Server端维护。当失败时能自动平衡

• 支持online和offline的场景

• 支持多种客户端语言

  Kafka支持Java、.NET、PHP、Python等多种语言

3. Kafka应用场景

• 日志收集

  一个公司可以用Kafka收集各种服务的Log，通过Kafka以统一接口服务的方式开发给各种Consumer

• 消息系统

  解耦生产者和消费者、缓存消息等。

• 用户活动跟踪

  Kafka经常被用来记录Web用户或者APP用户的各种活动，如浏览网页，搜索，点击等活动，这些活动信息被各个服务发布到Kafka的Topic中，然后消费者通过订阅这些Topic来做实时的监控分析，亦可保持到数据库。

• 运营指标

  Kafka也经常用来记录运营监控数据。包括手机各种分布式应用的数据，生产各种操作集中反馈，比如报警和报告

• 流失处理

  比如Spark Streaming 和Storm

4. 基本架构

4.1 消息和批次

Kafka的数据单元称为消息。可以把消息看成是数据库里的一个数据行或一条记录。消息由字节数组组成。

消息有键，键也是一个字节数组。当消息以一种可控的方式写入不同的分区时，会用到键。

为了提高效率，消息被分批写入Kafka。批次就是一组消息，这些消息属于同一个主体和分区。

把消息分成批次可以减少网络开销。批次越大，单位时间内处理的消息就越多，单个消息的传输时间就越长。批次数据会被压缩，这样可以提升数据的传输和存储能力，但是需要更多的计算处理。

4.2 模式

消息模式（schema）有许多可用的选项，以便于理解。如JSON和XML，但是它缺乏强类型处理能力。Kafka的许多开发者喜欢使用Apache Avro。Avro提供了一种紧凑的序列化格式，模式和消息体分开。当模式发生变化时，不需要重新生成代码，它还支持强类型和模式进化，其版本即向前兼容，也向后兼容。

数据格式的一致性对Kafka很重要，因为它消除了消息读写操作之间的耦合性。

4.3 主体和分区

Kafka的消息通过主体进行分类。主题可比是数据库的表或者文件系统里的文件夹。主题可以被分为若干分区，一个主题通过分区分布于Kafka集群中，提供了横向扩展的能力。

image-20210312110958520.png

4.4 生产者和消费者

生产者创建消息。消费者消费消息。

一个消费被发布到一个特定的主题上。

生产者在默认情况下把消息均衡地分布到主题的所有分区上：

1. 直接指定消息的分区

2. 根据消息的key散列取模得出分区

3. 轮询指定分区

消费者通过偏移量来区分已经读过的消息，从而消费消息。

消费者是消费组的一部分。消费组保证每个分区只能被一个消费者使用，避免重复消费。

image-20210312111420527.png

4.5 Broker和集群

一个独立的Kafka服务器称为broker。broker接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。broker为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。单个broker可以轻松处理数千个分区以及每秒百万级的消息量

image-20210312111655113.png

每个集群都有一个broker是集群控制器（自动从集群的活跃成员中选举处理）

控制器负责管理工作：

• 将分区分配给broker

• 监控broker

集群中一个分区属于一个broker，该broker称为分区首领

一个分区可以分配给多个broker，此时会发送分区复制。

分区复制提供了消息冗余，高可用。副本分区不负责处理消息的读写。

4.6 核心概念

4.6.1 Producer

生产者创建消息。

该角色将消息发布到Kafka的Topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。

一般情况下，一个消息会被发布到一个特定的主题上。

1. 默认情况下通过轮询把消息均衡地分布到主题的所有分区上。

2. 在某些情况下，生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的，分区器为键生成一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一分区上。

3. 生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区

4.6.2 Consumer

消费者读取消息。

1. 消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。

2. 消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka 会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在Zookeeper或Kafka上，如果消费者关闭或重启，它的读取状态不会丢失。

3. 消费者是消费组的一部分。群组保证每个分区只能被一个消费者使用。

4. 如果一个消费者失效，消费组里的其他消费者可以接管失效消费者的工作，再平衡，分区重新分配。

image-20210312120104284.png

4.6.3 Broker

一个独立的Kafka服务器被称为broker

broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。

1. 如果topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。

2. 如果topic有N个partition，集群有（N+M）个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。

3. 如果某个topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发送，这种情况容易导致Kafka集群数据不均衡。

broker是集群的组成部分。每个集群都有一个broker同时充当集群控制器的角色（自动从集群的活跃成员中选举出来）。

控制器复制管理工作，包括将分区分配给broker和监控broker

在集群中，一个分区从属于一个broker，该broker被称为分区的首领。

image-20210312120822076.png

4.6.4 Topic

每条发布到Kafka集群的消息都有一个类别，这个类别被称为一个Topic

物理上不同Topic的消息分开存储。

主题就好比数据库的表，尤其是分库分表之后的逻辑表。

4.6.5 Partition

主题可以被分为若干个分区，一个分区就是一个提交日志。

消息以追加的方式写入分区，然后以先入先出的顺序读取。

无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。

Kafka通过分区来实现数据冗余和伸缩性。

在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1

image-20210312134028017.png

4.6.6 Replicas

Kafka 使用主题来组织数据，每个主题被分为若干个分区，每个分区有多个副本。那些副本被保存在broker上，每个broker可以保存成百上千个属于不同主题和分区的副本。

副本有两种类型

• 首领副本

  每个分区都有一个首领副本。为了保证一致性，所有生产者请求和消费者请求都会经过这个副本。

• 跟随者副本

  首领意外的副本都是跟随者副本。跟随者副本不处理来自客户端的请求，他们唯一的任务就是从首领那里复制消息，保持与首领一直的状态。如果首领发生崩溃，其中的一个跟随者会被提升为新首领。

4.6.7 Offset

4.6.7.1 生产者Offset

消息写入的时候，每一个分区都有一个Offset，这个Offset就是生产者的Offset，同时也是这个分区的最新最大的offset。

有些时候没有指定某一个分区的offset，这个工作kafka帮我们完成。

image-20210312134601962.png

4.6.7.2 消费者offset

image-20210312135427705.png

这是某一个分区的offset情况，生产者写入的offset是最新最大的值是12，而当Consumer A进行消费时，从0开始消费，一直消费到9，消费者的offset就记录在9，Consumer B就记录在11。等下一次他们再来消费时，他们可以选择接着上一次的位置消费，当然也可以选择从头消费，或者跳到最近的记录从“现在”开始消费。

4.8 副本

Kafka 通过副本保证高可用。副本分为首领副本（Leader）和跟随者副本（Follower）。

跟随者副本包括同步副本和不同步副本，在发生首领副本切换的时候，只有同步副本可以切换为首领副本。

4.8.1 AR

分区中的所有副本统称为AR（Assigned Replicas）

AR=ISR + OSR

4.8.1.1 ISR

所有与leader副本保持一定程度同步的副本（包括Leader）组成ISR（In-Sync Replicas）,ISR集合是AR集合中的一个子集。消息会先发送到leader副本，然后follower副本才能从leader副本中拉取消息进行同步，同步期间内follower副本相对于leader副本而言会有一定程度的滞后。前面所说的“一定程度”是指可以忍受的滞后范围，这个范围可以通过参数进行配置。

4.8.1.2 OSR

与leader副本同步滞后过多的副本（不包括leader）副本，组成OSR（Out-Sync Replicas）。在正常情况下，所有的follower副本都应该与leader副本保持一定程度的同步，即AR=ISR，OSR集合为空

4.8.2 HW

HW是High Watermak的缩写，俗称高水位，它表示了一个特定消息的偏移量（offset），消费者只能拉取到这个offset之前的消息。

4.8.3 LEO

LEO是 Log End Offset的缩写，它表示了当前日志文件中下一条待写入消息的offset

image-20210312142439994.png