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