数据为企业的发展提供动力。我们从数据中获取信息，对它们进行分析处理，然后生成更多的数据。每个应用程序都会产生数据，包括日志消息、度量指标、用户活动记录、响应消息等。数据的点点滴滴都在暗示一些重要的事情，比如下一步行动的方向。我们把数据从源头移动到可以对它们进行分析处理的地方，然后把得到的结果应用到实际场景中，这样才能够确切地知道这些数据要告诉我们什么。比如我们在淘宝网站上浏览感兴趣的商品，浏览信息被转化为商品推荐并展示给我们。
发布与订阅消息系统
数据的发送者不会直接把消息发送给接收者，这是发布与订阅消息系统的一个特点。发布者以某种方式对消息进行分类，接收者订阅它们，以便收到特定类型的消息。发布者与订阅者之间一般会有一个 broker，也就是发布消息的中心点。
如何开始？
发布与订阅消息系统的大部分应用场景都是从一个简单的消息队列或一个进程间通道开始的。例如，你的程序需要往特别的地方发送监控信息，你可以直接在应用程序或另一个可以在仪表盘上显示度量指标的应用程序之间建立联系，然后通过这个连接，推送度量指标。
Kafka登场
Kafka就是为了解决上述问题而设计的一款基于发布与订阅的消息系统，它一般被称为分布式提交日志或者分布式流处理平台。文件系统或数据库提交日志用来提供所有事务的持久记录，通过重放这些日志可以重建系统状态。同样的，Kafka的数据是按一定顺序持久化保存的，可以按需读取。此外，Kafka的数据分布在整个系统里，具有数据故障保护和性能伸缩能力。
消息和批次
Kafka的数据单元被称为消息
为了提高效率，消息被分批次写入 Kafka，批次就是一组消息，这些消息属于同一个主题和分区。如果每个消息都单独传输，会导致大量网络开销。把消息分批次传输可以减少网络开销，不过这要在时间延迟和吞吐量之间做出权衡。批次越大，单位时间内处理的消息就越多，单个消息的传输时间就越长。批次里数据会被压缩，这样可以提升数据传输和存储能力，但需要做更多的计算。
主题和分区
Kafka的消息通过主题进行分类，主题就好比数据库表或者文件系统里面的文件夹。主题可以被分为若干个分区，一个分区就是一个日志提交。消息以追加的形式写入分区中，然后以先入先出的顺序读取。
生产者和消费者
Kafka客户端就是Kafka系统用户，它被分为两种类型，生产者和消费者。此外还有一些高级客户端API用于数据集成，包括 Kafka Connect API 和用于流处理的Kafka Stream，这些高级客户端API使用生产者和消费者作为内部组件，提高了高级功能。
生产者：创建消息，在其他发布与订阅系统中，生产者可以被称为发布者或写入者。一般情况下，一个消息会被发布到一个特定的主题上，生产者在默认情况下把消息均匀地分布在所有主题上，而不会特地关心写到哪个分区。不过在某些特定情况下，生产者会把消息直接写到特定的分区。这通常与消息键和分区器来实现，分区序为键生成的一个散列值，并将其映射到指定的分区上，这样可以保证同一个键的消息会被写到同一个分区上。生产者也可以自定义分区器，根据不同的业务规则将消息映射到分区。
消费者：读取消息，在其他发布与订阅系统中，消费者可以被称为订阅者或者读者。消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。消费者通过检查消息的偏移量来区分已经读过的消息。
偏移量：是另一种元数据，它是一个不断递增的数据值，在创建消息时，Kafka会把它添加到消息里，再给指定的分区里，每个消息的偏移量都是唯一的。消费者把每个分区最后读取的偏移量保存在Zookeeper 或Kafka上。如果消费者关闭或重启，它的读取状态不会丢失
Broker 和 集群
一个单独的 Kafka 服务器被称为 Broker，Broker 接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。Broker 为消费者提供服务，对读取分区和请求做出响应，返回已经提交到磁盘上的消息。根据特定的硬件及其性能特征，单个 broker 可以轻松地处理几千个分区以及几百万的消息量。
broker 是集群的组成部分。每个集群都有一个 broker 同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。控制器负责管理工作，包括将分区分配给 broker 和监控 broker。在集群中，一个分区从属于一个 broker，该 broker 被称为分区的首领。一个分区可以分配给多个 broker，这个时候会发生分区复制（见图 1-7）。这种复制机制为分区提供了消息冗余，如果有一个 broker 失效，其他 broker 可以接管领导权。不过，相关的消费者和生产者都要重新连接到新的首领。
为什么选择Kafka
多个生产者
Kafka 可以无缝地支持多个生产者，不管客户端在使用单个主题还是多个主题。所以它很适合用来从多个前端系统收集数据，并以统一的格式对外提供数据。例如，一个包含了多个微服务的网站，可以为页面视图创建一个单独的主题，所有服务都以相同的消息格式向该主题写入数据。消费者应用程序会获得统一的页面视图，而无需协调来自不同生产者的数据流。
多个消费者
除了支持多个生产者外，Kafka 也支持多个消费者从一个单独的消息流上读取数据，而且消费者之间互不影响。这与其他队列系统不同，其他队列系统的消息一旦被一个客户端读取，其他客户端就无法再读取它。另外，多个消费者可以组成一个群组，它们共享一个消息流，并保证整个群组对每个给定的消息只处理一次。
基于磁盘的数据存储
Kafka 不仅支持多个消费者，还允许消费者非实时地读取消息，这要归功于 Kafka 的数据保留特性。消息被提交到磁盘，根据设置的保留规则进行保存。每个主题可以设置单独的保留规则，以便满足不同消费者的需求，各个主题可以保留不同数量的消息。消费者可能会因为处理速度慢或突发的流量高峰导致无法及时读取消息，而持久化数据可以保证数据不会丢失。消费者可以在进行应用程序维护时离线一小段时间，而无需担心消息丢失或堵塞在生产者端。消费者可以被关闭，但消息会继续保留在 Kafka 里。消费者可以从上次中断的地方继续处理消息。
伸缩性
为了能够轻松处理大量数据，Kafka 从一开始就被设计成一个具有灵活伸缩性的系统。用户在开发阶段可以先使用单个 broker，再扩展到包含 3 个 broker 的小型开发集群，然后随着数据量不断增长，部署到生产环境的集群可能包含上百个 broker。对在线集群进行扩展丝毫不影响整体系统的可用性。也就是说，一个包含多个 broker 的集群，即使个别 broker 失效，仍然可以持续地为客户提供服务。要提高集群的容错能力，需要配置较高的复制系数。
高性能
上面提到的所有特性，让 Kafka 成为了一个高性能的发布与订阅消息系统。通过横向扩展生产者、消费者和 broker，Kafka 可以轻松处理巨大的消息流。在处理大量数据的同时，它还能保证亚秒级的消息延迟。
