(一)初识 Kafka

文章目录

  • 1.发布与订阅消息系统
    • (1)什么是发布与订阅消息系统
    • (2)为什么 Kafka 是数据驱动型应用程序的关键组件
  • 2. Kafka 介绍
    • (1)消息和批次
    • (2)消息模式
    • (3)主题和分区
    • (4)生产者和消费者
    • (5)生产者和消费者
    • (6)多集群
  • 3. Kafka 的优势

1.发布与订阅消息系统

(1)什么是发布与订阅消息系统

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

(2)为什么 Kafka 是数据驱动型应用程序的关键组件

  • 把数据从源头移动到可以对它们进行分析处理的地方,然后再把得到的结果应用到实际场景中,这样才能确切地知道这些数据要告诉我们什么。这个过程完成得越快,组织的反应就越敏捷。在数据移动上花费的精力越少,就越能专注于核心业务。这就是为什么在数据驱动型企业中,数据管道会成为关键性组件。如何移动数据几乎变得与数据本身一样重要。

2. Kafka 介绍

  • Kafka 是一款基于发布与订阅模式的消息系统。一般被称为“分布式提交日志”或“分布式流式平台”。文件系统或数据库提交日志旨在保存事务的持久化记录,通过重放这些日志可以重建系统状态。同样,Kafka 的数据是按照一定的顺序持久化保存的,并且可以按需读取。此外,Kafka 的数据分布在整个系统中,具备数据故障恢复能力和性能伸缩能力。

(1)消息和批次

  • Kafka 的数据单元被称为消息。可以把消息看成数据库中的一个“数据行”或一条“记录”。消息由字节数组组成,对Kafka 来说,消息里的数据没有特殊的格式或含义。
  • 消息可以有一个可选的元数据,也就是键。键也是一个字节数组,与消息一样,对 Kafka 来说没有特殊含义。当需要以一种可控的方式将消息写入不同的分区时,需要用到键(参考:分区策略)。最简单的例子就是为键生成一个一致性哈希值,然后用哈希值对主题分区数进行取模,为消息选取分区。这样可以保证具有相同键的消息总是会被写到相同的分区中(前提是分区数量没有发生变化)。
  • 批次包含了一组属于同一个主题和分区的消息。如果每一条消息都单独穿行于网络中,那么就会导致大量的网络开销,把消息分成批次传输可以减少网络开销。(参考:kafka 生产者 batch.size 与 linger.ms 参数)

(2)消息模式

  • 一些简单的模式,比如 JavaScript Object Notation(JSON)和 Extensible Markup Language(XML),不仅易用,还具备良好的可读性。不过,它们缺乏强类型处理能力,不同版本之间的兼容性也不是很好
  • 很多 Kafka 开发者喜欢使用 Apache Avro,其最初是为 Hadoop 开发的一款序列化框架。Avro 提供了一种紧凑的序列化格式,模式和消息体是分开的,当模式发生变化时,无须重新生成代码。Avro 还支持强类型和模式演化,既向前兼容,也向后兼容。数据格式的一致性对 Kafka 来说非常重要,它消除了消息读写操作之间的耦合性。

(3)主题和分区

  • Kafka 的消息通过主题进行分类。主题就好比数据库的表或文件系统的文件夹。主题可以被分为若干个分区,一个分区就是一个提交日志。消息会以追加的方式被写入分区,然后按照先入先出的顺序读取。
  • 需要注意的是,由于一个主题一般包含几个分区,因此无法在整个主题范围内保证消息的顺序,但可以保证消息在单个分区内是有序的。图中所示的主题有 4 个分区,消息被追加写入每个分区的尾部。

(一)初识 Kafka_第1张图片

  • Kafka 通过分区来实现数据的冗余和伸缩。分区可以分布在不同的服务器上,也就是说,一个主题可以横跨多台服务器,以此来提供比单台服务器更强大的性能。此外,分区可以被复制,相同分区的多个副本可以保存在多台服务器上,以防其中一台服务器发生故障。
  • 通常会使用流这个词来描述 Kafka 这类系统中的数据。很多时候,人们会把一个主题的数据看成一个流,不管它有多少个分区。流是一组从生产者移动到消费者的数据。当我们讨论流式处理时,一般都是这样描述消息的。Kafka Streams、Apache Samza 和 Storm 这些框架以实时的方式处理消息,这就是所谓的流式处理。流式处理有别于离线处理框架(如 Hadoop)处理数据的方式,后者被用于在未来某个时刻处理大量的数据。

(4)生产者和消费者

  • Kafka 的客户端被分为两种基本类型:生产者和消费者。除此之外,还有其他高级客户端 API——用于数据集成的 Kafka Connect API用于流式处理的Kafka Streams。这些高级客户端 API 使用生产者和消费者作为内部组件,提供了更高级的功能。
  • 生产者创建消息。一条消息会被发布到一个特定的主题上。默认情况下,生产者会把消息均衡地分布到主题的所有分区中某些情况下,生产者会把消息直接写入指定的分区,这通常是通过消息键和分区器来实现的。分区器会为键生成一个哈希值,并将其映射到指定的分区,这样可以保证包含同一个键的消息被写入同一个分区。生产者也可以使用自定义的分区器,根据不同的业务规则将消息映射到不同的分区。
  • 消费者读取消息。消费者会订阅一个或多个主题,并按照消息写入分区的顺序读取它们。消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量(不断递增的整数值)是另一种元数据,在创建消息时,Kafka 会把它添加到消息里。在给定的分区中,每一条消息的偏移量都是唯一的,越往后消息的偏移量越大(但不一定是严格单调递增)。消费者会把每一个分区可能的下一个偏移量保存起来(通常保存在 Kafka 中),如果消费者关闭或重启,则其读取状态不会丢失。
  • 消费者可以是消费者群组的一部分,属于同一群组的一个或多个消费者共同读取一个主题群组可以保证每个分区只被这个群组里的一个消费者读取。如图所示的群组中,有 3 个消费者同时读取一个主题,其中的两个消费者各自读取 3 个分区中的 1 个分区,另外一个消费者读取其他 2 个分区。消费者与分区之间的映射通常被称为消费者对分区的所有权关系。通过这种方式,消费者可以读取包含大量消息的主题。而且,如果一个消费者失效,那么群组里的其他消费者可以接管失效消费者的工作。(参考:消费策略1,消费策略2)

(一)初识 Kafka_第2张图片

(5)生产者和消费者

  • 一台单独的 Kafka 服务器被称为 broker。broker 会接收来自生产者的消息,为其设置偏移量,并提交到磁盘保存。broker 会为消费者提供服务,对读取分区的请求做出响应,并返回已经发布的消息。根据硬件配置及其性能特征的不同,单个 broker 可以轻松处理数千个分区和每秒百万级的消息量。
  • broker 组成了集群。每个集群都有一个同时充当了集群控制器角色的 broker(自动从活动的集群成员中选举出来)。控制器负责管理工作,包括为 broker 分配分区和监控 broker。在集群中,一个分区从属于一个 broker,这个 broker 被称为分区的首领。一个被分配给其他 broker 的分区副本叫作这个分区的“跟随者”。分区复制提供了分区的消息冗余,如果一个 broker 发生故障,则其中的一个跟随者可以接管它的领导权。所有想要发布消息的生产者必须连接到首领,但消费者可以从首领或者跟随者那里读取消息

(一)初识 Kafka_第3张图片

  • broker 默认的消息保留策略:保留一段时间(如 7 天)或保留消息总量达到一定字节数(如 1 GB)。消息数量达到上限时,旧消息就会过期并被删除。所以,任意时刻,可用消息的总量都不会超过配置参数指定的大小。主题可以配置自己的保留策略,将消息保留到不再使用它们为止。

(6)多集群

  • 如果有多个数据中心,则需要在它们之间复制消息,让在线应用程序能够访问到多个站点的用户活动信息。需要注意的是,Kafka 的消息复制机制只能在单个集群中而不能在多个集群之间进行
  • Kafka 提供了一个叫作 MirrorMaker 的工具,我们可以用它将数据复制到其他集群中MirrorMaker 的核心组件包括一个消费者和一个生产者,它们之间通过队列相连。消费者会从一个集群读取消息,生产者则会把消息发送到另一个集群中。图中是使用MirrorMaker 的例子,两个“本地”集群的数据被集合到一个“聚合”集群中,然后聚合集群的数据再被复制到其他数据中心。

(一)初识 Kafka_第4张图片

3. Kafka 的优势

  • 支持多个生产者。
  • Kafka 也支持多个消费者从一个单独的消息流读取数据,而且消费者之间互不影响多个消费者还可以组成一个群组,它们共享一个消息流,并保证整个群组只处理一次给定的消息
  • 允许消费者非实时地读取消息。这要归功于 Kafka 的数据保留特性。消息会被提交到磁盘,并根据设置的保留策略进行保存。每个主题可以设置单独的保留策略,以满足不同消费者的需求。各个主题还可以保留不同数量的消息。消费者可能会因为处理速度慢或突发的流量高峰而无法及时读取消息,在这种情况下,持久化的数据可以保证数据不会丢失。消费者可以在应用程序维护期间离线一小段时间,无须担心消息丢失或被堵塞在生产者端。消费者也可以被关闭,但消息会继续保留在 Kafka 中。消费者被重启之后,可以从上次中断的地方继续处理消息
  • 用户可以在开发阶段使用单个 broker,然后再扩展到包含 3 个 broker 的小型开发集群。随着数据量不断增长,在部署到生产环境时,集群可以包含上百个 broker。对在线集群进行扩展丝毫不影响系统的整体可用性。也就是说,一个包含多个 broker 的集群,即使个别broker 失效,仍然可以持续地为客户端提供服务。要提高集群的容错能力,需要配置较高的复制系数。
  • 通过横向扩展生产者、消费者和 broker,Kafka 可以轻松处理巨大的消息流。在处理大量数据的同时,它还能保证亚秒级的消息延迟。
  • Kafka 核心项目还加入了一些流式平台特性,从而使开发人员能够更容易执行一些常见的任务。我们可以用 Kafka Connect 从一个源数据抽取数据并将其推送到 Kafka,或者从 Kafka 抽取数据并将其推送到另一个接收数据的系统。Kafka Streams 提供了一个开发库,开发人员可以用它开发具备伸缩性和容错能力的流式处理应用程序。

你可能感兴趣的:(Kafka,kafka,大数据,分布式,java)