Kafka

Kafka

Apache Kafka由著名职业社交公司LinkedIn开发，最初是被设计⽤来解决LinkedIn公司内部海量⽇志传 输等问题。Kafka使⽤Scala语⾔编写，于2011年开源并进⼊Apache孵化器，2012年10⽉正式毕业，现 在为Apache顶级项⽬。

介绍

Kafka是⼀个分布式数据流平台，可以运⾏在单台服务器上，也可以在多台服务器上部署形成集群。它 提供了发布和订阅功能，使⽤者可以发送数据到Kafka中，也可以从Kafka中读取数据（以便进⾏后续的 处理）。Kafka具有⾼吞吐、低延迟、⾼容错等特点。

架构介绍

• Producer：Producer即⽣产者，消息的产⽣者，是消息的⼊⼝。

• kafka cluster：kafka集群，⼀台或多台服务器组成

  • Broker：Broker是指部署了Kafka实例的服务器节点。每个服务器上有⼀个或多个kafka的实 例，我们姑且认为每个broker对应⼀台服务器。每个kafka集群内的broker都有⼀个不重复的 编号，如图中的broker-0、broker-1等……
  • Topic：消息的主题，可以理解为消息的分类，kafka的数据就保存在topic。在每个broker上 都可以创建多个topic。实际应⽤中通常是⼀个业务线建⼀个topic。
  • Partition：Topic的分区，每个topic可以有多个分区，分区的作⽤是做负载，提⾼kafka的吞 吐量。同⼀个topic在不同的分区的数据是不重复的，partition的表现形式就是⼀个⼀个的⽂ 件夹！
  • Replication: 每⼀个分区都有多个副本，副本的作⽤是做备胎。当主分区（Leader）故障的 时候会选择⼀个备胎（Follower）上位，成为Leader。在kafka中默认副本的最⼤数量是10 个，且副本的数量不能⼤于Broker的数量，follower和leader绝对是在不同的机器，同⼀机 器对同⼀个分区也只可能存放⼀个副本（包括⾃⼰）。

• Consumer：消费者，即消息的消费⽅，是消息的出⼝。

  • Consumer Group：我们可以将多个消费组组成⼀个消费者组，在kafka的设计中同⼀个分 区的数据只能被消费者组中的某⼀个消费者消费。同⼀个消费者组的消费者可以消费同⼀个 topic的不同分区的数据，这也是为了提⾼kafka的吞吐量！

⼯作流程

我们看上⾯的架构图中，producer就是⽣产者，是数据的⼊⼝。Producer在写⼊数据的时候会把数据 写⼊到leader中，不会直接将数据写⼊follower！那leader怎么找呢？写⼊的流程⼜是什么样的呢？我 们看下图

1. ⽣产者从Kafka集群获取分区leader信息
2. ⽣产者将消息发送给leader
3. leader将消息写⼊本地磁盘
4. follower从leader拉取消息数据
5. follower将消息写⼊本地磁盘后向leader发送ACK
6. leader收到所有的follower的ACK之后向⽣产者发送ACK

选择partition的原则

那在kafka中，如果某个topic有多个partition，producer⼜怎么知道该将数据发往哪个partition呢？ kafka中有⼏个原则：

1. partition在写⼊的时候可以指定需要写⼊的partition，如果有指定，则写⼊对应的partition。
2. 如果没有指定partition，但是设置了数据的key，则会根据key的值hash出⼀个partition。
3. 如果既没指定partition，⼜没有设置key，则会采⽤轮询⽅式，即每次取⼀⼩段时间的数据写⼊某 个partition，下⼀⼩段的时间写⼊下⼀个partition

CK应答机制

producer在向kafka写⼊消息的时候，可以设置参数来确定是否确认kafka接收到数据，这个参数可设置 的值为 0 、 1 、 all 。

• 0代表producer往集群发送数据不需要等到集群的返回，不确保消息发送成功。安全性最低但是效 率最⾼。
• 1代表producer往集群发送数据只要leader应答就可以发送下⼀条，只确保leader发送成功。
• all代表producer往集群发送数据需要所有的follower都完成从leader的同步才会发送下⼀条，确保 leader发送成功和所有的副本都完成备份。安全性最⾼，但是效率最低。
• 最后要注意的是，如果往不存在的topic写数据，kafka会⾃动创建topic，partition和replication的数量 默认配置都是1。

Topic和数据⽇志

topic 是同⼀类别的消息记录（record）的集合。在Kafka中，⼀个主题通常有多个订阅者。对于每个 主题，Kafka集群维护了⼀个分区数据⽇志⽂件结构如下：

每个partition都是⼀个有序并且不可变的消息记录集合。当新的数据写⼊时，就被追加到partition的末 尾。在每个partition中，每条消息都会被分配⼀个顺序的唯⼀标识，这个标识被称为offset，即偏移 量。注意，Kafka只保证在同⼀个partition内部消息是有序的，在不同partition之间，并不能保证消息 有序。

Kafka可以配置⼀个保留期限，⽤来标识⽇志会在Kafka集群内保留多⻓时间。Kafka集群会保留在保留 期限内所有被发布的消息，不管这些消息是否被消费过。⽐如保留期限设置为两天，那么数据被发布到 Kafka集群的两天以内，所有的这些数据都可以被消费。当超过两天，这些数据将会被清空，以便为后 续的数据腾出空间。由于Kafka会将数据进⾏持久化存储（即写⼊到硬盘上），所以保留的数据⼤⼩可 以设置为⼀个⽐较⼤的值.

Partition结构

Partition在服务器上的表现形式就是⼀个⼀个的⽂件夹，每个partition的⽂件夹下⾯会有多组segment ⽂件，每组segment⽂件⼜包含 .index ⽂件、 .log ⽂件、 .timeindex ⽂件三个⽂件，其中 .log ⽂ 件就是实际存储message的地⽅，⽽ .index 和 .timeindex ⽂件为索引⽂件，⽤于检索消息

消费数据

多个消费者实例可以组成⼀个消费者组，并⽤⼀个标签来标识这个消费者组。⼀个消费者组中的不同消 费者实例可以运⾏在不同的进程甚⾄不同的服务器上。

如果所有的消费者实例都在同⼀个消费者组中，那么消息记录会被很好的均衡的发送到每个消费者实 例。

如果所有的消费者实例都在不同的消费者组，那么每⼀条消息记录会被⼴播到每⼀个消费者实例。

举个例⼦，如上图所示⼀个两个节点的Kafka集群上拥有⼀个四个partition（P0-P3）的topic。有两个 消费者组都在消费这个topic中的数据，消费者组A有两个消费者实例，消费者组B有四个消费者实例。 从图中我们可以看到，在同⼀个消费者组中，每个消费者实例可以消费多个分区，但是每个分区最多只 能被消费者组中的⼀个实例消费。也就是说，如果有⼀个4个分区的主题，那么消费者组中最多只能有4 个消费者实例去消费，多出来的都不会被分配到分区。其实这也很好理解，如果允许两个消费者实例同 时消费同⼀个分区，那么就⽆法记录这个分区被这个消费者组消费的offset了。如果在消费者组中动态 的上线或下线消费者，那么Kafka集群会⾃动调整分区与消费者实例间的对应关系。

使⽤场景

上⾯介绍了Kafka的⼀些基本概念和原理，那么Kafka可以做什么呢？⽬前主流使⽤场景基本如下：

消息队列（MQ）

在系统架构设计中，经常会使⽤消息队列（Message Queue）——MQ。MQ是⼀种跨进程的通信机 制，⽤于上下游的消息传递，使⽤MQ可以使上下游解耦，消息发送上游只需要依赖MQ，逻辑上和物理 上都不需要依赖其他下游服务。MQ的常⻅使⽤场景如流量削峰、数据驱动的任务依赖等等。在MQ领 域，除了Kafka外还有传统的消息队列如ActiveMQ和RabbitMQ等。

追踪⽹站活动

Kafka最出就是被设计⽤来进⾏⽹站活动（⽐如PV、UV、搜索记录等）的追踪。可以将不同的活动放⼊ 不同的主题，供后续的实时计算、实时监控等程序使⽤，也可以将数据导⼊到数据仓库中进⾏后续的离 线处理和⽣成报表等。

Metrics

Kafka经常被⽤来传输监控数据。主要⽤来聚合分布式应⽤程序的统计数据，将数据集中后进⾏统⼀的 分析和展示等。

⽇志聚合

很多⼈使⽤Kafka作为⽇志聚合的解决⽅案。⽇志聚合通常指将不同服务器上的⽇志收集起来并放⼊⼀ 个⽇志中⼼，⽐如⼀台⽂件服务器或者HDFS中的⼀个⽬录，供后续进⾏分析处理。相⽐于Flume和 Scribe等⽇志聚合⼯具，Kafka具有更出⾊的性能