Components

Topic：Kafka 将消息种子（Feed）分门别类，每一类的消息称之为 Topic。

Partition：一个 topic 可以被分为若干个分区（partition），同一个 topic 中的不同分区可以不在一个 broker 上。即通过部署在多个 broker 上，来实现 kafka 的伸缩性，单一 topic 中的一个 partition 可以被保证有序，但是无法保证 topic 中所有的分区有序。

A topic could have multiple partitions.
Each partition is a single log file where records are written to it in an append-only fashion.
一个非常大的 Topic 可以分布到多个 Broker 上，一个 Topic 可以分为多个 Partition 进行存储，每个 Partition 是一个有序的队列。
一个 broker 可能同时是一个 partition 的 leader，另一个 partition 的 follower。这样可以平衡负载，避免所有的请求都只让一台或者某几台服务器处理。
每个 partition 有一个 leader，零或多个 follower。Leader 处理此 partition 的所有的读写请求而 follower 被动的复制数据。如果 leader 当机，其它的一个 follower 会被推举为新的 leader。

Producer: 发布消息的对象称之为 Topic Producer

Consumer: 订阅消息并处理发布的消息的种子的对象称之为 Topic Consumers

Consumer Group：生产者与消费者的关系就如同餐厅中的厨师和顾客之间的关系一样，一个厨师对应多个顾客，也就是一个生产者对应多个消费者，消费者群组（Consumer Group）指的就是由一个或多个消费者组成的群体。

一个 topic 下的一条消息只会由一个消费者组中的一个消费者消费，而不会被这个消费者组中的其他消费者也同时消费
处于不同消费者组的消费者可以同时消费同一个 topic 中的同一消息

Broker：已发布的消息保存在一组 Server 中，这一组服务器被称为一个 Kafka 集群。集群中的每一个 Kafka Server 都是一个 Broker。消费者可以订阅一个或多个 topic ，并从 Broker 拉数据，从而消费这些已发布的消息。

Rebalance：消费者组内某个消费者实例挂掉后，其他消费者实例自动重新分配订阅 topic 分区的过程。Rebalance 是 Kafka 消费者端实现高可用的重要手段。

Replica：Kafka 中消息的备份又叫做 副本（Replica），为实现数据备份的功能，保证集群中的某个节点发生故障时，该节点上的 Partition 数据不丢失，且 Kafka 仍然能够继续工作，为此 Kafka 提供了副本机制，一个 Topic 的每个 Partition 都有若干个副本，一个 Leader 副本和若干个 Follower 副本。

Leader: 每个 partition 有多个副本，其中有且仅有一个作为 Leader，Leader 是当前负责数据的读写的 partition。

Follower: Follower 跟随 Leader，所有写请求都通过 Leader 路由，数据变更会广播给所有 Follower，Follower 与 Leader 保持数据同步。如果 Leader 失效，则从 Follower 中选举出一个新的 Leader。当 Follower 与 Leader 挂掉、卡住或者同步太慢，leader 会把这个 follower 从 “in sync replicas”（ISR）列表中删除，重新创建一个 Follower。

Consumer Offset: an integer value that continually increases—is another piece of metadata that Kafka adds to each message as it is produced.

Each message in a given partition has a unique offset, and the following message has a greater offset (though not necessarily monotonically greater).
By storing the next possible offset for each partition, typically in Kafka itself, a consumer can stop and restart without losing its place.

Offset：消费者消费的位置信息，监控数据消费到什么位置，当消费者挂掉再重新恢复的时候，可以从消费位置继续消费。

Kafka Controller Broker：其实就是一个 Kafka 集群中一台 Broker，它除了具有普通 Broker 的消息发送、消费、同步功能之外，还需承担一些额外的工作。Kafka 使用公平竞选的方式来确定 Controller ，最先在 ZooKeeper 成功创建临时节点 /controller 的 Broker 会成为 Controller ，一般而言，Kafka 集群中第一台启动的 Broker 会成为 Controller，并将自身 Broker 编号等信息写入 ZooKeeper 临时节点 /controller。

工作流程

Kafka 集群会将消息流存储在 Topic 的中，每条记录会由一个 Key、一个 Value 和一个时间戳组成。

Kafka 中消息是以 Topic 进行分类的，生产者生产消息，消费者消费消息，读取和消费的都是同一个 Topic。但是 Topic 是逻辑上的概念， Partition 是物理上的概念，每个 Partition 对应一个 log 文件，该 log 文件中存储的就是 Producer 生产的数据。Producer 端生产的数据会不断顺序追加到该 log 文件末尾，并且每条数据都会记录有自己的 Offset。而消费者组中的每个消费者，也都会实时记录当前自己消费到了哪个 Offset，方便在崩溃恢复时，可以继续从上次的 Offset 位置消费。

Kafka 的保证（Guarantees）

生产者发送到一个特定的 Topic 的一个特定 partition 上的消息将会按照它们发送的顺序依次加入
消费者收到的消息也是此顺序
如果一个 Topic 配置了复制因子（replication factor）为 N，那么可以在最多 N-1 个 brokers down 掉时，仍不丢失任何已经 successfully produced 的消息

Kafka APIs

In addition to command line tooling for management and administration tasks, Kafka has five core APIs for Java and Scala:

The Admin API to manage and inspect topics, brokers, and other Kafka objects.
The Producer API to publish (write) a stream of events to one or more Kafka topics.
The Consumer API to subscribe to (read) one or more topics and to process the stream of events produced to them.
The Kafka Streams API to implement stream processing applications and microservices. It provides higher-level functions to process event streams, including transformations, stateful operations like aggregations and joins, windowing, processing based on event-time, and more. Input is read from one or more topics in order to generate output to one or more topics, effectively transforming the input streams to output streams.
The Kafka Connect API to build and run reusable data import/export connectors that consume (read) or produce (write) streams of events from and to external systems and applications so they can integrate with Kafka. For example, a connector to a relational database like PostgreSQL might capture every change to a set of tables. However, in practice, you typically don’t need to implement your own connectors because the Kafka community already provides hundreds of ready-to-use connectors.

User Case

Commit Log
Event Sourcing
Stream Processing
Log Aggregation
Metrics
Website Activity Tracking

【Kafka】Basic

Components

工作流程

Kafka 的保证（Guarantees）

Kafka APIs

User Case

Reference

FEATURED TAGS

FRIENDS

TOC