Kafka基本认识和场景

1 Kafka 基本概念

Kafka 是一款基于发布与订阅的消息系统。它一般被称为
“分布式提交日志”或者“分布式流平台”。

1.1 消息和批次

消息：
Kafka 的数据单元被称为 消息。可以把消息看成是数据库里的一个“数据行”或一条“记录”。消息由 字节数组 组成，所以对于 Kafka 来说，消息里的数据没有特别的格式或含义。

键：
消息可以有一个可选的元数据 ，也就是 键。键也是一个 字节数组 ，与消息一样，对于 Kafka 来说也没有特殊的含义。 当消息以一种可控的方式写入不同的分区时，会用到键。最简单的例子就是为键生成一个一致性散列值，然后使用散列值对主题分区数进行取模，为消息选取分区 。这样可以保证具有相同键的消息总是被写到相同的分区上。

批次：
为了提高效率，消息被分 批次 写入 Kafka 。 批次 就是一组消息，这些消息属于同一个主题和分区。如果每一个消息都单独穿行于网络，会导致大量的网络开销，把消息分成批次传输可以减少网络开销。不过，这要在时间延迟和吞吐量之间作出权衡：批次越大，单位时间内处理的消息就越多，单个消息的传输时间就越长。批次数据会被压缩，这样可以提升数据的传输和存储能力，但要做更多的计算处理。

1.2 模式

消息不过是晦涩难懂的字节数组，所以有人建议用一些额外的结构来定义消息内容，让它们更易于理解。根据应用程序的需求， 消息模式 （ schema ）有许多可用的选项。像 JSON 和 XML 这些，不仅易用，而且可读性好。

1.3 主题和分区

Kafka 的消息通过 主题 进行分类。主题就好比数据库的表，或者文件系统里的文件夹。
主题可以被分为若干个 分区 ， 一个分区就是一个提交日志 。
消息以追加的方式写入分区，然后以 先入先出的顺序读取（分区内） 。要注意，由于一个主题一般包含几个分区，因此无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。

分区可以分布在不同的服务器上，也就是说， 一个主题可以横跨多个服务器，以此来提供比单个服务器更强大的性能。

1.4 生产者和消费者

生产者 创建消息。一般情况下，一个消息会被发布到一个特定的主题上。
默认情况下： 生产者把消息均衡地分布到主题的所有分区上，而并不关心特定消息会被写到哪个分区。
不过，在某些情况下，生产者会把消息直接写到指定的分区。这通常是通过 消息键 和 分区器 来实现的， 分区器 为键生成一个 散列值 ，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区。

消费者 读取消息。消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。消费者通过检查消息的偏移量 来区分已经读取过的消息。
偏移量 是另一种元数据，它是一个不断递增的整数值，在创建消息时， Kafka 会把它添加到消息里。在给定的分区里， 每个消息的偏移量都是唯一的 。消费者把每个分区最后读取的消息偏移量保存在 Zookeeper 或 Kafka 上，如果消费者关闭或重启，它的读取状态不会丢失。

消费者是 消费者群组 的一部分，也就是说，会有一个或多个消费者共同读取一个主题。 群组保证 每个分区只能被一个消费者使用 。消费者与分区之间的映射通常被称为消费者对分区的 所有权关系 。如果一个消费者失效，群组里的其他消费者可以 接管 失效消费者的工作。

1.5 broker和集群

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

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

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

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

保留消息（在一定期限内）是 Kafka 的一个重要特性。
Kafka broker 默认的消息保留策略 是这样的：

• 要么保留 一段时间（比如 7 天） ；
• 要么保留到消息达到一定大小的 字节数（比如 1GB ） 。

当消息数量达到这些上限时，旧消息就会过期并被删除，所以在任何时刻， 可用消息的总量都不会超过配置参数所指定的大小。
主题可以配置自己的保留策略，可以将消息保留到不再使用它们为止。例如，用于跟踪用户活动的数据可能需要保留几天，而应用程序的度量指标可能只需要保留几个小时。
可以通过配置把主题当作 紧凑型日志 ， 只有最后一个带有特定键的消息会被保留下来。这种情况对于变更日志类型的数据来说比较适用，因为人们只关心最后时刻发生的那个变更。

1.6 多集群

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

• 数据类型分离
• 安全需求隔离
• 多数据中心（灾难恢复）
  如果使用多个数据中心，就需要在它们之间复制消息。这样，在线应用程序才可以访问到多个站点的用户活动信息。例如，如果一个用户修改了他们的资料信息，不管从哪个数据中心都应该能看到这些改动。或者多个站点的监控数据可以被聚集到一个部署了分析程序和告警系统的中心位置。
  不过， Kafka 的消息复制机制只能在单个集群里进行，不能在多个集群之间进行。

2 使用场景

2.1 活动跟踪

Kafka 最初的使用场景是跟踪用户的活动。网站用户与前端应用程序发生交互 ，前端应用程序生成用户活动相关的消息。这些消息可以是一些静态的信息，比如 页面访问次数和点击量 ，也可以是一些复杂的操作，比如添加用户资料。这些消息被发布到一个或多个主题上，由后端应用程序负责读取。这样，我们就可以生成报告，为机器学习系统提供数据，更新搜索结果，或者实现其他更多的功能。

2.2 传递消息

Kafka 的另一个基本用途是 传递消息 。微服务系统中各个微服务之间的异步通信，A服务将数据格式化成消息，发送到 Kafka，B服务订阅响应的主题，读取消息，执行业务。

2.3 度量指标和日志记录

Kafka 也可以用于收集应用程序和系统 度量指标以及日志 。 Kafka 支持多个生产者的特性在这个时候就可以派上用场。应用程序定期把度量指标发布到 Kafka 主题上，监控系统或告警系统读取这些消息。

2.4 提交日志

Kafka 的基本概念来源于提交日志，所以使用 Kafka 作为提交日志是件顺理成章的事。我们可以把数据库的更新发布到 Kafka 上，应用程序通过监控事件流来接收数据库的实时更新。这种变更日志流也可以用于把数据库的更新复制到远程系统上，或者合并多个应用程序的更新到一个单独的数据库视图上。数据持久化为变更日志提供了缓冲区，也就是说 ，如果消费者应用程序发生故障，可以通过重放这些日志来恢复系统状态。另外，紧凑型日志主题只为每个键保留一个变更数据，所以可以长时间使用，不需要担心消息过期问题。

2.5 流处理

流处理是又一个能提供多种类型应用程序的领域。可以说，它们提供的功能与 Hadoop 里的 map 和 reduce 有点类似，只不过它们操作的是实时数据流，而 Hadoop 则处理更长时间片段的数据，可能是几个小时或者几天， Hadoop 会对这些数据进行批处理。通过使用流式处理框架，用户可以编写小型应用程序来操作 Kafka 消息，比如计算度量指标，为其他应用程序有效地处理消息分区，或者对来自多个数据源的消息进行转换。