1.2 Kafka登场
Kafka 就是为了解决上述问题而设计的一款基于发布与订阅模式的消息系统。它一般被称为“分布式提交日志”或“分布式流式平台”。文件系统或数据库提交日志旨在保存事务的持久化记录，通过重放这些日志可以重建系统状态。同样，Kafka 的数据是按照一定的顺序持久化保存的，并且可以按需读取。此外，Kafka 的数据分布在整个系统中，具备数据故障恢复能力和性能伸缩能力。
1.2.1 消息和批次
Kafka 的数据单元被称为消息。如果在使用Kafka 之前你已经有使用数据库的经验，那么可以把消息看成数据库中的一个“数据行”或一条“记录”。消息由字节数组组成，对Kafka 来说，消息里的数据没有特殊的格式或含义。消息可以有一个可选的元数据，也就是键。键也是一个字节数组，与消息一样，对Kafka 来说没有特殊含义。当需要以一种可控的方式将消息写入不同的分区时，需要用到键。最简单的例子就是为键生成一个一致性哈希值，然后用哈希值对主题分区数进行取模，为消息选取分区。这样可以保证具有相同键的消息总是会被写到相同的分区中（前提是分区数量没有发生变化）。
为了提高效率，消息会被分成批次写入Kafka。批次包含了一组属于同一个主题和分区的消息。如果每一条消息都单独穿行于网络中，那么就会导致大量的网络开销，把消息分成批次传输可以减少网络开销。不过，这需要在时间延迟和吞吐量之间做出权衡：批次越大，单位时间内处理的消息就越多，对单条消息来说，其传输时间就越长。消息批次会被压缩，这样可以提升数据的传输和存储性能，但需要做更多的计算处理。第 3章将详细介绍消息的键和批次。
1.2.2 模式
对Kafka 来说，消息不过是晦涩难懂的字节数组，所以有人建议用一些额外的结构来定义消息内容，让它们更易于理解。不同的应用程序有不同的需求，因此消息模式（schema）也有很多可选项。一些简单的模式，比如 JavaScript Object Notation（JSON）和 Extensible Markup Language（XML），不仅易用，还具备良好的可读性。不过，它们缺乏强类型处理能力，不同版本之间的兼容性也不是很好。很多Kafka 开发者喜欢使用 Apache Avro，其最初是为 Hadoop 开发的一款序列化框架。Avro 提供了一种紧凑的序列化格式，模式和消息体是分开的，当模式发生变化时，无须重新生成代码。Avro 还支持强类型和模式演化，既向前兼容，也向后兼容。
数据格式的一致性对Kafka 来说非常重要，它消除了消息读写操作之间的耦合性。如果读写操作紧密耦合在一起，那么消息订阅者就需要升级应用程序才能同时处理新旧两种数据格式，而消息发布者需要在消息订阅者升级之后跟着升级，然后使用新的数据格式发布消息。将定义好的模式保存在公共库中，更方便我们了解Kafka 的消息结构。第 3章将详细讨论模式和序列化。
1.2.3 主题和分区
Kafka 的消息通过主题进行分类。主题就好比数据库的表或文件系统的文件夹。主题可以被分为若干个分区，一个分区就是一个提交日志。消息会以追加的方式被写入分区，然后按照先入先出的顺序读取。需要注意的是，由于一个主题一般包含几个分区，因此无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内是有序的。图 1-5 所示的主题有 4 个分区，消息被追加写入每个分区的尾部。Kafka 通过分区来实现数据的冗余和伸缩。分区可以分布在不同的服务器上，也就是说，一个主题可以横跨多台服务器，以此来提供比单台服务器更强大的性能。此外，分区可以被复制，相同分区的多个副本可以保存在多台服务器上，以防其中一台服务器发生故障。
图 1-5：包含多个分区的主题
我们通常会使用流这个词来描述Kafka 这类系统中的数据。很多时候，人们会把一个主题的数据看成一个流，不管它有多少个分区。流是一组从生产者移动到消费者的数据。当我们讨论流式处理时，一般都是这样描述消息的。Kafka Streams、Apache Samza 和 Storm 这些框架以实时的方式处理消息，这就是所谓的流式处理。流式处理有别于离线处理框架（如 Hadoop）处理数据的方式，后者被用于在未来某个时刻处理大量的数据。第 14章将介绍流式处理。
1.2.4 生产者和消费者
Kafka 的客户端就是Kafka 系统的用户，其被分为两种基本类型：生产者和消费者。除此之外，还有其他高级客户端 API——用于数据集成的Kafka Connect API 和用于流式处理的Kafka Streams。这些高级客户端 API 使用生产者和消费者作为内部组件，提供了更高级的功能。
生产者创建消息。在其他发布与订阅系统中，生产者可能被称为发布者或写入者。一条消息会被发布到一个特定的主题上。在默认情况下，生产者会把消息均衡地分布到主题的所有分区中。不过，在某些情况下，生产者会把消息直接写入指定的分区，这通常是通过消息键和分区器来实现的。分区器会为键生成一个哈希值，并将其映射到指定的分区，这样可以保证包含同一个键的消息被写入同一个分区。生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到不同的分区。第 3章将详细介绍生产者。
消费者读取消息。在其他发布与订阅系统中，消费者可能被称为订阅者或读取者。消费者会订阅一个或多个主题，并按照消息写入分区的顺序读取它们。消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量（不断递增的整数值）是另一种元数据，在创建消息时，Kafka 会把它添加到消息里。在给定的分区中，每一条消息的偏移量都是唯一的，越往后消息的偏移量越大（但不一定是严格单调递增）。消费者会把每一个分区可能的下一个偏移量保存起来（通常保存在Kafka 中），如果消费者关闭或重启，则其读取状态不会丢失。
消费者可以是消费者群组的一部分，属于同一群组的一个或多个消费者共同读取一个主题。群组可以保证每个分区只被这个群组里的一个消费者读取。在图 1-6 所示的群组中，有 3 个消费者同时读取一个主题，其中的两个消费者各自读取 3 个分区中的 1 个分区，另外一个消费者读取其他 2 个分区。消费者与分区之间的映射通常被称为消费者对分区的所有权关系。
图 1-6：消费者群组从主题读取消息
通过这种方式，消费者可以读取包含大量消息的主题。而且，如果一个消费者失效，那么群组里的其他消费者可以接管失效消费者的工作。第 4章将详细介绍消费者和消费者群组。
1.2.5 broker 和集群
一台单独的Kafka 服务器被称为 broker。broker 会接收来自生产者的消息，为其设置偏移量，并提交到磁盘保存。broker 会为消费者提供服务，对读取分区的请求做出响应，并返回已经发布的消息。根据硬件配置及其性能特征的不同，单个 broker 可以轻松处理数千个分区和每秒百万级的消息量。
broker 组成了集群。每个集群都有一个同时充当了集群控制器角色的 broker（自动从活动的集群成员中选举出来）。控制器负责管理工作，包括为 broker 分配分区和监控 broker。在集群中，一个分区从属于一个 broker，这个 broker 被称为分区的首领。一个被分配给其他 broker 的分区副本（参见图 1-7）叫作这个分区的“跟随者”。分区复制提供了分区的消息冗余，如果一个 broker 发生故障，则其中的一个跟随者可以接管它的领导权。所有想要发布消息的生产者必须连接到首领，但消费者可以从首领或者跟随者那里读取消息。第 7章将详细介绍如何操作集群（包括复制分区）。
图 1-7：集群中的分区复制
保留消息（在一定期限内）是Kafka 的一个重要特性。broker 默认的消息保留策略是这样的：要么保留一段时间（如 7 天），要么保留消息总量达到一定的字节数（如 1 GB）。当消息数量达到这些上限时，旧消息就会过期并被删除。所以，在任意时刻，可用消息的总量都不会超过配置参数所指定的大小。主题可以配置自己的保留策略，将消息保留到不再使用它们为止。例如，用于跟踪用户活动的数据可能需要保留几天，而应用程序的指标可能只需要保留几小时。我们可以把主题配置成紧凑型日志，只有最后一条带有特定键的消息会被保留下来。这比较适用于变更日志类型的数据，因为人们只关心最近一次发生的更新事件。
1.2.6 多集群
随着 broker 数量的增加，最好使用多个集群，原因如下。
- 数据类型分离
- 安全需求隔离
- 多数据中心（灾难恢复）
如果有多个数据中心，则需要在它们之间复制消息，让在线应用程序能够访问到多个站点的用户活动信息。如果一个用户修改了他们的资料，那么不管从哪个数据中心都应该能看到这些更新。或者，可以将多个站点的监控数据聚合到一个部署了分析应用程序和告警系统的中心位置。不过，需要注意的是，Kafka 的消息复制机制只能在单个集群中而不能在多个集群之间进行。
Kafka 提供了一个叫作 MirrorMaker 的工具，我们可以用它将数据复制到其他集群中。MirrorMaker 的核心组件包括一个消费者和一个生产者，它们之间通过队列相连。消费者会从一个集群读取消息，生产者则会把消息发送到另一个集群中。图 1-8 是使用 MirrorMaker 的例子，两个“本地”集群的数据被集合到一个“聚合”集群中，然后聚合集群的数据再被复制到其他数据中心。不过，这个应用程序太过简单了，还不足以展示Kafka 在构建复杂数据管道方面的能力。第 9章将详细讨论这些复杂的应用场景。
图 1-8：多数据中心架构