1.1 发布与订阅消息系统

数据(消息)的发送者(发布者)不会直接把消息发送给接收者,这是发布与订阅消息系统的一个特点。发布者以某种方式对消息进行分类,接收者(订阅者)订阅它们,以便接收特定类型的消息。发布与订阅系统一般会有一个 broker,也就是发布消息的中心点。

1.1.1 如何开始

发布与订阅消息系统的大部分应用场景都是从一个简单的消息队列或一个进程间通道开始的。

但是这样容易出现一种情况:公司因此要为数据队列维护多个系统,每个系统又有各自的缺陷和不足。而且,接下来可能会有更多的场景需要用到消息系统。此时真正需要的是一个单一的集中式系统,它可以用来发布通用类型的数据,它的规模可以随着公司业务的增长而增长。

1.2 Kafka 登场

Apache Kafka,一般被称为“分布式提交日志”或者“分布式流平台”。文件系统或数据库提交日志用来提供所有事务的持久记录,通过重放这些日志可以重建系统状态。同样地,Kafka 的数据是按照一定顺序持久化保存的,可以按需读取。此外,Kafka 的数据分布在整个系统里,具备数据故障保护性能伸缩能力。

1.2.1 消息和批次

  • Kafka 的数据单元被称为消息。类似于数据库中的一个“数据行”或一条“记录”。
  • 消息字节数组组成。
  • 消息可以有一个可选的元数据,又成为“键”。键也是一个字节数组,与消息一样。当消息以一种可控的方式写入不同的分区时,会用到键。
  • 为了提高效率,消息被分批次写入 Kafka。批次是指一组“消息”,这些消息属于同一个主题和分区。可以减少网络开销,但是会影响时间时间延迟和吞吐量。

1.2.2 模式(Schema)

对于 Kafka 来说,消息不过是晦涩难懂的字节数组。为了便于理解及支持强类型处理,产生了一些额外的数据结构。

Apache Avro 提供了一种紧凑的序列化格式,模式和消息体分开,当模式发生变化时,不需要重新生成代码;它还支持强类型和模式进化,其版本既向前兼容,也向后兼容。

数据格式的一致性消除了消息读写操作之间的耦合性。

1.2.3 主题和分区

  • Kafka 的消息通过主题进行分类。主题(Topic)类似于数据中的表(Table),或者文件系统中的文件夹(Directory)。
  • 主题可以被分为若干个分区,一个分区就是一个提交日志。消息以追加方式写入,按先入先出(FIFO)顺序读取。
  • 由于一个主题一般包含几个分区,因此无法在整个主题范围内保证消息的顺序,但可以保证消息在单个分区内的顺序。
  • 一个主题可以横跨多个服务器,提供强大性能。
  • 流(Stream)是一组从生产者移动到消费者的数据。
  • Kafka Streams、Apache Samza 和 Storm 以实时方式处理消息,即流式处理。Hadoop 被用于离线处理。

![包含多个分区的主题表示](/Users/raymond/Library/Application Support/typora-user-images/image-20210207134551097.png)

1.2.4 生产者和消费者

Kafka 的客户端就是 Kafka 系统的用户,分为生产者消费者,另有高级客户端,用于数据集成的 Kafka Connect API 和用于流式处理的 Kafka Streams。

  • 生产者
    • 生产者创建消息。一般一条消息会被发布到一个特定的主题。生产者在默认情况下把消息均衡地分布到主题的所有分区上。在某些情况下,生产者会把消息直接写到指定的分区。这通常是通过消息键分区器来实现的。
    • 分区器为键生成一个散列值,并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。
  • 消费者
    • 消费者订阅一个或多个主题,并按照消息生成的顺序读取它们。
    • 消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据,它是一个不断递增的整数值,在创建消息时,Kafka 会把它添加到消息里。
    • 消费者把每个分区最后读取的消息偏移量保存在 Zookeeper 或 Kafka 上,如果消费者关闭或重启,它的读取状态不会丢失。
    • 消费者是消费者群组的一部分,也就是说,会有一个或多个消费者共同读取一个主题。群组保证每个分区只能被一个消费者使用。
    • 消费者与分区之间的映射通常被称为消费者对分区的所有权关系。

消费者群组从主题读取消息

1.2.5 broker和集群

  • 一个独立的 Kafka 服务器被称为 broker。
  • broker 接收来自生产者的消息,为消息设置偏移量,并提交消息到磁盘保存。
  • broker 为消费者提供服务,对读取分区的请求作出响应,返回已经提交到磁盘上的消息。根据特定的硬件及其性能特征,单个 broker 可以轻松处理数 千个分区以及每秒百万级的消息量。
  • broker 是集群的组成部分。每个集群都有一个 broker 同时充当了集群控制器的角色(自动从集群的活跃成员中选举出来)。
  • 控制器负责管理工作,包括将分区分配给 broker 和监控 broker。
  • 在集群中,一个分区从属于一个 broker,该 broker 被称为分区的首领(Leader)
  • 一个分区可以分配给多个 broker,这个时候会发生分区复制。如下图

集群里的分区复制

  • 复制机制为分区提供了消息冗余,如果有一个 broker 失效,其他 broker 可以接管领导权。但是相关的消费者和生产者都要重新连接到新的首领(Leader)。
  • 保留消息(在一定期限内)是 Kafka 的一个重要特性。
  • 旧消息就会过期并被删除,可以自定义配置。Kafka broker 默认的消息保留策略:
    • 要么保留一段时间(比如 7 天);
    • 要么保留到消息达到一定大小的字节数(比如 1GB)。

1.2.6 多集群

多集群的好处:

  • 数据类型隔离
  • 安全需求隔离
  • 多数据中心(灾难恢复)

Kafka 的消息复制机制只能在单个集群里进行,不能在多个集群之间进行。Kafka 提供了一个叫作 MirrorMaker 的工具,可以用它来实现集群间的消息复制。

  • MirrorMaker 的核心组件包含了一个生产者和一个消费者,两者之间通过一个队列相连。
  • 消费者从一个集群读取消息,生产者把消息发送到另一个集群上。

下图展示了一个使用 MirrorMaker 的例子,两个“本地”集群的消息被聚集到一个“聚合”集群上,然后将该集群复制到其他数据中心。

多数据中心架构

1.3 为什么选择Kafka

  • 多个生产者:Kafka 可以无缝地支持多个生产者。
  • 多个消费者:Kafka 支持多个消费者从一个单独的消息流上读取数据。
  • 基于磁盘的数据存储。
  • 伸缩性。
  • 高性能。通过横向扩展生产者、消费者和 broker,Kafka 可以轻松处理巨大的消息流。在处理大量数据的同时,它还能保证亚秒级的消息延迟。

1.4 数据生态系统

Kafka 为数据生态系统带来了循环系统,如下图所示。它在基础设施的各个组件之间传递消息,为所有客户端提供一致的接口。

大数据生态系统

使用场景:

  • 活动跟踪:页面访问次数、点击量、添加用户资料。
  • 传递消息:向用户发送通知、邮件等。
  • 度量指标和日志记录。
  • 提交日志。
  • 流处理。

1.5 起源

起源于 LinkedIn。

评论