Kafka基础概念及架构

一、Kafka 介绍

Kafka是?个分布式、分区的、多副本的、多?产者、多订阅者，基于zookeeper协调的分布式?志系统（也可以当做MQ系统），常?可以?于web/nginx?志、访问?志，消息服务等等。
Kafka主要应?场景：?志收集系统和消息系统

Kafka主要设计目标：

• 以时间复杂度为O(1)的?式提供消息持久化能?，即使对TB级以上数据也能保证常数时间的访问性能。
• ?吞吐率。即使在?常廉价的商?机器上也能做到单机?持每秒100K条消息的传输。
• ?持Kafka Server间的消息分区，及分布式消费，同时保证每个partition内的消息顺序传输。
• 同时?持离线数据处理和实时数据处理。
• ?持在线?平扩展

Kafka消息传递模式：发布-订阅模式（不支持点对点模式）

Kafka消息推拉模式：Kafka只有消息的拉取，没有推送，可以通过轮询实现消息的推送

1. Kafka在?个或多个可以跨越多个数据中?的服务器上作为集群运?。
2. Kafka集群中按照主题分类管理，?个主题可以有多个分区，?个分区可以有多个副本分区。
3. 每个记录由?个键，?个值和?个时间戳组成。

Kafka 的 4 个核心 API：

1. Producer API：允许应?程序将记录流发布到?个或多个Kafka主题。
2. Consumer API：允许应?程序订阅?个或多个主题并处理为其?成的记录流。
3. Streams API：允许应?程序充当流处理器，使??个或多个主题的输?流，并?成?个或多个输出主题的输出流，从?有效地将输?流转换为输出流。
4. Connector API：允许构建和运?将Kafka主题连接到现有应?程序或数据系统的可重??产者或使?者。例如，关系数据库的连接器可能会捕获对表的所有更改。

二、Kafka 优势

?吞吐量：单机每秒处理??上百万的消息量。即使存储了许多TB的消息，它也保持稳定的性能。
?性能：单节点?持上千个客户端，并保证零停机和零数据丢失。
持久化数据存储：将消息持久化到磁盘。通过将数据持久化到硬盘以及replication防?数据丢失。

• 零拷贝
• 顺序读，顺序写
• 利?Linux的?缓存

分布式系统：易于向外扩展。所有的Producer、Broker和Consumer都会有多个，均为分布式的。?需停机即可扩展机器。多个Producer、Consumer可能是不同的应?。
可靠性：Kafka是分布式，分区，复制和容错的。
客户端状态维护：消息被处理的状态是在Consumer端维护，?不是由server端维护。当失败时能?动平衡。
?持online和offline的场景
?持多种客户端语?：Kafka?持Java、.NET、PHP、Python等多种语?。

三、Kafka 应用场景

?志收集：?个公司可以?Kafka可以收集各种服务的Log，通过Kafka以统?接?服务的?式开放给各种Consumer；
消息系统：解耦?产者和消费者、缓存消息等；
?户活动跟踪：Kafka经常被?来记录Web?户或者App?户的各种活动，如浏览??、搜索、点击等活动，这些活动信息被各个服务器发布到Kafka的Topic中，然后消费者通过订阅这些Topic来做实时的监控分析，亦可保存到数据库；
运营指标：Kafka也经常?来记录运营监控数据。包括收集各种分布式应?的数据，?产各种操作的集中反馈，?如报警和报告；
流式处理：?如Spark Streaming和Storm。

四、Kafka 基本架构

消息和批次
消息：

• Kafka 的数据单元称为消息。消息可以看做数据库表的一条“行记录”，消息由字节数组组成。
• 消息有键，键也是一个字节数组。当消息需要写入不同的分区时，会使用键进行分区。

批次：

• 消息可以分批写入Kafka，一批次消息属于同一个主题和分区。
• 分批次写入消息可以减少网络开销。批次越大，单位时间处理消息越多，单个消息传输时间越长；批次消息数据会被压缩，这样能提升传输和存储能力，也需要更多的计算处理。

模式

• 消息模式（schema）有许多可?的选项，以便于理解。如JSON和XML，但是它们缺乏强类型处理能?
• Kafka 使用的 Apache Avro（了解即可）。
• 数据格式的?致性对Kafka很重要，因为它消除了消息读写操作之间的耦合性

主题和分区

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

生产者和消费者
生产者：

• ?产者创建消息。?个消息被发布到?个特定的主题上，?产者在默认情况下把消息均衡地分布到主题的所有分区上
  • 直接指定消息的分区
  • 根据消息的key散列取模得出分区
  • 轮询指定分区

消费者：

• 消费者消费消息。消费者通过偏移量来区分已经读过的消息
• 消费者是消费组的?部分。消费组保证每个分区只能被?个消费者使?，避免重复消费

broker和集群

• 一个独立的Kafka服务器称为broker。
• broker接收来??产者的消息，为消息设置偏移量，并提交消息到磁盘保存
• broker为消费者提供服务，对读取分区的请求做出响应，返回已经提交到磁盘上的消息
• 单个broker可以轻松处理数千个分区以及每秒百万级的消息量
• 每个集群都有?个broker是集群控制器（?动从集群的活跃成员中选举出来，通过Zookeeper的Master选举）控制器负责管理?作
  • 将分区分配给broker
  • 监控broker
• 集群中一个分区属于一个 broker，该broker称为分区首领
• 一个分区可以分配给多个broker，此时会发生分区复制。分区复制提供了消息冗余和高可用。副本分区不负责处理消息的读写

五、Kafka 核心概念

5.1 生产者 Producer

生产者创建消息，将消息发布到主题（Topic）中。一般一个消息会被发布到指定的主题上，然后通过以下几种方式发布到指定主题分区：

• 默认情况下通过轮询把消息均衡地分布到主题的所有分区上
• 有时我们可以将消息指定发到某一个分区上。通常是通过消息键和分区器来实现的，分区器可以为消息键计算出一个散列值，通过这个散列值就可以映射到相应的分区上
• 也可以自定义分区器，我们可以根据不同的业务规则将消息映射到不同分区。

5.2 消费者 Consumer

消费者从主题中读取消息

• 消费者可以订阅一个或多个主题，并按照消息生成的顺序读取
• 消费者可以通过偏移量（Offset）区分已经读取的消息
  • 偏移量是另?种元数据，它是?个不断递增的整数值，在创建消息时，Kafka 会把它添加到消息?
  • 在给定的分区?，每个消息的偏移量都是唯?的
  • 消费者把每个分区最后读取的消息偏移量保存在Zookeeper 或Kafka（现在是存在Kafka上的） 上，如果消费者关闭或重启，它的读取状态不会丢失
• 消费者是消费组的一部分。消费组保证每个分区只能被一个消费者使用
• 如果某一个消费者失效，就会进行再平衡，重新给消费组中的消费者分配消费分区，以达到高可用的目的

5.3 服务器 Broker

一个独立的Kafka服务器就是一个 Broker。Broker为消费者提供服务，对读取分区的请求做出响应，返回已经提交到磁盘上的消息。

• 如果某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集群数据不均衡

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

• 控制器负责管理?作，包括将分区分配给broker 和监控broker

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

5.4 主题 Topic

每条发布到Kafka的消息都有一个类别，这个类别就是Topic。

5.5 分区 Partition

主题可以分为若干个分区，消息可以写主题的某一个分区中。
消息以追加的方式写入分区，然后以先进后出的方式被读取。
Kafka 无法在整个主题范围内保证消息的顺序，但是可以保证消息在单个分区中的顺序。
Kafka 通过分区实现数据冗余和伸缩性。
在需要严格保证消息顺序的情况下，需要将分区设置为 1 。

5.6 副本 Replicas

5.6.1 副本概念

消息被写入主题，每个主题有多个分区，每个分区有多个副本。副本被保存在broker 上，每个broker 可以保存成百上千个属于不同主题和分区的副本
副本有两种类型：

• ?领副本：每个分区都有?个?领副本。为了保证?致性，所有?产者请求和消费者请求都会经过这个副本
• 跟随者副本：?领以外的副本都是跟随者副本。跟随者副本不处理来?客户端的请求，它们唯?的任务就是从?领那?复制消息，保持与?领?致的状态。如果?领发?崩溃，其中的?个跟随者会被提升为新?领

5.6.1 副本介绍

Kafka 通过副本保证高可用。副本分为?领副本(Leader)和跟随者副本(Follower)。
跟随者副本包括同步副本和不同步副本，在发??领副本切换的时候，只有同步副本可以切换为?领副本。

AR
分区中的所有副本统称为AR（Assigned Repllicas）。AR=ISR+OSR

ISR

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

OSR

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

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

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

5.7 偏移量 Offset

5.7.1 生产者 Offset

消息写?的时候，每?个分区都有?个offset，这个offset就是?产者的offset，同时也是这个分区的最新最?的offset
有些时候没有指定某?个分区的offset，这个?作kafka帮我们完成

5.7.2 消费者 Offset

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