在大数据中，使用了大量的数据。关于数据，我们有两个主要挑战：第一个挑战是如何收集海量数据；第二个挑战是分析收集的海量数据。
什么是 Kafka？Apache Kafka 是一个分布式发布 - 订阅消息系统和一个强大的队列，可以处理大量的数据，并能够将消息从一个端点传递到另一个端点。Kafka 适合离线和在线消息消费。Kafka 消息保留在磁盘上，并在群集内复制以防止数据丢失。它与 Storm 和 Spark 非常好地集成，用于实时流式数据分析。
Kafka 具备的特性可靠性：Kafka 是分布式，分区，复制和容错的。可扩展性：Kafka 消息传递系统轻松缩放，无需停机。耐用性：Kafka 使用分布式提交日志，这意味着消息会尽可能快地保留在磁盘上，持久化。性能：Kafka 对于发布和订阅消息都具有高吞吐量。即使存储了许多 TB 的消息，它也保持稳定的性能。 Kafka 使用场景
指标：Kafka 通常用于操作监控数据。这涉及聚合来自分布式应用程序的统计信息，以产生操作数据的集中馈送。数据清洗：Kafka 可用于跨组织从多个服务收集数据，并使它们以标准格式提供给多个服务器。流处理：流行的框架(如 Storm 和 Spark Streaming)从主题中读取数据，对其进行处理，并将处理后的数据写入新主题，供用户和应用程序使用。 Kafka 的强耐久性在流处理的上下文中也非常有用。 Kafka 集群架构 代理（Broker）
Kafka 集群中有很多台 Server，其中每一台 Server 都可以存储消息，将每一台 Server 称为一个 Kafka 实例，也叫做 Broker。一个 Kafka 代理实例可以每秒处理数十万次读取和写入，每个 Broker 可以处理 TB 的消息，而没有性能影响。
ZooKeeperZooKeeper 用于管理和协调 Kafka 代理。 ZooKeeper 服务主要用于通知生产者和消费者 Kafka 系统中存在任何新代理或 Kafka 系统中代理失败。根据Zookeeper 接收到关于代理的存在或失败的通知，然后生产者和消费者采取决定并开始与某些其他代理协调他们的任务。
生产者（Producers）生产者将数据推送给代理。当新代理启动时，所有生产者搜索它并自动向该新代理发送消息。Kafka 生产者不等待来自代理的确认，并且发送消息的速度与代理可以处理的一样快。
消费者（Consumers）消费者从代理拉取数据。Kafka 代理是无状态的，这意味着消费者必须通过使用分区偏移来维护已经消耗了多少消息。如果消费者确认特定的消息偏移，则意味着消费者已经消费了所有先前的消息。消费者向代理发出异步拉取请求，以具有准备好消耗的字节缓冲区。消费者可以简单地通过提供偏移值来快退或跳到分区中的任何点。消费者偏移值由 ZooKeeper 通知。
主题（Topic）一个 topic 里保存的是同一类消息，相当于对消息的分类，每个 Producer 将消息发送到 Kafka 中，都需要指明要存的 topic 是哪个，也就是指明这个消息属于哪一类。
分区（Partition）每个 topic 都可以分成多个 Partition，每个 Partition 在存储层面是 append log 文件。任何发布到此 Partition 的消息都会被直接追加到 log 文件的尾部。
分区最根本的原因就是：Kafka 基于文件进行存储，当文件内容大到一定程度时，很容易达到单个磁盘的上限，因此，采用分区的办法，一个分区对应一个文件，这样就可以将数据分别存储到不同的 server 上去，另外这样做也可以负载均衡，容纳更多的消费者。
偏移量（Offset）一个分区对应一个磁盘上的文件，而消息在文件中的位置就称为 offset（偏移量），offset 为一个 long 型数字，它可以唯一标记一条消息。由于 Kafka 并没有提供其他额外的索引机制来存储 offset，文件只能顺序的读写，所以在 Kafka 中几乎不允许对消息进行“随机读写”。
Kafka 工作流程Kafka 以快速，可靠，持久，容错和零停机的方式提供基于 Pub-Sub 和队列的消息系统。在这两种情况下，生产者只需将消息发送到主题，消费者可以根据自己的需要选择任何一种类型的消息传递系统。
发布 - 订阅消息的工作流程生产者定期向主题发送消息；Kafka 代理存储为该特定主题配置的分区中的所有消息。它确保消息在分区之间平等共享。如果生产者发送两个消息并且有两个分区，Kafka 将在第一分区中存储一个消息，在第二分区中存储第二消息；消费者订阅特定主题；一旦消费者订阅主题，Kafka 将向消费者提供主题的当前偏移，并且还将偏移保存在 Zookeeper 系统中；消费者将定期请求 Kafka (如100 Ms)新消息；一旦 Kafka 收到来自生产者的消息，它将这些消息转发给消费者；消费者将收到消息并进行处理；一旦消息被处理，消费者将向 Kafka 代理发送确认；一旦 Kafka 收到确认，它将偏移更改为新值，并在 Zookeeper 中更新它。由于偏移在 Zookeeper 中维护，消费者可以正确地读取下一封邮件；以上流程将重复，直到消费者停止请求；消费者可以随时回退/跳到所需的主题偏移量，并阅读所有后续消息； 队列消息/用户组的工作流以下是 Pub-Sub 消息的逐步工作流程：
生产者以固定间隔向某个主题发送消息；Kafka 存储在为该特定主题配置的分区中的所有消息，类似于前面的方案；单个消费者订阅特定主题，假设 Topic-01 为 Group ID 为 Group-1；Kafka 以与发布 - 订阅消息相同的方式与消费者交互，直到新消费者以相同的组 ID 订阅相同主题 Topic-01 1；一旦新消费者到达，Kafka 将其操作切换到共享模式，并在两个消费者之间共享数据。此共享将继续，直到用户数达到为该特定主题配置的分区数；一旦消费者的数量超过分区的数量，新消费者将不会接收任何进一步的消息，直到现有消费者取消订阅任何一个消费者。出现这种情况是因为 Kafka 中的每个消费者将被分配至少一个分区，并且一旦所有分区被分配给现有消费者，新消费者将必须等待；此功能也称为使用者组。同样，Kafka 将以非常简单和高效的方式提供两个系统中最好的； ZooKeeper 的作用在队列消息传递系统而不是单个消费者中，具有相同组 ID 的一组消费者将订阅主题。简单来说，订阅具有相同 Group ID 的主题的消费者被认为是单个组，并且消息在它们之间共享。
Kafka 的一个关键依赖是 Zookeeper，它是一个分布式的协调组件。Zookeeper 是 Kafka 代理和消费者之间的协调接口。Kafka 服务器通过 Zookeeper 集群共享信息。Kafka 在 Zookeeper 中存储基本元数据，例如关于主题，代理，消费者偏移(队列读取器)等的信息。
考虑到 Zookeeper 本身的一些因素以及整个架构较大概率存在单点问题，新版本中逐渐弱化了 Zookeeper 的作用。但是 broker 依然依赖于 Zookeeper，Zookeeper 在 kafka 中还用来选举 Controller Broker 和检测 broker 是否存活等等。
Kafka 2.8.0 出炉了，此版本有一项重大改进：实现了 Raft 分布式一致性机制，意味着可以脱离 ZooKeeper 独立运行了。