简介

Kafka是一个分布式、支持分区的（partition）、多副本的（replication）的基于发布/订阅模式的消息队列，主要应用于大数据实时处理领域。消息的传输过程中保存消息的容器叫做消息队列。把数据放到消息队列叫做生产者，从消息队列里边取数据叫做消费者.

特性

1）高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, 消费组对partition进行消费操作；

2）可扩展性：kafka集群支持热扩展；

3）持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失；

4）容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）；

5）高并发：支持数千个客户端同时读写；

优点

1）解耦：各位系统之间通过消息系统这个统一的接口交换数据，无须了解彼此的存在；

2）冗余：部分消息系统具有消息持久化能力，可规避消息处理前丢失的风险；

3）灵活性和消除峰值：在访问量剧增的情况下，应用仍然需要继续发挥作用，使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃；

4）可恢复性：系统中部分组件失效并不会影响整个系统，它恢复后仍然可从消息系统中获取并处理数据；

5）顺序保障：在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。Kafka保证一个Partition内的消息的有序性；

6）异步通信：在不需要立即处理请求的场景下，可以将请求放入消息系统，合适的时候再处理。

使用场景

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

名词解释

1）Producer ：消息生产者，就是向 kafka broker 发消息的客户端；

2）Consumer：消息消费者，向kafka broker 取消息的客户端；

3）Consumer Group （CG）：消费者组，由多个 consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。

4）Broker ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker可以容纳多个 topic。

5）Topic ：可以理解为一个队列， 生产者和消费者面向的都是一个topic；

6）Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker（即服务器）上，一个 topic 可以分为多个 partition，每个 partition 是一个有序的队列；

7）Replica：副本，为保证集群中的某个节点发生故障时， 该节点上的 partition 数据不丢失，且 kafka 仍然能够继续工作， kafka 提供了副本机制，一个 topic 的每个分区都有若干个副本，一个 leader 和若干个 follower。

8）leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是 leader。

9）follower：每个分区多个副本中的“从”，实时从 leader 中同步数据，保持和 leader 数据的同步。leader 发生故障时，某个 follower 会成为新的 follower。

Kafka中发布订阅的对象是topic。我们可以为每类数据创建一个topic，把向topic发布消息的客户端称作producer，从topic订阅消息的客户端称作consumer。

Producers和consumers可以同时从多个topic读写数据。一个kafka集群由一个或多个broker服务器组成，它负责持久化和备份具体的kafka消息。

集群架构

 

核心概念

Zookeeper在Kafka中的作用

所有的Kafka Broker节点一起去Zookeeper上注册，只有一个 broker 会被选举为 Controller，Controller负责管理集群 broker 的上下线，所有 topic 的分区副本分配和 leader 选举等工作。

 

Cluster & Controller

多个Broker构成一个Cluster（集群）对外提供服务，每个集群会选取一个Broker来担任Controller。

Controller职责：管理分区的状态、管理每个分区的副本状态、监听Zookeeper中数据的变化等工作。

其他Broker：监听Controller Leader的状态。

当Controller出现故障时会重新选取Controller Leader。

Producer

主要工作是生产消息，Broker响应producer的请求返回topic的元信息，比如哪些leader partition可访问；

写入方式：根据消息key的Hash值选择分区、随机轮询、或者按序轮询全部分区。

通过Producer的参数控制批量写入到partition，参数值可以设置为累计的消息的数量（如500条）、累计的时间间隔（如100ms）或者累计的数据大小(64KB)。

生产者数据可靠性保证和ACK机制：为保证 producer 发送的数据，能可靠的发送到指定的 topic， topic 的每个 partition 收到producer 发送的数据后， 都需要向 producer 发送 ack，如果producer 收到 ack， 就会进行下一轮的发送，否则重新发送数据。

acks参数配置：

0：producer 不等待 broker 的 ack，这一操作提供了一个最低的延迟， broker 一接收到还没有写入磁盘就已经返回，当 broker 故障时有可能丢失数据；

1：producer 等待 broker 的 ack， partition 的 leader 落盘成功后返回 ack，如果在 follower同步成功之前 leader 故障，那么将会丢失数据；

-1（all） ：producer 等待 broker 的 ack， partition 的 leader 和 follower 全部落盘成功后才返回 ack。但是如果在 follower 同步完成后， broker 发送 ack 之前， leader 发生故障，那么会造成数据重复。

Topic

Kafka 中消息是以 topic 进行分类， 生产者生产消息，消费者消费消息，都是面向 topic；

topic 是逻辑上的概念，而 partition 是物理上的概念，每个 partition 对应于一个log文件，该 log 文件中存储的就是 producer 生产的数据；

Producer 生产的数据会被不断追加到该log 文件末端，且每条数据都有自己的 offset；

消费者组中的每个消费者， 都会实时记录自己消费到了哪个 offset，以便出错恢复时，从上次的位置继续消费。

Kafka文件存储机制

由于生产者生产的消息会不断追加到 log 文件末尾， 为防止 log 文件过大导致数据定位效率低下， Kafka 采取了分片和索引机制，将每个partition 分为多个 segment。

每个 segment对应两个文件——“.index”文件和“.log”文件。这些文件位于一个文件夹下， 该文件夹的命名规则为：topic 名称+分区序号。

index 和 log 文件以当前 segment 的第一条消息的 offset 命名。

 

ISR集合

ISR是In-Sync Replica的缩写，ISR集合表示的是目前“可用”（alive）**且消息量与Leader相差不多的副本集合。ISR集合中的副本必须满足下面两个条件：

副本所在节点必须维持着与zookeeper的连接；

副本最后一条消息的offset 与 leader副本的最后一条消息的offset之间 的差值不能超出指定的阈值。

每个分区的leader副本会维护此分区的ISR集合，会将不符合上面两个条件的副本踢出ISR集合外。

1、每个Topic可以划分成多个分区，同一Topic下的不同分区包含的消息是不同的；

2、Topic的Partition数量大于等于Broker的数量，可以提高吞吐率；

3、同一个Partition的Replica尽量分散到不同的机器，高可用；

4、添加Partition时，Partition里面的信息不会重新分配，新增的Partition是空的；

5、Replica数量最小为1，最大为broker的数量；

6、Replica副本数越高，系统虽然越稳定，但是回来带资源和性能上的下降；

7、producer先把message发送到partition leader，再由leader发送给其他partition follower；

8、leader和follower分布在不同的broker，leader所在的broker宕机后，重新选举新的leader继续对外提供服务；

9、数据保留策略可以有全局配置，也可以针对某个Topic覆盖全局配置；

Consumer 

consumer 采用 pull（拉）模式从 broker 中读取数据。由于 consumer 在消费过程中可能会出现断电宕机等故障， consumer 恢复后，需要从故障前的位置的继续消费，所以 consumer 需要实时记录自己消费到了哪个 offset，以便故障恢复后继续消费；Kafka 0.9 版本之前， consumer 默认将 offset 保存在 Zookeeper 中，从 0.9 版本开始，consumer 默认将 offset 保存在 Kafka 一个内置的 topic 中，该 topic 为__consumer_offsets；用户也可根据需要自行维护offset信息。

Consumer Group

1、Consumer group是由各个consumer线程组成的组，partition中的每个message只能被组内的一个consumer线程消费；

2、新启动的consumer默认从partition队列最头端最新的地方开始阻塞的读message；

3、一个消费组内不管有多少个线程，都会去消费所有的partition，消费者线程数等于partition数量时效率最高；

4、消费组支持指定位置消费，从头开始，从最新开始，指定位置，详见KafkaConsumer重置Offset

5、Consumer增加或删除，或者Broker的增加或者减少都会触发 Consumer Rebalance

6、如果producer的流量增大，可以增加分区数，同时调整consumer线程数，提高吞吐量；