初识kafka
Kafka 从何而来？我们为什么要开发 Kafka ? Kafka 到底是什么？
Kafka 最初是 Linkedln 的一个内部基础设施系统。我们发现，虽然有很多数据库和系统可以用来存储数据，但在我们的架构里，刚好缺一个可以帮助处理持续数据流的组件。在开发 Kafka 之前，我们实验了各种现成的解决方案，从消息系统到日志聚合系统，再到 ETL工具，它们都无陆搞足我们的需求。最后 ，我们决定从头开发一个系统。我们不想只是开发一个能够存储数据的系统，比如传统的关系型数据库、键值存储引擎、搜索引擎或缓存系统，我们希望能够把数据看成是持续变化和不断增长的流，井基于这样的想主主构建出一个数据系统 。 事实上，是一个数据架构。
kafka权威指南中写到
我们认为 Kafka 是一个流平台：在这个平台上可以发布和订阅数据流，并把它们保存起来、进行处理，这就是构建 Kafka 的初衷。以这种方式来看待数据确实与人们习惯的想陆有所不同，但它确实在构建应用和架构方面表现出了强大的抽象能力。 Kafka 经常会被拿来与现有的技术作比较：企业级消息系统、大数据系统（如 Hadoop）和数据集成或 ETL工具。这里的每一项比较都有一定的道理，但也有失偏颇。Kafka 有点像消息系统，允许发布和订阅消息流。从这点来看，它类似于 ActiveMQ 、RabbitMQ 或 IBM 的 MQSeries 等产品。尽管看上去有些相似，但 Kafka 与这些传统的消息系统仍然存在很多重要的不同点，这些差异使它完全不同于消息系统。首先，作为一个现代的分布式系统， Kafka 以集群的方式运行，可以自由伸缩，处理公司的所有应用程序。 Kafka 集群并不是一组独立运行的 broker，而是一个可以灵活伸缩的中心平台，可以处理整个公司所有的数据流。其次， Kafka 可以按照你的要求存储数据，保存多久都可以 。作为数据连接层， Kafka 提供了数据传递保证 可复制、持久化，保留多长时间完全可以由你来决定。最后，流式处理将数据处理的层次提升到了新高度 。 消息系统只会传递消息，而 Kafka 的流式处理能力让你只用很少的代码就能够动态地处理派生流和数据集。Kafka 的这些独到之处足以让你刮目相看，它不只是“另一个消息队列” 。
(在正式讨论Kafka之前，先来了解发布与订阅消息系统的概念，并认识这个系统的重要性。数据（消息）的发送者（发布者）不会直接把消息发送给接收者，这是发布与订阅消息系统的一个特点。发布者以某种方式对消息进行分类，接收者（订阅者）订阅它们，以便接收特定类型的消息。发布与订阅系统一般会有一个 broker，也就是发布消息的中心点。)
Kafka 就是一款基于发布与订阅的梢息系统。它一般被称为“分布式提交臼志”或者“分布式流平台”。文件系统或数据库提交日志用来提供所有事务的持久记录 ， 通过重放这些日志可以重建系统的状态。同样地， Kafka 的数据是按照一定顺序持久化保存的，可以按需读取 。 此外， Kafka 的数据分布在整个系统里，具备数据故障保护和性能伸缩能力。
消息和批次
Kafka 的数据单元被称为 消息 。如果你在使用 Kafka 之前已经有数据库使用经验，那么可以把消息看成是数据库里的一个“数据行”或一条“记录”。消息由字节数组组成，所以对于 Kafka 来说，消息里的数据没有特别的格式或含义。消息可以有一个可选的元数据 ，也就是键。键也是一个字节数组，与消息一样，对于 Kafka 来说也没有特殊的含义。 当消息以一种可控的方式写入不同的分区时，会用到键。最简单的例子就是为键生成一个一致性散列值，然后使用散列值对主题分区数进行取模，为消息选取分区。这样可以保证具有相同键的消息总是被写到相同的分区上。
为了提高效率，消息被分批次写入 Kafka 。 批次就是一组消息，这些消息属于同一个主题和分区。如果每一个消息都单独穿行于网络，会导致大量的网络开销，把消息分成批次传输可以减少网络开销。不过，这要在时间延迟和吞吐量之间作出权衡：批次越大，单位时间内处理的消息就越多，单个消息的传输时间就越长。批次数据会被压缩，这样可以提升数据的传输和存储能力，但要做更多的计算处理。
模式
对于 Kafka 来说，消息不过是晦涩难懂的字节数组，所以有人建议用一些额外的结构来定义消息内容，让它们更易于理解。根据应用程序的需求， 消息模式 （ schema）有许多可用的选项。像 JSON 和 XML 这些简单的系统，不仅易用，而且可读性好。不过，它们缺乏强类型处理能力，不同版本之间的兼容性也不是很好。 Kafka 的许多开发者喜欢使用Apache Avro ， 它最初是为 Hadoop 开发的一款序列化框架。 Avro 提供了一种紧凑的序列化格式，模式和消息体是分开的，当模式发生变化时，不需要重新生成代码 ； 它还支持强类型和模式进化，其版本既向前兼容， 也向后兼容。数据格式的一致性对于 Kafka 来说很重要，它消除了消息读写操作之间的辑合性。 如果读写操作紧密地桐合在一起，消息订阅者需要升级应用程序才能同时处理新旧两种数据格式。在消息订阅者升级了之后，消息发布者才能跟着升级，以便使用新的数据格式。新的应用程序如果需要使用数据，就要与消息发布者发生耦合，导致开发者需要做很多繁杂的工作。
所以，定义良好的模式，并把它们存放在公共仓库，可以方便我们理解 Kafka 的消息结构。
主题和分区
Kaflca 的消息通过主题进行分类。主题就好比数据库的表，或者文件系统里的文件夹。主题可以被分为若干个分区 ， 一个分区就是一个提交日志。消息以追加的方式写入分区，然后以先入先出的顺序读取（队列）。要注意，由于一个主题一般包含几个分区，因此无法在整个主题范围内保证消息的顺序，但可以保证消息在单个分区内的顺序。 Kafka 通过分区来实现数据冗余和伸缩性。分区可以分布在不同的服务器上，也就是说， 一个主题可以横跨多个服务器，以此来提供比单个服务器更强大的性能。
我们通常会使用流这个词来描述 Kafka 这类系统的数据。很多时候 ， 人们把一个主题的数据看成一个流，不管它有多少个分区。流是一组从生产者移动到消费者的数据。当我们讨论流式处理时，一般都是这样描述消息的。 kafka Streams 、 Apache Samza 和 Storm 这些框架以实时的方式处理消息，也就是所谓的流式处理。我们可以将流式处理与离线处理进行比较，比如 Hadoop 就是被设计用于在稍后某个时刻处理大量的数据。
生产者和消费者
Kafka 的客户端就是 Kafka 系统的用户，它们被分为两种基本类型 ： 生产者和消费者。除此之外，还有其他高级客户端 API－←用于数据集成的 Kafka Connect API 和用于流式处理的 Kafka Streams。这些高级客户端 API 使用生产者和消费者作为内部组件，提供了高级的功能。
生产者创建消息。在其他发布与订阅系统中，生产者可能被称为发布者或写入者。一般情况下，一个消息会被发布到一个特定的主题上。生产者在默认情况下把消息均衡地分布到主题的所有分区上，而并不关心特定消息会被写到哪个分区。不过，在某些情况下，生产者会把消息直接写到指定的分区。这通常是通过消息键和分区器来实现的，分区器为键生成一个散列值，并将其映射到指定的分区上。这样可以保证包含同一个键的消息会被写到同一个分区上。生产者也可以使用自定义的分区器，根据不同的业务规则将消息映射到分区。
消费者读取消息。在其他发布与订阅系统中，消费者可能被称为订阅者或读者。 消费者订阅一个或多个主题，并按照消息生成的顺序读取它们。消费者通过检查消息的偏移盘来区分已经读取过的消息。 偏移量是另一种元数据，它是一个不断递增的整数值，在创建消息时， Kafka 会把它添加到消息里。在给定的分区里，每个悄息的偏移量都是唯一的。消费者把每个分区最后读取的悄息偏移量保存在 Zookeeper 或 Kafka 上，如果悄费者关闭或重启，它的读取状态不会丢失。消费者是消费者群组的一部分，也就是说，会有一个或多个消费者共同读取一个主题 。 群组保证每个分区只能被一个消费者使用 。下图 所示的群组中，有 3 个消费者同时读取一个主题。其中的两个消费者各自读取一个分区，另外一个消费者读取其他两个分区。消费者与分区之间的映射通常被称为悄费者对分区的所有权关系 。通过这种方式，消费者可以消费包含大量消息的主题。而且，如果一个消费者失效，群组
里的其他消费者可以接管失效消费者的工作。
broker和集群
一个独立的 Kafka 服务器被称为 broker。 broker 接收来自 生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。 broker 为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。根据特定的硬件及其性能特征，单个 broker 可以轻松处理数千个分区以及每秒百万级的消息量。
broker 是集群的组成部分。每个集群都有一个 broker 同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。控制器负责管理工作，包括将分区分配给broker和监控broker。在集群中，一个分区从属于一个 broker, 该 broker 被称为分区的首领 。一个分区可以分配给多个 broker，这个时候会发生分区复制（见下图）。这种复制机制为分区提供了消息冗余，如果有一个 broker 失效，其他 broker 可以接管领导权。不过，相关的消费者和生产者都要重新连接到新的首领。
多集群
随着 Kafka 部署数量的增加，基于以下几点原因，最好使用多个集群。
1.数据类型分离
2.安全需求隔离
3.多数据中心（灾难恢复）
如果使用多个数据中心，就需要在它们之间复制消息。这样，在线应用程序才可以访问到多个站点的用户活动信息。例如，如果一个用户修改了他们的资料信息，不管从哪个数据中心都应该能看到这些改动。或者多个站点的监控数据可以被聚集到一个部署了分析程序和告警系统的中心位置。不过， Kafka 的消息复制机制只能在单个集群里进行，不能在多个集群之间进行。
Kafka 提供了一个叫作 MirrorMaker 的工具，可以用它来实现集群间的消息复制。MirrorMaker 的核心组件包含了一个生产者和一个消费者，两者之间通过一个队列相连。消费者从一个集群读取消息，生产者把消息发送到另一个集群上。图 1-8 展示了一个使
用 MirrorMaker 的例子，两个“本地”集群的消息被聚集到一个“聚合”集群上，然后将该集群复制到其他数据中心。不过，这种方式在创建复杂的数据管道方面显得有点力不从心。
多数据中心架构图如下
