Kafka 01-核心概念

一、基本概念

Kafka是一个分布式、分区的、多副本的、多生产者、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等。

1.1 特点：

• 消息持久化（以时间复杂度为O(1)的方式提供，即使对TB级以上数据也能保证常数时间的访问性能）。
• 高吞吐率（消息分批发送）。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输。
• 在主题中划分多个分区（FIFO队列），实现了横向扩展
• 通过分区副本，实现高可用
• 在一个消费者组中，每个分区只会被一个消费者消费：
  • 如果消费者数 < 分区数，则会有消费者消费多个分区
  • 如果消费者数 > 分区数，则会有消费者空闲（避免重复消费）
• 每个记录由键（可选）、值、时间戳组成。

对于消息中间件：

• 从消息传递模式上看，分为点对点模式、发布-订阅模式。Kafka是一种发布-订阅模式。

• 从消息消费模式上看，分为推、拉两种模式。Kafka只有消息的拉取，没有推送（可以通过轮询实现消息的推送）。

1.2 四个核心API：

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

1.3 如何保证消息的有序性？

• 无法保证整体上的有序性，只能保证同一分区上的消息是顺序消费的
• 可以在发送消息时，指定对应的分区（会有负载均衡的问题）
• 【推荐】可以在发送一组有序消息时，指定key，然后通过hash后取模，最后分配到同一个分区。
• 【极端】如果需要保证消息的严格有序，则将分区数设置为1即可

1.4 优势

• 高吞吐量：单机每秒处理几十上百万的消息量。即使存储了许多TB的消息，它也保持稳定的性能。
• 高性能：单节点支持上千个客户端，并保证零停机和零数据丢失。
• 持久化数据存储：将消息持久化到磁盘。通过将数据持久化到硬盘以及replication防止数据丢失。
  • 零拷贝
  • 顺序读，顺序写
  • 利用Linux的页缓存
• 分布式系统，易于向外扩展。所有的Producer、Broker和Consumer都会有多个，均为分布式的。无需停机即可扩展机器。多个Producer、Consumer可能是不同的应用。
• 可靠性 - Kafka是分布式，分区，复制和容错的。
• 客户端状态维护：消息被处理的状态是在Consumer端维护，而不是由server端维护。当失败时能自动平衡。
• 支持online和offline的场景。
• 支持多种客户端语言。Kafka支持Java、.NET、PHP、Python等多种语言。

1.5 应用场景

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

二、核心概念

2.1 消息和批次

Kafka的数据单元称为消息(message)。消息由字节数组组成。消息有键(key)，键也是一个字节数组。当消息以一种可控的方式写入不同的分区时，会用到键。

为了提高效率，消息被分批写入Kafka。批次就是一组消息，这些消息属于同一个主题和分区。把消息分成批次可以减少网络开销。批次越大，单位时间内处理的消息就越多，单个消息的传输时间就越长。批次数据会被压缩，这样可以提升数据的传输和存储能力，但是需要更多的计算处理。

2.2 消息模式

就是消息的数据格式

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

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

2.3 主题和分区

Kafka的消息通过主题进行分类。主题可以被分为若干分区，一个主题通过分区分布于Kafka集群中，提供了横向扩展的能力。

2.4 生产者和消费者

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

一个消息被发布到一个特定的主题上时，生产者通过如下3种策略，把消息均衡地分布到主题的所有分区上：

• 直接指定消息的分区
• 根据消息的key，hash取模得出分区
• 轮询所有分区。

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

消费组包括多个消费者。消费组保证每个分区只能被一个消费者使用，避免重复消费。

2.5 集群控制器与分区首领

一个独立的Kafka服务器称为broker。broker接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。broker为消费者提供服务，对读取分区的请求做出响应，返回已经保存到磁盘上的消息。

每个集群都有一个broker是集群控制器（通过抢占zk上的分布式锁来选举）。控制器负责管理工作：

• 将分区分配给broker
• 监控broker

集群中一个分区的首领副本在某个broker上，该broker称为分区首领。

一个分区可以分配给多个broker，此时会发生分区复制。分区的复制提供了消息冗余，高可用。

副本分区不负责处理消息的读写。

三、核心组件

3.1 Producer

生产者将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到对应的segment文件中。

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

• 默认情况（未指定key）下，通过轮询的方式，把消息分布到主题的各个分区上。
• 可以在发送消息时，直接指定发送的分区。
• 可以通过消息键和分区器，把消息直接写到指定的分区。
  • 分区器为键生成一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。
  • 生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区。

3.2 Consumer

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

• 偏移量：消费者通过检查消息的 偏移量(offset) 来区分已经读取过的消息。
  • 偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时，Kafka 会把它添加到消息里。
  • 在一个分区里，每个消息的偏移量都是唯一的。
  • 消费者把每个分区最后读取的消息偏移量保存在Kafka(低版本保存在zk) 上，如果消费者关闭或重启，它的读取状态不会丢失。
• 消费者组：消费者是消费组的一部分。群组保证每个分区只会被一个消费者使用。
• 再平衡：如果一个消费者失效，消费组里的其他消费者可以接管失效消费者的工作（给分区重新分配消费者）。

3.3 Broker

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

假设现集群中有一定数量的broker，某主题中有一定数量的partition：

• partition数量 == broker数量：每个broker存储该topic的一个partition。
• partition数量 < broker数量：其中有N个broker存储该topic的一个partition，剩下的broker不存储该topic的partition数据。
• partition数量 > broker数量：那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。

与broker相关的2个概念：

• 集群控制器
  • broker是集群的组成部分。每个集群都有一个节点既是broker，同时充当了集群控制器的角色（通过抢占zk中的分布式锁，自动从集群的活跃成员中选举出来）。
  • 控制器负责管理工作，包括将分区分配给broker 和监控broker。
• 分区首领：
  • 在集群中，一个leader分区从属于一个broker，该broker被称为分区首领。
  • 下图中，broker1是分区0的分区首领，broker2是分区1的分区首领。

3.4 Topic 主题

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

不同Topic的消息在物理上（不同文件夹）分开存储。

3.5 Partition 分区

• 主题可以被分为若干个分区，一个分区对应磁盘上的一个组文件。
• 消息以追加的方式写入分区，然后以先入先出的顺序从分区中读取。
• 无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。
• Kafka 通过分区来实现数据冗余和伸缩性。
• 在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。

kafka中的Partition相当于其他mq中的queue。

1.3.6 Replicas 副本

Kafka 使用主题来组织数据，每个主题被分为若干个分区，每个分区有多个副本，相同分区的副本被保存在不同的broker上

副本有以下两种类型：

• 首领副本(就是Leader分区)

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

• 跟随者副本

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

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

• AR

  分区中的所有跟随者副本统称为AR（Assigned Replicas），而AR=ISR OSR。

• ISR

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

• OSR

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

• HW

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

• LEO

  • LEO是Log End Offset的缩写，它表示了当前分区（partion/segment）中下一条**待写入（而未写入）**消息的offset。

3.7 Offset 偏移量

• 生产者Offset

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

• 消费者offset

  这是某一个分区的offset情况，生产者写入的offset是最新最大的值是12，Consumer A的offset就记录在9，Consumer B就纪录在了11（这里仅供理解，实际的消费者offset是根据消费者组记录的）。等下一次再来消费时，他们可以选择接着上一次的位置消费，当然也可以选择从头消费，或者跳到最近的记录并从“现在”开始消费。

这篇好文章是转载于：学新通技术网