Kafka使用总结

Kafka 是由 Apache 软件基金会开发的一个开源流处理平台，由 Scala 和 Java 编写。Kafka 是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。

#### 主要特性

- 高吞吐量、低延迟：Kafka 每秒可以处理几十万条消息，它的延迟最低只有几毫秒。
- 可扩展性：Kafka 集群支持热扩展。
- 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失。
- 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）。
- 高并发：支持数千个客户端同时读写。

#### 使用场景

- 日志收集：一个公司可以用 Kafka 可以收集各种服务的 log，通过 Kafka 以统一接口服务的方式开放给各种 consumer，例如 hadoop、Hbase、Solr 等。
- 消息系统：解耦和生产者和消费者、缓存消息等。
- 用户活动跟踪：Kafka 经常被用来记录 Web 用户或者 APP 用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到 Kafka 的 topic 中，然后订阅者通过订阅这些 topic 来做实时的监控分析，或者装载到 hadoop、数据仓库中做离线分析和挖掘。
- 运营指标：Kafka 也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
- 流式处理：比如 spark streaming 和 storm。
- 事件源。

#### 基本概念

- Broker: 和 AMQP 里协议的概念一样， 就是消息中间件所在的服务器。
- Topic(主题) : 每条发布到 Kafka 集群的消息都有一个类别，这个类别被称为 Topic。（物理上不同 Topic 的消息分开存储，逻辑上一个 Topic 的消息虽然保存于一个或多个 broker 上但用户只需指定消息的 Topic 即可生产或消费数据而不必关心数据存于何处）。
- Partition(分区) : Partition 是物理上的概念，体现在磁盘上面，每个 Topic 包含一个或多个 Partition。
- Producer: 负责发布消息到 Kafka broker。
- Consumer: 消息消费者，向 Kafka broker 读取消息的客户端。
- Consumer Group（消费者群组）: 每个 Consumer 属于一个特定的 Consumer Group（可为每个 Consumer 指定group - name，若不指定 group name 则属于默认的 group）。
- offset偏移量：是 Kafka 用来确定消息是否被消费过的标识，在 Kafka 内部体现就是一个递增的数字。

#### 四个核心 API

- Producer API（生产者 API）允许应用程序发布记录流至一个或多个 Kafka 的 topics（主题）。
- Consumer API（消费者 API）允许应用程序订阅一个或多个 topics（主题），并处理所产生的对他们记录的数据流。
- Streams API（流 API）允许应用程序充当流处理器，从一个或多个 topics（主题）消耗的输入流，并产生一个输出流至一个或多个输出的 topics（主题），有效地变换所述输入流，以输出流。
- Connector API（连接器 API）允许构建和运行 topics（主题）连接到现有的应用程序或数据系统中重用生产者或消费者。例如，关系数据库的连接器可能捕获对表的每个更改。

![](/upload/article/7e6/4/14/2016142137.jpeg)

在 Kafka 中，客户端和服务器之间的通信是通过简单，高性能，语言无关的 TCP 协议完成的。此协议已版本化并保持与旧版本的向后兼容性。

#### Topic 和 Partition

一个 Topic 可以认为是一类消息，每个 Topic 将被分成多个 Partition（区），每个 Partition 在存储层面是 append log 文件。

Topic 是发布记录的类别或订阅源名称。Kafka 的 Topic 总是多用户; 一个主题可以有零个，一个或多个消费者订阅写入它的数据。

对于每个 Topic，Kafka 集群都维护一个如下所示的分区日志：

![](/upload/article/7e6/4/14/204358822.png)

每个分区都是一个有序的，不可变的记录序列，不断附加到结构化的提交日志中。分区中的记录每个都分配了一个称为偏移的顺序ID号，它唯一地标识分区中的每个记录。

Kafka 集群持久保存所有已发布的记录 - 无论是否已使用 - 使用可配置的保留期。例如，如果保留策略设置为两天，则在发布记录后的两天内，它可供使用，之后将被丢弃以释放空间。Kafka 的性能在数据大小方面实际上是恒定的，因此长时间存储数据不是问题。

![](/upload/article/7e6/4/14/2044282367.png)

实际上，基于每个消费者保留的唯一元数据是该消费者在日志中的偏移或位置。这种偏移由消费者控制：通常消费者在读取记录时会线性地提高其偏移量，但事实上，由于该位置由消费者控制，因此它可以按照自己喜欢的任何顺序消费记录。例如，消费者可以重置为较旧的偏移量来重新处理过去的数据，或者跳到最近的记录并从 “现在” 开始消费。

这些功能组合意味着 Kafka 消费者 consumers 非常 cheap - 他们可以来来往往对集群或其他消费者没有太大影响。例如，您可以使用我们的命令行工具 “tail” 任何主题的内容，而无需更改任何现有使用者所消耗的内容。

日志中的分区有多种用途。首先，它们允许日志扩展到超出适合单个服务器的大小。每个单独的分区必须适合托管它的服务器，但主题可能有许多分区，因此它可以处理任意数量的数据。其次，它们充当了并行性的单位 - 更多的是它。

#### Distribution 分配

一个 Topic 的多个 partitions，被分布在 Kafka 集群中的多个 server上；每个 server（Kafka 实例）负责 partitions 中消息的读写操作；此外 Kafka 还可以配置 partitions 需要备份的个数（replicas）,每个 Partition 将会被备份到多台机器上，以提高可用性。

基于 replicated 方案，那么就意味着需要对多个备份进行调度。每个 Partition 都有一个 server 为 “leader”，leader 负责所有的读写操作，如果 leader 失效，那么将会有其他 follower 来接管（成为新的 leader）。follower 只是单调的和 leader 跟进，同步消息即可。由此可见作为 leader 的 server 承载了全部的请求压力，因此从集群的整体考虑，有多少个 partitions 就意味着有多少个 “leader”，Kafka 会将 “leader” 均衡的分散在每个实例上，来确保整体的性能稳定。

#### Producers 和 Consumers

Producers（生产者）将数据发布到指定的topics。同时 Producer 也能决定将此消息归属于哪个 Partition，比如基于 “round-robin” 方式或者通过其他的一些算法等。

Consumers（消费者）本质上 Kafka 只支持 Topic。每个 consumer 属于一个 consumer group。反过来说，每个 Group 中可以有多个 Consumer。发送到 Topic 的消息，只会被订阅此 Topic 的每个 group 中的一个 consumer 消费。

如果所有使用者实例具有相同的使用者组，则记录将有效地在使用者实例上进行负载平衡。

如果所有消费者实例具有不同的消费者组，则每个记录将广播到所有消费者进程。

![](/upload/article/7e6/4/14/212334163.png)

分析：两个服务器 Kafka 群集，托管四个分区（P0-P3），包含两个使用者组。消费者组A有两个消费者实例，B组有四个消费者实例。

在 Kafka 中实现消费 Consumption 的方式是通过在消费者实例上划分日志中的分区，以便每个实例在任何时间点都是分配的 “公平份额” 的独占消费者。维护组中成员资格的过程由 Kafka 协议动态处理。如果新实例加入该组，他们将从该组的其他成员接管一些分区，如果实例死亡，其分区将分发给其余实例。

Kafka 仅提供分区内记录的总订单，而不是主题中不同分区之间的记录。对于大多数应用程序而言，按分区排序与按键分区数据的能力相结合就足够了。但是，如果您需要对记录进行总订单，则可以使用仅包含一个分区的主题来实现，但这将意味着每个使用者组只有一个使用者进程。

Kafka使用总结

相关文章

热门标签

热门文章