Kafka 笔记

一、kafka简介

Kafka最初由 Linkedin 公司开发，是一个分布式、分区的、多副本的、多订阅者，基于 zookeeper 协调的分布式日志系统，也可以作为MQ消息系统。Linkedin 公司在2010 年贡献给了Apache基金会并成为了顶级开源项目。

简单一句话，是一款分布式消息发布和订阅系统，它的特点是高性能、高吞吐量。消息中间件主要解决的就是分布式系统之间消息传递的问题，它能够屏蔽各种平台以及协议之间的特性，实现应用程序之间的协同。

---

二、Kafka的基本概念

1、Broker【经纪人、中介者】

Kafka集群中包含的服务器，有一个或多个服务器，这种服务器被称为 Broker。Broker 端不维护数据的消费状态，提升了性能。直接使用磁盘进行存储，线性读写，速度快。避免了在JVM 内存和系统内存之间的复制，减少耗性能的创建对象和垃圾回收。

Broker接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。Broker为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。

2、Producer【生产者】

生产者，即消息的发布者，其会将某 topic 的消息发布到相应的 partition 中。生产者在默认情况下把消息均衡地分布到主题的所有分区上，而并不关心特定消息会被写到哪个分区。不过，在某些情况下，生产者会把消息直接写到指定的分区。

3、Consumer【消费者】

负责从Broker 拉取数据并进行处理。一个消费者可以消费多个 topic 的消息。

每个 Consumer 属于一个特定的 Consumer Group 【消费者组】，可为每个 Consumer 指定Group name，若不指定 Group name 则属于默认的 Group；

注意：每条消息只可以被消费者组中的一个Consumer消费，但是可以指定多个 Consumer Group，所以一个消息在 Consumer Group 里面只可以被消费一次。

4、Topic【主题】

每条发布到kafka集群的消息都有一个类别，这个类别被称为Topic。Topic相当于消息的分配标签，是一个逻辑概念。主题好比是数据库的表，或者文件系统中的文件夹。物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个服务器上，但是用户只需指定消费的Topic，即刻就可以生产或消费数据而不必关心数据存于何处。

5、Partition【分区】

Topic中的消息被分割为一个或多个的 partition，是物理上的概念。消息以追加的形式写入分区，以先后顺序的方式读取。

Topic 在逻辑上可以被认为是一个 queue （队列），每发送一条消息必须指定它的Topic，可以简单理解为必须指明把这条消息放入到哪个queue里。为了使得kafka 的吞吐率可以线性提高，物理上把Topic 分成一个或多个Partition，每个Partition 在物理上对应一个文件夹，该文件夹下存储这个Partition 的所有消息和索引文件。若创建 Topic1 和Topic2 两个Topic，且分别有13个和19个分区，则整个集群上相应会生成共32个文件夹。

分区可以分布在不同的服务器上，也就是说，一个主题可以跨越多个服务器，以此来提供比单个服务器更强大的性能。

注意：由于一个主题包含无数个分区，因此无法保证消息在整个 topic 中有序，但是单个 Partition 分区可以保证有序。消息被迫加写入每个分区的尾部。Kafka 通过分区来实现数据冗余和伸缩性

6、Segment

Segment 被译为段，将 Partition 进一步细分为若干个 segment，每个 segment 文件的大小相等。

---

三、kafka分布式消息原理

在Kafka中，Topic 是一个存储消息的逻辑概念，可以认为是一个消息集合。每条消息发送到 Kafka 集群的消息都有一个类别。物理上来说，不同的topic的消息是分开存储的。每个Topic 可以有多个生产者向它发送消息，也可以有多个消费者去消费其中的消息。

每个Topic 又可以划分为多个分区（每个Topic至少有一个分区），同一topic 不同分区包含的消息是不同的。每个消息在被添加到分区时，都会被分配一个 offset （偏移量），它是消息在此分区中的唯一编号，kafka 通过offset 保证消息在分区内的顺序，offset 的顺序不跨分区，即kafka 只保证同一个分区内的消息是有序的。

对于一个Consumer Group而言，消费者的数量不应该多余分区的数量，因为在一个Group中，每个分区至多只能绑定到一个消费者上，即一个消费者可以消费多个分区，一个分区只能给一个消费者消费。因此，若一个Group中的消费者数量大于分区数量的话，多余的消费者将不会收到任何消息。

---

四、kafka分区机制

分区机制是kafka实现高吞吐的秘密武器。从数据组织形式来说，kafka有三层形式，kafka有多个主题，每个主题有多个分区，每个分区又有多条消息。而每个分区可以分布到不同的机器上，，这样一来，从服务端来说，分区可以实现高伸缩性，以及负载均衡，动态调节的能力。

当然多分区就意味着每条消息都难以按照顺序存储，那么是不是意味着这样的业务场景kafka就无能为力呢？不是的，最简单的做法可以使用单个分区，单个分区，所有消息自然都顺序写入到一个分区中，就跟顺序队列一样了。而复杂些的，还有其他办法，那就是使用按消息键，将需要顺序保存的消息存储的单独的分区，其他消息存储到其他分区。

分区写入策略

所谓分区写入策略，即是生产者将数据写入到kafka主题后，kafka如何将数据分配到不同分区中的策略。

常见的有三种策略，轮询策略，随机策略，和按键保存策略。其中轮询策略是默认的分区策略，而随机策略则是较老版本的分区策略，不过由于其分配的均衡性不如轮询策略，故而后来改成了轮询策略为默认策略。

1）轮询策略

所谓轮询策略，即按顺序轮流将每条数据分配到每个分区中。

举个例子，假设主题test有三个分区，分别是分区A，分区B和分区C。那么主题对接收到的第一条消息写入A分区，第二条消息写入B分区，第三条消息写入C分区，第四条消息则又写入A分区，依此类推。

轮询策略是默认的策略，故而也是使用最频繁的策略，它能最大限度保证所有消息都平均分配到每一个分区。

2）随机策略

随机策略，也就是每次都随机地将消息分配到每个分区。其实大概就是先得出分区的数量，然后每次获取一个随机数，用该随机数确定消息发送到哪个分区。

在比较早的版本，默认的分区策略就是随机策略，但其实使用随机策略也是为了更好得将消息均衡写入每个分区。但后来发现对这一需求而言，轮询策略的表现更优，所以社区后来的默认策略就是轮询策略了。

3）按键保存策略

按键保存策略，就是当生产者发送数据的时候，可以指定一个key，计算这个key的hashCode值，按照hashCode的值对不同消息进行存储。

至于要如何实现，那也简单，只要让生产者发送的时候指定key就行。欸刚刚不是说默认的是轮询策略吗？其实啊，kafka默认是实现了两个策略，没指定key的时候就是轮询策略，有的话那就是按键保存策略了。

让需要顺序存储的数据都指定相同的键，而不需要顺序存储的数据指定不同的键，这样一来，即实现了顺序存储的需求，又能够享受到kafka多分区的优势，岂不美哉。

---

五、kafka副本机制

说完了分区，再来说说副本。先说说副本的基本内容，在kafka中，每个主题可以有多个分区，每个分区又可以有多个副本。这多个副本中，只有一个是leader，而其他的都是follower副本。仅有leader副本可以对外提供服务。

多个follower副本通常存放在和leader副本不同的broker中。通过这样的机制实现了高可用，当某台机器挂掉后，其他follower副本也能迅速”转正“，开始对外提供服务。

这里通过问题来整理这部分内容。

1、kafka的副本都有哪些作用？

在kafka中，实现副本的目的就是冗余备份，且仅仅是冗余备份，所有的读写请求都是由leader副本进行处理的。follower副本仅有一个功能，那就是从leader副本拉取消息，尽量让自己跟leader副本的内容一致。

2、follower副本为什么不对外提供服务？

这个问题本质上是对性能和一致性的取舍。试想一下，如果follower副本也对外提供服务那会怎么样呢？首先，性能是肯定会有所提升的。但同时，会出现一系列问题。类似数据库事务中的幻读，脏读。

比如你现在写入一条数据到kafka主题a，消费者b从主题a消费数据，却发现消费不到，因为消费者b去读取的那个分区副本中，最新消息还没写入。而这个时候，另一个消费者c却可以消费到最新那条数据，因为它消费了leader副本。

看吧，为了提高那么些性能而导致出现数据不一致问题，那显然是不值得的。

3、leader副本挂掉后，如何选举新副本？

如果你对zookeeper选举机制有所了解，就知道zookeeper每次leader节点挂掉时，都会通过内置id，来选举处理了最新事务的那个follower节点。

从结果上来说，kafka分区副本的选举也是类似的，都是选择最新的那个follower副本，但它是通过一个In-sync（ISR）副本集合实现。

kafka会将与leader副本保持同步的副本放到ISR副本集合中。当然，leader副本是一直存在于ISR副本集合中的，在某些特殊情况下，ISR副本中甚至只有leader一个副本。

当leader挂掉时，kakfa通过zookeeper感知到这一情况，在ISR副本中选取新的副本成为leader，对外提供服务。

但这样还有一个问题，前面提到过，有可能ISR副本集合中，只有leader，当leader副本挂掉后，ISR集合就为空，这时候怎么办呢？这时候如果设置unclean.leader.election.enable参数为true，那么kafka会在非同步，也就是不在ISR副本集合中的副本中，选取出副本成为leader，但这样意味这消息会丢失，这又是可用性和一致性的一个取舍了。

4、ISR副本集合保存的副本的条件是什么？

上面一直说ISR副本集合中的副本就是和leader副本是同步的，那这个同步的标准又是什么呢？

答案其实跟一个参数有关：replica.lag.time.max.ms。

前面说到follower副本的任务，就是从leader副本拉取消息，如果持续拉取速度慢于leader副本写入速度，慢于时间超过replica.lag.time.max.ms后，它就变成“非同步”副本，就会被踢出ISR副本集合中，存入OSR（Outof-Sync Replicas）列表。但后面如果follower副本的速度慢慢提上来，那就又可能会重新加入ISR副本集合中了。新加入的follower也会先存放在OSR中。AR=ISR+OSR。【AR:Assigned Replicas 所有副本】

---

 六、Kafka到底会不会丢失消息？

在讨论kafka是否丢消息前先来了解一下什么是消息传递语义。

message delivery semantic 也就是消息传递语义，简单说就是消息传递过程中消息传递的保证性。主要分为三种：

• at most once：最多一次。消息可能丢失也可能被处理，但最多只会被处理一次。
• at least once：至少一次。消息不会丢失，但可能被处理多次。可能重复，不会丢失。
• exactly once：精确传递一次。消息被处理且只会被处理一次。不丢失不重复就一次。

理想情况下肯定是希望系统的消息传递是严格exactly once，也就是保证不丢失、只会被处理一次，但是很难做到。

回到主角Kafka，Kafka有三次消息传递的过程：

1. 生产者发消息给Kafka Broker。
2. Kafka Broker 消息同步和持久化
3. Kafka Broker 将消息传递给消费者。

在这三步中每一步都有可能会丢失消息，下面详细分析为什么会丢消息，如何最大限度避免丢失消息。

a、生产者丢失消息

先介绍一下生产者发送消息的一般流程（部分流程与具体配置项强相关，这里先忽略）：

1. 生产者是与leader直接交互，所以先从集群获取topic对应分区的leader元数据；
2. 获取到leader分区元数据后直接将消息发给过去；
3. Kafka Broker对应的leader分区收到消息后写入文件持久化；
4. Follower拉取Leader消息与Leader的数据保持一致；
5. Follower消息拉取完毕需要给Leader回复ACK确认消息；
6. Kafka Leader和Follower分区同步完，Leader分区会给生产者回复ACK确认消息。

生产者采用push模式将数据发布到broker，每条消息追加到分区中，顺序写入磁盘。消息写入Leader后，Follower是主动与Leader进行同步。

Kafka消息发送有两种方式：同步（sync）和异步（async），默认是同步方式，可通过producer.type属性进行配置。

Kafka通过配置request.required.acks属性来确认消息的生产：

• 0---表示不进行消息接收是否成功的确认；
• 1---表示当Leader接收成功时确认；
• -1---表示Leader和Follower都接收成功时确认；

kafka producer 的参数acks 的默认值为1，所以默认的producer级别是at least once，并不能exactly once。

敲黑板了，这里可能会丢消息的！

• 如果acks配置为0，发生网络抖动消息丢了，生产者不校验ACK自然就不知道丢了。
• 如果acks配置为1保证leader不丢，但是如果leader挂了，恰好选了一个没有ACK的follower，那也丢了。
• all：保证leader和follower不丢，但是如果网络拥塞，没有收到ACK，会有重复发的问题。

b、Kafka Broker丢失消息

Kafka Broker 接收到数据后会将数据进行持久化存储，你以为是下面这样的：

 

 　　　　　　　　　　消息持久化，无cache

没想到是这样的：

　　　　　　　　　　消息持久化，有cache

操作系统本身有一层缓存，叫做 Page Cache，当往磁盘文件写入的时候，系统会先将数据流写入缓存中，至于什么时候将缓存的数据写入文件中是由操作系统自行决定。

Kafka提供了一个参数 producer.type 来控制是不是主动flush，如果Kafka写入到mmap之后就立即 flush 然后再返回 Producer 叫同步 (sync)；写入mmap之后立即返回 Producer 不调用 flush 叫异步 (async)。

敲黑板了，这里可能会丢消息的！

Kafka通过多分区多副本机制中已经能最大限度保证数据不会丢失，如果数据已经写入系统 cache 中但是还没来得及刷入磁盘，此时突然机器宕机或者掉电那就丢了，当然这种情况很极端。

c、消费者丢失消息

消费者通过pull模式主动的去 kafka 集群拉取消息，与producer相同的是，消费者在拉取消息的时候也是找leader分区去拉取。

多个消费者可以组成一个消费者组（consumer group），每个消费者组都有一个组id。同一个消费组者的消费者可以消费同一topic下不同分区的数据，但是不会出现多个消费者消费同一分区的数据。

消费者消费的进度通过offset保存在kafka集群的__consumer_offsets这个topic中。

消费消息的时候主要分为两个阶段：

1、标识消息已被消费，commit offset坐标；

2、处理消息。

敲黑板了，这里可能会丢消息的！

场景一：先commit再处理消息。如果在处理消息的时候异常了，但是offset 已经提交了，这条消息对于该消费者来说就是丢失了，再也不会消费到了。

场景二：先处理消息再commit。如果在commit之前发生异常，下次还会消费到该消息，重复消费的问题可以通过业务保证消息幂等性来解决。

---

七、总结

那么问题来了，kafka到底会不会丢消息？答案是：会！

Kafka可能会在三个阶段丢失消息：

（1）生产者发送数据；

（2）Kafka Broker 存储数据；

（3）消费者消费数据；

在生产环境中严格做到exactly once其实是难的，同时也会牺牲效率和吞吐量，最佳实践是业务侧做好补偿机制，万一出现消息丢失可以兜底。

解决办法：

针对消息丢失：同步模式下，确认机制设置为-1，即让消息写入Leader和Follower之后再确认消息发送成功；异步模式下，为防止缓冲区满，可以在配置文件设置不限制阻塞超时时间，当缓冲区满时让生产者一直处于阻塞状态；

针对消息重复：将消息的唯一标识保存到外部介质中，每次消费时判断是否处理过即可。