一、消息（Record）

 消息是 Kafka 中最基本的数据单元。消息由一串字节构成，其中主要由 key 和 value 构成，key 和 value 也都是 byte 数组。消息的真正有效负载是 value 部分的数据。为了提高网络和存储的利用率，生产者会批量发送消息到 Kafka，并在发送之前对消息进行压缩。

• key
  key 的主要作用是作为路由依据，根据一定的策略，将此消息路由到指定的分区中。Kafka 提供的默认分区路由策略是：
  • 当 key 值为 null 时，使用轮询策略路由；
  • 当 key 值不为 null 时，使用 key 保序策略路由，即将相同 key 值的消息写入到同一分区中。
• value
  消息的真正有效负载是 value 部分的数据。
• timesamp
  消息的版本号，其值为时间戳，当生产者推送消息未指定的该值时，将使用生产者的当前系统时间自行填充。此属性将作为消息过期的判断依据之一。
• header
  可自定义一些附加标签信息。

二、生产者、服务端、消费者、消费者组

2.1 生产者（Producer）

 生产者是使用 Kafka 提供的客户端程序，承担主动为其推送消息的角色。

2.2 缓存代理（Broker）

 一个单独的 Kafka 服务器就是一个 Broker。Broker 的主要工作就是接收生产者发过来的消息，分配 offset，之后保存到此盘中；同时，接收消费者、其他 Broker 的请求，根据请求类型进行相应处理并返回响应。在一般的生产环境中，一个 Broker 独占一台物理服务器。

2.3 消费者（Consumer）

• 消费者组（Consumer Group）
  Consumer Group 是 Kafka 提供的可扩展且具有容错性的消费者机制。既然是一个组，那么组内必然可以有多个消费者，它们共享一个公共的 ID，这个 ID 被称为 Group ID。组内的所有消费者协调在一起来消费订阅主题（Topic）的所有分区（Partition）。当然，每个分区只能由同一个消费者组内的一个 Consumer 实例来消费。总之，可以总结出如下三点：
  • 消费者组下可以有一个或多个消费者实例。这里的实例可以是一个单独的进程，也可以是同一进程下的线程。
  • Group ID 是一个字符串，在一个 Kafka 集群中，它标识唯一的一个 Consumer Group。
  • Consumer Group 下所有实例订阅的主题的单个分区，只能分配给组内的某个 Consumer 实例消费。这个分区当然也可以被其他的 Group 消费。

三、主题（Topic）

 在 Broker 内部将存储的消息划分为多个逻辑分组，可以把这些分组看做是一个个消息集合，将这一个个集合命名为Topic。每个 Topic 可以有多个生产者向其中推送（push）消息，也可以有任意多个消费者拉取（pull）其中的消息，如下图所示：

四、分区（Partition）

 Topic 只是一个逻辑概念，每个 Topic 都由至少一个 Partition（分区）组成。此处的 Partition 可以简单地将其理解成是一个先进先出（FIFO）的队列（Queue）。

 分区的作用就是提供负载均衡的能力，或者说对数据进行分区的主要原因，就是为了实现系统的高伸缩性（Scalability）。不同的分区能够被放置到不同的机器上，而数据的读写操作也都是针对分区这个粒度进行的，这样每个机器都能独立地处理各自分区的读写请求。并且，还可以通过添加新的机器来增加整体系统的吞吐量。

五、位移（offset）

 每条消息在被添加到分区时，都会被分配一个 offset，它是消息在此分区中的唯一编号，Kafka 通过 offset 保证消息在分区内的顺序，offset 的顺序性不跨分区，即 Kafka 只保证在同一个分区内的消息是有序的；同一 Topic 的多个分区间的消息，Kafka 并不保证其顺序性，如下图所示：

六、副本（Replica）

 Kafka 对消息进行了冗余备份，每个 Partition 可以有多个副本，每个副本中包含的消息是一样的（在同一时刻，副本之间其实并不是完全一样的）。每个分区至少有一个副本，当分区中只有一个副本时，就只有 Leader 副本，没有 Follower 副本。
 每个分区的副本集合中，都会选举出一个副本作为 Leader 副本，Kafka 在不同的场景下会采用不同的选举策略。所有的读写请求都由选举出的 Leader 副本处理，其他都作为 Follower 副本，Follower 副本仅仅是从 Leader 副本处把数据拉去到本地之后，同步更新到自己的 Log 中。下图展示了一个拥有三个 Replica 的 Partition。

 一般情况下，同一分区的多个分区会被分配到不同的 Broker 上，这样，当 Leader 所在的 Broker 宕机之后，可以重新选举新的 Leader，继续对外提供服务。

七、保留策略

 无论消费者是否已经消费了消息，Kafka 都会一直保存这些消息，但并不会像数据库那样长期保存。为了避免磁盘被占满，Kafka 会配置相应的“保留策略”（retention policy），以实现周期性地删除陈旧的消息。Kafka 中有两种“保留策略”：

• 根据消息保留的时间
  当消息在 Kafka 中保存的时间超过了指定时间，就可以被删除；
• 根据 Topic 存储的数据大小
  当 Topic 所占的日志文件大小大于一个阈值，则可以开始删除最旧的消息。

 Kafka 会启动一个后台线程，定期检查是否存在可以删除的消息。“保留策略”的配置是非常灵活的，可以有全局的配置，也可以针对 Topic 进行配置覆盖全局配置。

八、日志压缩

 在很多场景中，消息的 key 与 value 的值之间的对应关系是不断变化的，就像数据库中的数据会不断被修改一样，消费者只关心 key 对应的最新的 value 值，此时，可以开启 Kafka 的日志压缩（Log Compaction）功能，Kafka 会在后台启动一个线程，定期将相同 key 的消息进行合并，只保留最新的 value 值。日志压缩的工作原理如下图所示，下图展示了一次日志压缩过程的简化版本。

九、ISR 集合

 ISR（In-Sync Replica）集合表示的是目前“可用”（alive）且消息量与 Leader 相差不多的副本集合，这是整个副本集合的一个子集。“可用”和“相差不多”都是很模糊的描述，其实际含义是 ISR 集合的副本必须满足下面两个条件：

1. 副本所在节点必须维持着与 ZooKeeper 的连接。
2. 副本最后一条消息的 offset 与 Leader 副本的最后一条消息的 offset 之间的差值不能超出指定的阈值。

 每个分区中的 Leader 副本都会维护此分区的 ISR 集合。写请求首先由 Leader 副本处理，之后 Follower 副本会从 Leader 上拉取写入的消息，这个过程会有一定的延迟，导致 Follower 副本中保存的消息略少于 Leader 副本，只要未超出阈值都是可以容忍的。如果一个 Follower 副本出现异常，比如：宕机，发生长时间 GC 而导致 Kafka 僵死或是网络断开连接导致长时间没有拉取消息进行同步，就会违反上面的两个条件，从而被 Leader 副本踢出 ISR 集合。当 Follower 副本从异常中恢复之后，会继续与 Leader 副本进行同步，当 Follower 副本“追上”（即最后一条消息的 offset 的差值小于指定阈值）Leader 副本的时候，此 Follower 副本会被 Leader 副本重新加入到 ISR 中。

十、HW、LEO

 HW 和 LEO 与上面的 ISR 集合紧密相关。下面先用一张图来形象的展示它们。

10.1 高水位（HW）

 高水位（HW，HighWatermark）标记了一个特殊的 offset，当消费者处理消息的时候，只能拉取到 HW 之前的消息，HW 之后的消息对消费者来说是不可见的。与 ISR 集合类似，HW 也是由 Leader 副本管理的。当 ISR 集合中全部的 Follower 副本都拉取 HW 指定消息进行同步后，Leader 副本会递增 HW 的值。Kafka 官方网站将 HW 之前的消息状态称为“commit”，其含义是这些消息在多个副本中同时存在，即使此时 Leader 副本损坏，也不会出现数据丢失。
 HW 的作用主要有以下 2 个：

• 定义消息可见性，即用来标识分区下的哪些消息是可以被消费者消费的。
• 帮助 Kafka 完成副本的消息复制。

10.2 日志末端位移（LEO）

 日志末端位移（LEO，Log End Offset）是所有的副本都会有的一个 offset 标记，它指向追加到当前副本的最后一个消息的 offset。当生产者向 Leader 副本追加消息时的时候，Leader 副本的 LEO 标记会递增；当 Follower 副本成功从 Leader 副本拉取消息并更新到本地的时候，Follower 副本的 LEO 就会增加。