初识Kafka
来由
数据为企业的发展提供动力。我们从数据中获取信息，对它们进行分析处理，然后生成更多的数据。每个应用程序都会产生数据， 包括日志消息、度量指标、用户活动记录、晌应消息等。数据的点点滴滴都在暗示一些重要的事情，比如下一步行动的方向。我们把数据从摞头移动到可以对它们进行分析处理的地方，然后把得到的结果应用到实际场景中，这样才能够确切地知道这些数据要告诉我们什么。例如，我 每天在 azon 网站上浏览感兴趣的商品，浏览信息被转化成商品推荐，并在稍后展示给我们。这个过程完成得越快，组织的反应就越敏捷。花费越少的精力在数据移动上，就越能专注于核心业务。这就是为什么在 个以数据为驱动的企业里，数据管道会成为关键性组件。如何移动数据，几乎变得与数据本身一样重要。
这个过程完成得越快，组织的反应就越敏捷。花费越少的精力在数据移动上，就越能专注于核心业务。这就是为什么在 个以数据为驱动的企业里，数据管道会成为关键性组件。
如何移动数据，几乎变得与数据本身一样重要。
1.1 发布与订阅消息系统
数据（消息）的发送者（发布者）不会直接把消息发送给接收者，这是发布与订阅消息系统的一个特点。发布者以某种方式对消息进行分类，接收者（订阅者）订阅它们，以便接收特定类型的消息。发布与订阅系统一般会有一个 roker ，也就是发布消息的中心点。
1.1.1 如何开始
发布与订阅消息系统的大部分应用场景都是从一个简单的消息队列或 个进程间通道开始的。例如，你的应用程序需要往别处发送监控信息，可以直接在你的应用程序和另 个可以在仪表盘上显示度量指标的应用程序之间建立连接 然后通过这个连接推送度量指标，如图 1-1 所示。
这是刚接触监控系统时简单问题的应对方案。过了不久，你需要分析更民时间片段的度量指标，而此时的仪表盘程序满足不了需求。
于是，你启动了 个新的服务来接收度盘指标。 主服务把度量指标保存起来，然后进行分析。与此同时，｛尔修改了原来的应用程序，把度量指标同时发送到两个仪表盘系统上 现在，你又多了 个可以生成度量指标 应用程序，它们都与这两个服务直接相连。而你的同事认为最好可以对这些服务进行轮询以便获得告警功能，于是你为每一个应用程序增加了一个服务器，用于提供度量指标。
再过阵子，有更多的应用程序出于各自的目的，都从这些服务器获取度主指标。这时的架构看起来就像图 1-2 所示的那样节点间的连接一团糟。
多个直连的度量指标发布者
这时，技术债务开始凸显出来，于是你决定偿还掉 些。你创建了 个独立的应用程序，用于接收来自其他应用程序的度量指标，井为其他系统提供了 个查询服务器。
这样，之前架构的复杂度被降低到图 -3 所示的那样。那么恭喜你，你已经创建了 个基于发布与订阅的消息系统。
1.1.2 独立的队列系统
在你跟度量指标打得不可开交的时候，你的 个同事也正在跟日志消息奋战。还有另同事正在跟踪网站用户的行为，为负责机器学习开发的同事提供信息 ，同时为管理团队生成报告。你和同事们使用相同的方式创建这些系统，解辑信息的发布者和订阅者。图 1-4所示的架构包含了 个独立的发布与订阅系统。
这种方式比直接使用点对点的连接（图 1-2 要好得多，但这里有太多重复的地方。你的公司因此要为数据队列维护多个系统，每个系统又有各自的缺陷和不足。而且，接下来可能会有更多的场景需要用到消息系统。 此时，你真正需要的是 个单 的集中式系统，它可以用来发布通用类型的数据，其规模可以随着公司业务的增长而增长。
1.2 Kafka登场
Kafka 就是为了解决上述问题而设计的一款基于发布与订阅的梢息系统。
它 般被称为“分布式提交臼志”或者“分布式流平台”。文件系统或数据库提交日志用来提供所有事务的持久记录 通过重放这些日志可以重建系统的状态。同样地， Kafka 的数据是按照一定顺序持久化保存的，可以按需读取 此外， fk 的数据分布在整个系统里，具备数据故障保护和性能伸缩能力。
1.2.1 消息和批次
Kafka 的数据单元被称为消息。
如果你在使用 afka 之前已经有数据库使用经验，那么以把消息看成是数据库里的 个“数据行”或一条“记录”。消息由字节数组组成，所以对于 Kafka 来说，消息里的数据没有特别的格式或含义。消息可以有 个可选的元数据也就是键。键 个字节数组，与消息 样，对于 Kafka 来说也没有特殊的含义。息以 种可控的方式写入不同的分区时，会用到键。最简单的例子就是为键生成性散列值，然后使用散列值对主题分区数进行取模，为消息选取分区。这样可以保证具有相同键的消息总是被写到相同的分区上。
为了提高效率，消息被分批次写入 Kafka 批次就是一组消息，这些消息属于同一 主题和分区。如果每 个消息都单独穿行于络，会导致大 的网络开销，把消息分成批次传输可以减少网络开销。不过，这要在时间延迟和吞吐量之间作出权衡：批次越大，单位时间内处理的消息就越多，单个消息的传输时间就越长。批次数据会被压缩，这样可以提数据的传输和存储能力，但要做更多的计算处理。
1.2.2 模式
对于 afka 来说，消息不过是晦涩难懂的字节数组，所以有人建议用 些额外的结构来定义消息内容，让它们更易于理解Avro 提供了 种紧凑的序列化格式，模式和消息体是分开的，当模式发生变 时，不需要重新生成代码 它还支持强类型和模式化，其版本既向前兼容， 向后兼容。
数据格式的一致性对于Kafka来说很重要。
它消除了消息读 操作之间的耦合性。
1.2.3 主题和分区
Kaflca 的消息通过主题进行分类。。主题就好比数据库的表，或者文件系统里的文件夹。主题可以被分为若干个分区 个分区就是一个提交日志。消息以追加的方式写入分区，然后以先入先出的顺序读取。
无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。
消息被追加写入每个分区的尾部。 Kafka通过分区来实现数据冗余和伸缩性。分区可以分布在不同的服务器上，也就是说，一个主题可以横跨多个服务器，以此来提供比单个服务器更强大的性能。
使用流这个词来描述 Kafka这类系统的数据。把 个主题的数据看成一个流，不管它有多少个分区。
流是一组从生产者移动到消费者的数据。当我们讨论流式处理时，一般都是这样描述消息的。 aflca Strea ac amza Storm 这些框架以实时的方式处理消息，也就是所谓的流式处理。
1.2.4 生产者和消费者
Kafka的客户端就是 Kaflea 系统的用户.生产者和消费者。
- 生产 创建消息。
- 消费者读取消息。
- 生产者
- 在其他发布与订阅系统中，生产者可能被称为发布者 写入者。一般情况下，一个消息会被发布到一个特定的主题上。生产者在默认情况下把消息均衡地分布到主题的所有分区上，而并不关心特定消息会被写到哪个分区。不过，在某些情况下，生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的，分区器为键生成一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区。
- 消费者
- 消费者可能被称为订阅者或读者 消费者订个或多个主题，并按照消息生成的顺序读取它们。消费者通过检查消息的偏移盘来区分已经读取过的消息。 偏移量是另 种元数据，它是 个不断递增的整数值，在创建消息时， Kafka 会把它添加到消息里。在给定的分区里，每个悄息的偏移量都是唯 的。消费者把每个分区最后读取的悄息偏移量保存在 Zookeeper Kafka 上，如果悄费者关闭或重启，它的读取状态不会丢失。
- 消费者是消费者群组的 部分，也就是说，会有 个或多个消费者共同读取 个主题组保证每个分区只能被 个消费者使用 。图 1-6 所示的群组中，有 消费者同时读取个主题。其中的两个消费者各自读取 个分区，另外 个消费者读取其他两个分区。消费者与分区之间的映射通常被称为悄费者对分区的所有权关系
- 通过这种方式，消费者可以消费包含大量消息的主题。而且，如果 个消费者失效，群组里的其他消费者可以接管失效悄费者的工作。
