一、发布与订阅消息系统

Kafka 是数据驱动型应用程序的关键组件。

数据（消息）的发送者（发布者）不会直接把消息发送给接收者，这是发布与订阅消息系统的一个特点。

发布与订阅系统一般会有一个 broker，也就是发布消息的地方。

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

二、Kafka 基础概念介绍

1、消息与批次

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

对 Kafka 来说，消息里的数据没有特殊的格式或含义。消息可以有一个可选的元数据，也就是键。键也是一个字节数组，与消息一样，对 Kafka 来说没有特殊含义。当需要以一种可控的方式将消息写入不同的分区时，需要用到键。最简单的例子就是为键生成一个一致性哈希值，然后用哈希值对主题分区数进行取模，为消息选取分区。这样可以保证具有相同键的消息总是会被写到相同的分区中（前提是分区数量没有发生变化）。

为了提高效率，消息会被分成批次写入 Kafka。批次包含了一组属于同一个主题和分区的消息。把消息分成批次传输可以减少网络开销。但这需要在时间延迟和吞吐量之间做出权衡：批次越大，单位时间内处理的消息就越多，对单条消息来说，其传输时间就越长。消息批次会被压缩，这样可以提升数据的传输和存储性能，但需要做更多的计算处理。

2、模式

对 Kafka 来说，消息不过是晦涩难懂的字节数组，需要使用额外的结构来定义消息内容，让它们更易于理解。

一些简单的模式，比如 JSON 和 XML，易用且具备良好的可读性。不过，它们缺乏强类型处理能力，不同版本之间的兼容性也不是很好。

另外还有 Apache Avro，其最初是为 Hadoop 开发的一款序列化框架。Avro 提供了一种紧凑的序列化格式，模式和消息体是分开的，当模式发生变化时，无须重新生成代码。Avro 还支持强类型和模式演化，既向前兼容，也向后兼容。

数据格式的一致性对 Kafka 来说非常重要，它消除了消息读写操作之间的耦合性。

3、主题和分区

Kafka 的消息通过主题进行分类。主题就好比数据库的表或文件系统的文件夹。

主题可以被分为若干个分区，一个分区就是一个提交日志。消息会以追加的方式被写入分区，然后按照先入先出的顺序读取。需要注意的是，由于一个主题一般包含几个分区，因此无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内是有序的。

上图中的主题有 4 个分区，消息被追加写入每个分区的尾部。

Kafka 通过分区来实现数据的冗余和伸缩。分区可以分布在不同的服务器上，也就是说，一个主题可以横跨多台服务器，以此来提供比单台服务器更强大的性能。此外，分区可以被复制，相同分区的多个副本可以保存在多台服务器上，以防其中一台服务器发生故障。

通常使用流这个此来描述 Kafka 这种系统中的数据。可以把一个主题的数据看成一个流，不管它有多少个分区。

流是一组从生产者移动到消费者的数据。当我们讨论流式处理时，一般都是这样描述消息的。

Kafka Streams、Apache Samza 和 Storm 这些框架以实时的方式处理消息，这就是所谓的流式处理。流式处理有别于离线处理框架（如 Hadoop）处理数据的方式，后者被用于在未来某个时刻处理大量的数据。

4、生产者和消费者

Kafka 的客户端就是 Kafka 系统的用户，其被分为两种基本类型：生产者和消费者。除此之外，还有其他高级客户端：用于数据集成的 Kafka Connect API 和 用于流式处理的 Kafka Streams。这些高级客户端 API 使用生产者和消费者作为内部组件，提供更高级的功能。

生产者创建消息。在其他发布与订阅系统中，生产者可能被称为发布者或写入者。在默认情况下，生产者会把消息均衡地分布到主题的所有分区中生产者会把消息直接写入指定的分区，这通常是通过消息键和分区器来实现的这样可以保证包含同一个键的消息被写入同一个分区

消费者读取消息。在其他发布与订阅系统中，消费者可能被称为订阅者或读取者。消费者会订阅一个或多个主题，并按照消息写入分区的顺序读取它们。消费者通过检查消息的偏移量来区分已经读取过的消息。

偏移量（不断递增的整数值）是另一种元数据，在创建消息时，Kafka 会把它添加到消息里。在给定的分区中，每一条消息的偏移量都是唯一的，越往后消息的偏移量越大（但不一定是严格单调递增）。消费者会把每一个分区可能的下一个偏移量保存起来（通常保存在 Kafka 中），如果消费者关闭或重启，则其读取状态不会丢失。

消费者可以是消费者群组的一部分，属于同一群组的一个或多个消费者共同读取一个主题。群组可以保证每个分区只被这个群组里的一个消费者读取。

上图中的群组中，有3个消费者同事读取一个主题，其中两个消费者各自读取3个分区中的一个分区，另外一个消费者读取其他两个分区。

消费者与分区之间的关系，通常被称作消费者对分区的所有权关系。

5、broker 和集群

根据硬件配置及其性能特征的不同，单个 broker 可以轻松处理数千个分区和每秒百万级的消息量。

broker 组成了集群。每个集群都有一个同时充当了集群控制器角色的 broker（自动从活动的集群成员中选举出来）。控制器负责管理工作，包括为 broker 分配分区和监控 broker。

在集群中，一个分区从属于一个broker，这个 broker 被称为分区的首领。一个被分配给其他 broker 的分区副本叫作这个分区的“跟随者”。

分区复制提供了分区的消息冗余，如果一个 broker 发生故障，则其中的一个跟随者可以接管它的领导权。所有想要发布消息的生产者必须连接到首领，但消费者可以从首领或者跟随者那里读取消息。

Kafka 可以保留消息，其是 Kafka 的一个重要特征。可以设置保留策略：磁盘空间层面和时间层面。可以设置保留消息总量到一定的字节数，也可以设置消息保留一段时间。当消息数量达到限制之后，旧消息就会过期自动删除。主题可以设置自己的保留策略。

6、多集群

随着 broker 数量的增加，最好使用多集群，原因如下：

  • 数据类型分离
  • 安全需求隔离
  • 多数据中心（灾难恢复）

如果有多个数据中心，则需要在它们之间复制消息，让在线应用程序能够访问到多个站点的用户活动信息。如果一个用户修改了他们的资料，那么不管从哪个数据中心都应该能看到这些更新。或者，可以将多个站点的监控数据聚合到一个部署了分析应用程序和告警系统的中心位置。不过，Kafka 的消息复制机制只能在单个集群中而不能在多个集群之间进行。

Kafka 提供了一个叫作 MirrorMaker 的工具，我们可以用它将数据复制到其他集群中。MirrorMaker 的核心组件包括一个消费者和一个生产者，它们之间通过队列相连。消费者会从一个集群读取消息，生产者则会把消息发送到另一个集群中。

三、Kafka 的优点

基于发布订阅的消息系统有很多，为什么选择 Kafka？

1、多个生产者

Kafka 可以支持多个生产者，不管客户端消费的时单个主题还是多个主题。所以，它很适合用于从多个前端系统收集数据，并以统一的格式对外提供数据。

2、多个消费者

Kafka 支持多个消费者从一个单独的消息流读取数据，而且消费者之间互不影响。这与其他队列系统不同，在其他队列系统中，消息一旦被一个客户端读取，就无法再被其他客户端读取。多个消费者还可以组成一个群组，共享一个消息流，并保证整个群组只处理一次给定的消息。

3、基于磁盘的数据保留

Kafka 允许消费者非实时地读取消息。消息被提交到磁盘中，并根据设置的保留策略进行保存。每个主题可以设置不同的保留策略，以满足不同消费者的需求。

消费者可能会因为处理速度慢或突发的流量高峰而无法及时读取消息，这种情况下，持久化的数据可以保证数据不不会丢失。

消费者可以在应用程序维护期间离线一小段时间，无须担心消息丢失或被堵塞在生产端。

4、伸缩性

Kafka 在开始被设计的时候就是一个具备灵活伸缩性的系统。

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

5、高性能

Kafka 是一个高性能的发布与订阅消息系统。通过横向扩展生产者、消费者和 broker，Kafka 可以轻松处理巨大的消息流。在处理大量数据的同时，它还能保证亚苗级的消息延迟。

6、平台特性

Kafka 核心项目还有流式平台特性，从而使开发人员能够更容易执行一些常见任务。

我们可以用 Kafka Connect 从一个源数据抽取数据并将其推送到 Kafka，或者从 Kafka 抽取数据并将其推送到另一个接收数据的系统。Kafka Streams 提供了一个开发库，开发人员可以用它开发具备伸缩性和容错能力的
流式处理应用程序。

四、应用场景

1、活动跟踪

Kafka 最初的应用场景是跟踪网站用户的活动。网站用户与前端应用程序发生交互，前端应用程序再生成与用户活动相关的消息。这些消息可以是一些静态信息，比如页面访问量或点击量，也可以是一些复杂的操作，比如修改用户资料。这些消息可以发布到一个或多个主题上，并被后端应用程序读取。

2、传递消息

Kafka 的另一个基本用途是传递消息。应用程序向用户发送通知（如邮件）就是通过消息传递来实现的。这些应用程序组件可以生成消息，而无须关心消息的格式以及消息是如何被发送出去的。一个公共应用程序会负责读取并处理如下这些消息。

  • 格式化消息
  • 将多条消息放在同一个通知里发送
  • 根据用户配置的首选项来发送消息。

使用公共组件的好处：无须在多个应用程序中开发重复功能，并且可以在公共组件中做一些转换，比如将多条消息聚合成一个单独的通知。

3、指标和日志记录

Kafka 也可以用于收集应用程序以及系统的指标和日志。Kafka 的多生产者特性在这个时候就派上用场了。应用程序定期把指标发布到 Kafka 主题上，监控系统或告警系统会读取这些消息。Kafka 也可以被用在离线处理系统（如 Hadoop）中，进行较长时间片段的数据分析，比如年度增长走势预测。我们也可以把日志消息发布到 Kafka 主题上，然后再路由给专门的日志搜索系统（如 Elasticsearch）或安全分析应用程序。更改目标系统（如日志存储系统）不会影响前端应用程序或聚合方法，这是Kafka 的另一个优点。

4、提交日期

Kafka 的基本概念源自提交日志，所以将 Kafka 作为提交日志是件顺理成章的事。

我们可以把数据库的更新发布到 Kafka，然后应用程序会通过监控事件流来接收数据库的实时更新。这种变更日志流也可以用于把数据库的更新复制到远程系统，或者将多个应用程序的更新合并到一个单独的数据库。持久化的数据为变更日志提供了缓冲，也就是说，如果消费者应用程序发生故障，则可以通过重放这些日志来恢复系统状态。另外，可以用紧凑型主题更长时间地保留数据，因为我们只为一个键保留了一条最新的变更数据。

5、流式处理

流式处理是另一个包含多种类型应用程序的领域。

虽然可以认为大部分 Kafka 应用程序是基于流式处理，但真正的流式处理通常是指提供了类似 map/reduce（Hadoop）处理功能的应用程序。

Hadoop 通常依赖较长时间片段的数据聚合，可以是几小时或几天。流式处理采用实时的方式处理消息，速度几乎与生成消息一样快。

开发人员可以通过用流式处理框架开发小型应用程序来处理 Kafka 消息，执行一些常见的任务，比如指标计数、对消息进行分区或使用多个数据源的数据来转换消息，等等。

相关链接

OB tags

#Kafka