BigDataGuide

1.kafka入门

概念

Apache Kafka是一个分布式流处理平台

一个流处理平台应该有三个关键能力

  1. 发布和订阅记录流，类似于消息队列或企业消息传递系统。

  2. 以容错的持久方式存储记录流。

  3. 当记录发生时处理它们的流。

Kafka适合的应用

  • 构建实时流数据通道为了可靠的得到数据在系统和应用之间

  • 构建实时流处理应用为了转换或者反馈这个数据的流

Kafka的一些概念

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

  • Kafka集群将记录流存储在称为topic的类别中。

  • 每个记录由 一个键、一个值和一个时间戳 组成。

Kafka的5个核心API

  • Prodcuer API

  • Consumer API

  • Streams API

  • Connector API

  • Admin API

Topics和Logs

Topic

  • topic是将记录发布到一个category或者订阅源名称。Kafka中的Topic始终是多用户的，因此 一个Topic可以有零个，一个或者多个消费者来订阅写入该topic的数据 。

  • 对于每个Topic， Kafka集群都会去维护一个分区日志 ，如下:

  • 每个分区都是有序的、不变的记录序列， 这些记录连续地附加到结构化的commit log中 。分别为分区的记录分配一个序列ID号，称为offset，该ID号唯一标示分区中的每个记录 。

  • Kafka集群使用可配置的保留期限持久保留所有已发布的记录(无论是否使用它们) 。如果保留策略设置为2天，则在发布记录后的俩天内，该记录可供使用，之后将被丢弃以释放空间 。Kafka的性能相对于数据大小实际上是恒定的 ，因此长时间存储数据不是问题。

  • 实际上，基于每个消费者保留的唯一元数据是该消费者在commit log中的offset或位置 。该 offset由消费者控制 :通常，消费者在读取记录时会线性地推进其offset ，但实际上，由于位置是由消费者控制的，因此它可以按任何顺序来使用记录 。例如。消费者可以重置到较旧的offset以重新处理过去的数据，或者跳到最近的记录并从"现在"开始使用。

  • 日志中的分区有几个用途 。首先，它们允许日志扩展到一个服务器所能容纳的范围之外 。每个单独的分区必须适合承载它的服务器，但是一个topic可能有多个分区，因此它可以处理任意数量的数据 。

分布式

  • 日志的分区分布在Kafka集群中的服务器上，每个服务器处理数据和共享分区的请求 。为了容错 ，每个分区被复制到大量可配置的服务器上 。

  • 每个分区有一个充当“领导者”的服务器和零个或多个充当“追随者”的服务器 。 leader处理分区的所有读和写请求，而follower被动地复制leader。如果领导者失败，其中一个追随者将自动成为新的领导者。 每个服务器充当它的一些分区的领导者和其他分区的追随者，因此集群内的负载非常平衡 。

Geo-副本

  • Kafka MirrorMaker 提供geo-replication支持对于你的集群，使用MirrorMaker，消息可以跨·多个数据中心或云区域进行复制· 。您可以在用于备份和恢复的active/passive场景中使用它;或者在active/active场景中，将数据放置到离用户更近的地方，或者支持数据位置需求。

生产者

  • 生产者们发布数据到它们选择的topic中。生产者负责选择将哪个记录分配给topic中的哪个分区 。这可以以循环的方式完成 ，只是为了平衡负载 ，也可以根据某种语义划分函数(比如基于记录中的某个键)来完成 。

消费者

  • 消费者使用消费者组名称和发布到topic标记自己 的每个记录将传递到每个订阅消费者组中的一个消费者实例 。消费者实例可以在单独的进程中，也可以在单独的机器上。

  • 如果全部的消费者实例有相同的消费者组，然后这些记录将有效地在使消费者实例上进行负载平衡 。

  • 如果全部的消费者实例有不同的消费者组，然后每个记录将会广播全部消费者处理 。

  • 一个包含四个分区(P0-P3)和两个消费者组的两台服务器Kafka集群。消费者组A有两个消费者实例，而组B有四个。

  • 然而，更常见的是，我们发现topic有少量的消费者组，每个“逻辑订阅者”对应一个用户组。每个组由许多用于可伸缩性和容错的消费者实例组成。这只不过是发布-订阅语义，其中订阅者是一个消费者集群，而不是单个进程 。

  • Kafka中实现消费的方法是在消费者实例的日志中划分分区 ，这样每个实例在任何时候都是分区“公平共享”的唯一消费者 。这个保持组成员身份的过程是由Kafka协议动态处理的 。如果新的实例加入组，它们将从组的其他成员那里接管一些分区 ;如果一个实例死亡， 它的分区将分配给其余的实例 。

  • Kafka只提供分区内记录的总顺序，而不提供主题中不同分区之间的总顺序 。对大多数应用程序来说，按分区排序和按键分区数据的能力已经足够了。但是，如果您需要记录的总顺序，则可以使用只有一个分区的topic来实现这一点 ，尽管这意味着每个消费者组只有一个消费者进程。

多租户

  • 您可以将Kafka部署为一个多租户解决方案 。通过配置哪些topic可以生产或消费数据 ，可以启用多租户。还有对限额的操作支持。管理员可以对请求定义和强制执行限额，以控制客户端使用的代理资源。

Kafka的几点保证

  • 生产者发送到特定主题分区的消息将按照发送的顺序追加 。也就是说，如果记录M1是由与记录M2相同的生产者发送的，并且M1是先发送的，那么M1的偏移量将比M2低，并出现在日志的前面。

  • 消费者实例按记录在日志中存储的顺序查看记录 。

  • 对于具有复制因子N的topic，我们将容忍至多N-1个服务器故障 ，而 不会丢失提交到日志的任何记录 。

Kafka产生

消息和批次

消息

  • Kafka的消息单元称为消息。可以把其看为数据库中的”数据行“或一条“记录”。

  • 消息由字节数组组成，消息里的数据没有特别的格式或含义，消息可以有一个可选的元数据，也就是键 key，键也是一个字节数组。当消息以可控的方式写入不同的分区时，会用到键。

批次

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

  • 需要在时间延迟和吞吐量做出权衡 :批次越大， 单位时间内处理的消息就越多，单个消息的传输时间就越长 。 批次数据会被压缩，这样可以提升数据传输和存储能力，但要做更多的计算 。

模式

  • 用于解析字节数组消息的模式，类似于Avro，消息体和模式是分开的 ，如此消除了消息读写操作的耦合性。

topic和分区

  • Kafka的消息通过Topic进行分类。 Topic相当于数据库的表，或者文件系统的文件夹 。Topic可以被分为若干个分区 ， 一个分区就是一个commit log ， 消息以追加的方式写入分区，然后以先入先出的顺序读取 。

  • 因为一个topic分为多个分区，因此无法在整个topic范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。

  • 分区可以分布在不同的服务器上，一个Topic可以横跨多个服务器。

生产者和消费者

生产者

  • 创建消息。生产者默认情况下以轮询的方式将消息写入所有分区上 ，而不关心特定消息被写到哪个分区。

  • 也可以通过消息键(key)和分区器来实现，分区器为键生成一个散列值，并将其映射到指定的分区上 。保证包含同一个键的消息会被写到同一个分区上。支持自定义的分区器，根据不同的业务规则将消息映射到分区 。

消费者

  • 消费者是消费者组的一部分， 会有一个或者多个消费者共同订阅一个Topic。消费者组保证每个分区只能被一个消费者使用 。

  • 例如，有一个消费者组中有3个消费者同时订阅一个Topic， 其中的两个消费者各自读取一个分区，另一个消费者读取其他两个分区。消费者与分区之间的映射通常称为消费者对分区的所有权关系 。

  • 通过这种方式，消费者可以消费包含大量消息的topic ，如果一个消费者失效，消费者组里的其他消费者可以接管失效消费者的工作 。

broker和集群

broker

  • 一个独立的Kafka服务器被称为broker 。 broker接受来自生产者的消息，为消息设置offset，并提交保存到磁盘。 broker为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息 。根据特定的硬件机器性能特征， 单个broker可以轻松处理千万个分区以及每秒百万级的消息量 。

集群

  • broker是集群的组成部分 ，每个集群都有一个broker同时充当集群控制器的角色(自动从集群的活跃成员中选举出来) 。 控制负责管理工作，将包括分区分配给broker和监控broker 。

  • 在集群中， 一个分区从属于一个broker，该broker被称为分区的首领 。 一个分区可以分配给多个broker，这个时候会发生分区复制。这种复制为分区提供了消息冗余，如果有一个broker失效，其他broker可以接管领导权 。不过， 相关的消费者和生产者都要重新连接到新的leader里 。

保留消息

  • 是Kafka的一个重要特征， kafka broker默认的消息策略是这样的，要么保留一段时间(比如7天)，要么保留到消息达到一定大小的字节数(比如1GB) 。

  • 当消息数量达到这些上限时，旧消息就会过期并被删除，所以在任何时刻，可用消息的总量都不会超过配置参数所指定的大小 。

  • topic 可以配置自己的保留策略，可以将消息保留到不再使用他们为止。 例如， 用于跟踪用户活动的数据可能需要保留几天，而应用程序的度量指标可能只需要保留几个小时。可以通过配置把主题作为紧凑型日志，只有最后一个带有特定键的消息会被保留下来,compact压缩策略 。

多集群

  • 随着Kafka部署数量的增加，基于以下几点，最好使用多个集群

    • 数据类型分离

    • 安全需求隔离

    • 多数据中心(容灾恢复)

  • 使用多个数据中心，就需要它们之间的复制消息，Kafka的消息机制只能在 单个集群里进行，不能在多个集群之间进行 。

  • Kafka提供了一个叫 MirrorMaker的工具，可以用它来实现集群间的消息复制。MirrorMark的核心组件包含了一个生产者和一个消费者，两者之间通过一个队列相连 。

Kafka的特点

多个生产者

  • Kafka无缝支持多个生产者，不管客户端在使用单个topic还是多个topic。

多个消费者

  • 支持多个消费者从一个单独的消息流上读取数据，而且消费者之间不会互相影响。

基于磁盘的数据存储

  • Kafka 支持消费者非实时地读取消息，主要依赖于数据保留特性 。消息被提交到磁盘，根据设置的保留规则进行保存 。每个topic可以设置单独的保留规则 ，以便满足不同消费者的需求，各个topic可以保留不同数量的消息。 消费者可能会因为处理速度慢或突发的流量高峰导致无法及时读取消息，而持久化数据可以保证消息不会丢失 。消费者可以在进行应用程序维护时离线一小段时间，而无需担心消息丢失或堵塞在生产端。消费者可以被关闭，但消息会继续保留在Kafka里。消费者可以从上次中断的地方继续处理消息。

伸缩性

  • 可以灵活的扩展broker，从单机broker再到小集群broker再到上百个broker的kafka集群 。对在线集群进行扩展丝毫不影响整体系统的可用性。

  • 一个包含多个broker的集群，即使个别broker失效，仍然可以持续地为客户提供服务。要提高集群的容错能力，需要配置较高的复制系数 。

高性能

  • kafka支持横向扩展生产者、消费者和broker，Kafka可以轻松处理巨大的消息流。在处理大量数据的同时，还可以保证亚秒级别的消息延迟。

上一页kafka权威指南下一页2.安装Kafka

最后更新于