1.1 Kafka之前发布与订阅消息系统存在的问题

1、多个发布者之间直连

2、多个独立的队列系统

需要的是一个单一的集中式系统，可以用来发布通用类型的数据，规模也可以随着公司业务增长而增长。

1.2 Kafka登场

Kafka是为了解决上述问题而出现的一款基于发布与订阅的消息系统。

1.2.1 消息与批次

消息是Kafka的数据单元，相当于数据库的一个数据行或者是一条记录。由字节数组组成。

为提高效率，消息会被分批次写入Kafka。批次是一组消息。批次可以减少网络开销，但是会存在时间延迟，所以需要在时间延迟和吞吐量之间做出权衡。批次数据会被压缩。

1.2.2 模式

消息模式：

        JSON、XML，简单易用、可读性好。

        Avro 提供一种紧凑的序列号格式，模式与消息体是分开的，模式发生变化时不需要重新生成代码；还支持强类型和模式进化。

1.2.3 主题与分区

主题：相当于数据库的表

一个主题可以有一到多个分区

消息以追加方式写入分区，数据结构类似于Java的队列，先入先出顺序读取。由于一个主题一般有若干个分区，所以无法在整个主题范围内包装消息的顺序，但是可以保证在单个分区内的顺序。

1.2.4 生产者和消费者

生产者：默认情况下消息会被均衡的分布到主题所有分区上，并不关系特定消息会被写到哪个分区。某些情况下会把消息写到指定分区。通常是通过消息键和分区器来实现的。

消费者：订阅一个或多个主题，按照消息生成的顺序读取它们。消费者通过检查消息的偏移量来区分已经读取过的消息。偏移量是另一种元数据，是一个不断递增的整数值，在创建消息时，Kafka会把它添加到消息里。

消费者是消费者群组的一部分，会有一个或 多个消费者共同读取同一个主题。

1.2.5 broker和集群

一个独立的Kafka服务器叫做broker。broker接收来自生产者的消息，为消息设置偏移量，并提及消息保存到磁盘。单个broker可以轻松处理数千个分区以及每秒百万级的消息量。

集群包含多个broker。有一个broker充当集群控制器的角色。在集群中，如果一个分区属于一个broker，那么该broker称为该分区的首领；如果一个分区分配给多个broker，会发生分区复制提供分区冗余，这样当一个broker失效其他broker可以接管。

1.2.6 多集群

基于以下原因，最好使用多集群

        1、数据类型分离

        2、安全需求隔离

        3、多数据中心（灾备）

需注意：Kafka的消息复制只能在单集群里进行，不能在多集群之间进行。

Kafka提供了一个MirrorMaker的工具，可以用它来实现集群间复制。

1.3 为什么选择Kafka

1.3.1 多个生产者

可以无缝的支持多个生产者，不管客户端在使用单个主题还是多个主题。所以很适合从多个前端系统收集数据并以统一格式对外提供数据。

1.3.2 多个消费者

支持多个消费者从一个单独的消息流上读取数据，而且消费者之间互不影响。多个消费者可以组成一个消费群组，共享一个消息流，并保证整个群主对给定的消息只消费一次。

1.3.3 基于磁盘的数据存储

允许非实时消费，提供持久化到磁盘，根据设置的规则进行读取。

1.3.4 伸缩性

可灵活伸缩扩容。

1.3.5 高性能

通过横向扩展生产者、消费者、broker，Kafka可轻松处理巨大的消息流。处理大量数据的同时能保证亚秒级的消息延迟。

1.4 数据生态系统

Kafka为数据生态系统带来了循环系统，在基础设施各个组件之间传递消息，为所有客户端提供统一的接口。当提供消息模式的系统集成时，生产者与消费者之间不再有紧密的耦合，也不需再建立任何类型直连。

使用场景

1、活动跟踪。Kafka最初使用场景，收集前端用户交互的数据

2、传递消息。

3、度量指标和日志记录

4、提交日志

5、流处理。与Hadoop的map和reduce类似，不过是操作实时数据流

1.5 起源故事

Kafka是为了解决LinkedIn数据管道问题而生的。

1.5.4 命名

Jay Kreps大学上过很多文学课程，很喜欢Franz Kafka