数据为企业的发展提供动力。我们从数据中获取信息，对它们进行分析处理，然后生成更多的数据。每个应用程序都会产生数据， 包括日志消息、度量指标、用户活动记录、晌应消息等。
发布与订阅消息系统
先来了解发布与订阅消息系统的概念，。数据（消息）的发送者（发布者）不会直接把消息发送给接收者，这是发布与订阅消息系统的一个特点。发布者以某种方式对消息进行分类，接收者（订阅者）订阅它们，以便接收特定类型的消息。
发布与订阅系统一般会有一个broker ，也就是发布消息的中心点。
如何开始
发布与订阅消息系统的大部分应用场景都是从一个简单的消息队列或一个进程间通道开始的。
例如，你的应用程序需要往别处发送监控信息，可以直接在你的应用程序和另一个可以在仪表盘上显示度量指标的应用程序之间建立连接， 然后通过这个连接推送度量指标，如图所示。
（即两个应用之间的消息传递）
这是刚接触监控系统时简单问题的应对方案。过了不久，你需要分析更民时间片段的度量指标，而此时的仪表盘程序满足不了需求，于是，你启动了一个新的服务来接收度盘指标。
该服务把度量指标保存起来，然后进行分析。与此同时，｛尔修改了原来的应用程序，把度量指标同时发送到两个仪表盘系统上。
现在，你又多了3 个可以生成度量指标的应用程序，它们都与这两个服务直接相连。而你的同事认为最好可以对这些服务进行轮询以便获得告警功能，于是你为每一个应用程序增加了一个服务器，用于提供度量指标。
再过一阵子，有更多的应用程序出于各自的目的，都从这些服务器获取度主指标。这时的架构看起来就像图所示的那样，节点间的连接一团糟。
这时，技术债务开始凸显出来，于是你决定偿还掉一些。你创建了一个独立的应用程序，用于接收来自其他应用程序的度量指标，井为其他系统提供了一个查询服务器。
这样，之前架构的复杂度被降低到图所示的那样。那么恭喜你，你已经创建了一个基于发布与订阅的消息系统。
独立的队列系统
在你跟度量指标打得不可开交的时候，你的一个同事也正在跟日志消息奋战。还有另一个同事正在跟踪网站用户的行为，为负责机器学习开发的同事提供信息，同时为管理团队生成报告。你和同事们使用相同的方式创建这些系统，解辑信息的发布者和订阅者。图所示的架构包含了3 个独立的发布与订阅系统。
这种方式比直接使用点对点的连接（图1-2 ） 要好得多，但这里有太多重复的地方。你的公司因此要为数据队列维护多个系统，每个系统又有各自的缺陷和不足。
此时，你真正需要的是一个单一的集中式系统，它可以用来发布通用类型的数据，其规模可以随着公司业务的增长而增长。
Kafka 登场
Kafka 就是为了解决上述问题而设计的一款基于发布与订阅的消息系统。它一般被称为“分布式提交日志”或者“分布式流平台”。
消息和批次
Kafka 的数据单元被称为消息，可以把消息看成是数据库里的一个“数据行”或一条“ 记录”。
为了提高效率，消息被分批次写入Kafka 。
批次就是一组消息，这些消息属于同一个主题和分区。如果每一个消息都单独穿行于网络，会导致大量的网络开销，把消息分成批次传输可以减少网络开销。
模式
对于Kafka 来说，消息不过是晦涩难懂的字节数组，所以有人建议用一些额外的结构来定义消息内容，让它们更易于理解。
Kafka 的许多开发者喜欢使用Apache Avro ， 它最初是为Hadoop 开发的一款序列化框架。Avro 提供了一种紧凑的序列化格式，模式和消息体是分开的，当模式发生变化时，不需要重新生成代码；它还支持强类型和模式进化，其版本既向前兼容， 也向后兼容。
数据格式的一致性对于Kafka来说很重要，它消除了消息读写操作之间的耦合性。定义良好的模式，并把它们存放在公共仓库，可以方便我们理解Kafka的消息结构。第3章将详细讨论模式和序列化。
主题和分区
Kaflca 的消息通过主题进行分类。主题就好比数据库的表，或者文件系统里的文件夹。主题可以被分为若干个分区， 一个分区就是一个提交日志。消息以追加的方式写入分区，然后以先入先出FIFO的顺序读取。
由于一个主题一般包含几个分区，因此无撞在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。
我们通常会使用流这个词来描述Kaflca 这类系统的数据。很多时候， 人们把一个主题的数据看成一个流，不管它有多少个分区。
生产者和消费者
Kafka 的客户端就是Kafka 系统的用户，它们被分为两种基本类型： 生产者和消费者。
生产者也称为发布者和写入者，它负责创建消息。生产者在默认情况下把消息均衡地分布到主题的所有分区上，而并不关心特定消息会被写到哪个分区。
不过，在某些情况下，生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的，分区器为键生成一个散列值，并将其映射到指定的分区上。
消费者也称为订阅者或者读者，它负责读取消息。消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。消费者通过检查消息的偏移量来区分已经读取过的消息。
偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时， Kafka 会把它添加到消息里。在给定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的消息偏移量保存在Zookeeper 或Kafka 上，如果消费者关闭或重启，它的读取状态不会丢失。
消费者是消费者群组的一部分，也就是说，会有一个或多个消费者共同读取一个主题。群组保证每个分区只能被一个消费者使用。如果一个消费者失效，群组里的其他消费者可以接管失效消费者的工作。
broker和集群
一个独立的Kafka 服务器被称为broker。
broker 接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。
broker 是集群的组成部分。每个集群都有一个broker 同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。控制器负责管理工作，包括将分区分配给broker 和监控broker。
在集群中，一个分区从属于一个broker，该broker 被称为分区的首领。一个分区可以分配给多个broker ，这个时候会发生分区复制。
这种复制机制为分区提供了消息冗余，如果有一个broker 失效，其他broker 可以接管领导权。不过，相关的消费者和生产者都要重新连接到新的首领。
Kafka broker保留消息的策略是这样的：
要么保留一段时间（比如7 天），要么保留到消息达到一定大小的字节数（比如lGB ）。当消息数量达到这些上限时，旧消息就会过期井被删除，所以在任何时刻， 可用消息的总量都不会超过配置参数所指定的大小。
主题可以配置自己的保留策略，可以将消息保留到不再使用它们为止。例如，用于跟踪用户活动的数据可能需要保留几天，而应
用程序的度量指标可能只需要保留几个小时。可以通过配置把主题当作紧凑型日志， 只有最后一个带有特定键的消息会被保留下来。这种情况对于变更日志类型的数据来说比较适用，因为人们只关心最后时刻发生的那个变更。
多集群
随着Kafka 部署数量的增加，基于以下几点原因，最好使用多个集群。
- 数据类型分离
- 安全需求隔离
- 多数据中心（灾难恢复）
如果使用多个数据中心，就需要在它们之间复制消息。不过， Kafka 的消息复制机制只能在单个集群里进行，不能在多个集群之间进行。Kafka 提供了一个叫作Mirror Maker 的工具，可以用它来实现集群间的消息复制。
Mirror Maker 的核心组件包含了一个生产者和一个消费者，两者之间通过一个队列相连。
图展示了一个使用MirrorMaker 的例子，两个“本地”集群的消息被聚集到一个“聚合”集群上，然后将该集群复制到其他数据中心。不过，这种方式在创建复杂的数据管道方面显得有点力不从心。具体细节，我们第7章再讨论。
为什么选择Kafka
基于发布与订阅的消息系统那么多，为什么Kafka 会是一个更好的选择呢？
- 多个生产者
- 多个消费者
- 基于磁盘的数据存储
- 伸缩性
- 高性能
- 数据生态系统
它在基础设施的各个组件之间传递消息，为所有客户端提供一致的接口。当与提供消息模式的系统集成时，生产者和消费者之间不再有紧密的祸合，也不需要在它们之间建立任何类型的直连。我们可以根据业务需要添加或移除组件．因为生产者不再关心谁在使用数据，也不关心有多少个消费者。