从技术上讲，事件流（Event streaming）是指以连续不断的一系列事件（event） 的形式从事件源(event sources，如数据库、传感器、移动设备、云服务和软件应用程序)实时捕获数据的实践；持久地存储这些事件流，以便以后检索;实时和可追溯地操作、处理和响应事件流;并根据需要将事件流路由到不同的目标的技术。
因此，事件流确保了数据的连续流动和各种检索与处理，从而使正确的信息在正确的时间出现在正确的地方。
Kafka是一个分布式系统，由服务器和客户端组成，通过高性能的TCP网络协议进行通信。
Kafka是作为一个集群运行的一个或多个服务器，可以跨越多个数据中心或云区域。其中一些服务器形成存储层(storage layer)，称为代理(brokers)。
其他服务器运行Kafka Connect，以事件流的形式持续导入和导出数据，将Kafka与你现有的系统集成，如关系数据库以及其他Kafka集群。
它们允许您编写分布式应用程序和微服务，这些应用程序和微服务可以并行地、大规模地、以容错的方式读取、写入和处理事件流，即使在网络问题或机器故障的情况下也是如此。
Kafka自带了一些这样的客户端，由Kafka社区提供的很多语言的客户端:Java、Scala、Go、Python、C/ c++和许多其他编程语言，并且支持REST api，还有更高级的Kafka Streams库。
事件记录了在你的业务中“发生了某事”的事实。在文档中也称为记录或消息。当你读或写数据到Kafka时，你以事件的形式来完成。
从概念上讲，事件具有键、值、时间戳和可选元数据头。下面是一个事件的例子:
key: "Alice"
value: "Made a payment of $200 to Bob"
timestamp: "Jun. 25, 2020 at 2:06 p.m."
生产者是那些发布(写)事件到Kafka的客户端应用程序，消费者是那些订阅(读取和处理)事件的客户端。在Kafka中，生产者和消费者是完全解耦的，彼此是不可知的，这是实现Kafka众所周知的高可扩展性的一个关键设计元素。例如，生产者不需要等待消费者。Kafka提供了各种保证，比如只处理一次事件的能力。
事件被组织起来并持久地存储在主题中。非常简单，主题类似于文件系统中的文件夹，而事件是该文件夹中的文件。例如，主题名称可以是“payments”。Kafka中的主题总是多生产者和多消费者:一个主题可以有0个、1个或多个生产者向它写入事件，也可以有0个、1个或多个消费者订阅这些事件。
主题中的事件可以根据需要随时读取，与传统消息传递系统不同，事件在使用后不会被删除。相反，你可以通过每个主题的配置来定义Kafka应该保留你的事件多长时间，在这之后旧的事件将被丢弃。Kafka的性能实际上与数据大小无关，所以长时间存储数据是完全没问题的。
主题是分区的，这意味着一个主题分散在位于不同Kafka broker上的许多“buckets”上。
数据的分布式放置对于可伸缩性非常重要，因为它允许客户机应用程序同时从多个代理读取和写入数据。当一个新事件被发布到一个主题时，它实际上被追加（append）到该主题(topic)的一个分区(partitions)。带有相同事件键(event key)的事件(例如，客户ID或车辆ID)被写入到相同的分区，Kafka保证任何一个给定的topic分区的消费者将总是以完全相同的顺序读取该分区的事件。
图:这个示例主题有四个分区P1-P4。两个不同的生产者客户端通过网络将事件写入主题的分区，从而彼此独立地发布主题的新事件。具有相同键的事件(在图中由它们的颜色表示)被写入相同的分区。注意，如果合适，两个生产者都可以写入同一个分区。
topic下的每个partition里的每条消息都会被分配一个唯一的序列号，称为位移值（offset），该位置值是从0开始顺序递增的整数。位移值可以唯一定位到某partition下的一条消息。**<topic,partition,offset>**三元组就可以唯一定位一条消息了。
让你的数据具有容错性和高可用性,每一个主题（topic）可以被复制（replicated）,甚至跨geo-regions或数据中心,这样总有多个brokers有一份数据以防出错,你想做代理维护,等等。一个常见的生产设置是复制因子（replication factor ）3，也就是说，您的数据总是有三个副本。
此副本（replica）在主题分区（partition）级别执行。
副本分为俩类：领导者副本（leader replica）和追随者副本(follower replica)。追随者副本是不能提供服务给客户端的，也就是说不负责响应客户端发来的消息写入和消息消费请求。它只能被动的向领导者副本获取数据，而一旦leader replica 所在的broker宕机，Kafka会从剩余的replica中选举出新的 leader 继续提供服务。
Kafka 的 replica 分为两个角色：领导者（ leader）和追随者（ follower ）。在这类 leader-follower 系统中通常只有 leader 对外提供服务， follower 只是被动地追随 leader 的状态，保持与 leader 的同步。follower 存在的唯一价值就是充当 leader的候补：一旦 leader 挂掉立即就会有一个追随者被选举成为新的 leader 接替它的工作。
ISR 的全称是in-sync replica，翻译过来就是与leader replica保持同步的 replica 集合 。
Kafka 为 partition 动态维护一个 replica 集合。该集合 中的所有 replica 保存的消息日志都与leader replica 保持同步状态。只有这个集合中的 replica 才能被选举为 leader，也只有该集合中所有 replica 都接收到了同一条消息，Kafka 才会将该消息置于“己提交”状态，即认为这条消息发送成功。
正常情况下， partition的所有 replica （含 leader replica ）都应该与 leader replica 保持同步，即所有 replica 都在 ISR 中。因为各种各样的原因，一小部分 replica 开始落后于 leader replica 的进度 。当滞后到一定程度时，Kafka 会将这些 replica “踢”出 ISR 。相反地，当这些 replica 重新“追上”了 leader 的进度时 ， 那么 Kafka 会将它们加回到ISR 中。
除了用于管理和管理任务的命令行工具，Kafka有五个针对Java和Scala的核心api: