Kafka高可用，高吞吐量低延迟的高并发的特性背后实现机制_kafka如何实现高并发

3.将第i个Partition的第j个Replica分配到第（(i + j) mode n）个Broker上

3.2 消息传递同步策略

============

Producer在发布消息到某个Partition时，先通过ZooKeeper找到该Partition的Leader，然后无论该Topic的Replication 数量为多少，Producer只将该消息发送到该Partition的Leader。Leader会将该消息写入其本地Log。每个Follower都从Leader pull数据。这种方式上，Follower存储的数据顺序与Leader保持一致。Follower在收到该消息并写入其Log后，向Leader发送ACK。一旦Leader收到了ISR中的所有Replica的ACK，该消息就被认为已经commit了，Leader向Producer发送ACK（前提消息生产者send消息是设置ack=all或-1）。

为了提高性能，每个Follower在接收到数据后就立马向Leader发送ACK，而非等到数据写入Log中。因此，对于已经commit的消息，Kafka只能保证它被存于多个Replica的内存中，而不能保证它们被持久化到磁盘中，也就不能完全保证异常发生后该条消息一定能被Consumer消费。

Consumer读消息也是从Leader读取，只有被commit过的消息才会暴露给Consumer。

Kafka Replication的数据流如下图所示：

4 高可用机制

=======

4.1 kafka副本

===========

分区中的所有副本统称为AR（Assigned Repllicas）存储在zk中，所有与leader副本保持一定程度同步的副本（包括Leader）组成ISR（In-Sync Replicas），ISR集合是AR集合中的一个子集

1、leader副本：响应客户端的读写请求

2、follow副本：备份leader的数据，不进行读写操作

3、ISR集合表：leader副本和所有能够与leader副本保持基本同步的follow副本，如 果follow副本和leader副本数据同步速度过慢(消息差值超过replica.lag.max.messages阈值 )或者卡住的节点( 心跳丢失超过replica.lag.time.max.ms阈值 )，该follow将会被T出ISR集合表

ISR集合表中的副本必须满足的条件

1. 副本所在的节点与zk相连

2. 副本的最后一条消息和leader副本的最后一条消息的差值不能超过阈值replica.lag.time.max.ms如果该follower在此时间间隔之内没有追上leader,则该follower将会被T出ISR

4.2 kafka通过两个手段容错

=================

• 数据备份：以partition为单位备份，副本数可设置。当副本数为N时，代表1个leader，N-1个followers，followers可以视为leader的consumer，拉取leader的消息，append到自己的系统中

• failover：

1. 当leader处于非同步中时，系统从followers中选举新leader( kakfa采用一种轻量级的方式：从broker集群中选出一个作为controller，这个controller监控挂掉的broker，为该broker上面的leader分区重新选主 )

2. 当某个follower状态变为非同步中时，leader会将此follower剔除ISR，当此follower恢复并完成数据同步之后再次进入 ISR

5 kafka高吞吐机制

============

**5.1、零拷贝——**Page Cache 结合 sendfile 方法，Kafka消费端的性能也大幅提升

=======================================================

当Kafka客户端从服务器读取数据时，如果不使用零拷贝技术，那么大致需要经历这样的一个过程：

1.操作系统将数据从磁盘上读入到内核空间的读缓冲区中。

2.应用程序（也就是Kafka）从内核空间的读缓冲区将数据拷贝到用户空间的缓冲区中。

3.应用程序将数据从用户空间的缓冲区再写回到内核空间的socket缓冲区中。

4.操作系统将socket缓冲区中的数据拷贝到NIC缓冲区中，然后通过网络发送给客户端。

非零拷贝

从图中可以看到，数据在内核空间和用户空间之间穿梭了两次，那么能否避免这个多余的过程呢？当然可以，Kafka使用了零拷贝技术，也就是直接将数据从内核空间的读缓冲区直接拷贝到内核空间的socket缓冲区，然后再写入到NIC缓冲区，避免了在内核空间和用户空间之间穿梭。

零拷贝

可见，这里的零拷贝并非指一次拷贝都没有，而是避免了在内核空间和用户空间之间的拷贝。如果真是一次拷贝都没有，那么数据发给客户端就没了不是？不过，光是省下了这一步就可以带来性能上的极大提升。

5.2、分区分段+索引

===============

Kafka的message是按topic分类存储的，topic中的数据又是按照一个一个的partition即分区存储到不同broker节点。每个partition对应了操作系统上的一个文件夹，partition实际上又是按照segment分段存储的,通过这种分区分段的设计，Kafka的message消息实际上是分布式存储在一个一个小的segment中的，每次文件操作也是直接操作的segment。为了进一步的查询优化，Kafka又默认为分段后的数据文件建立了索引文件，就是文件系统上的.index文件。这种分区分段+索引的设计，不仅提升了数据读取的效率，同时也提高了数据操作的并行操作的能力

5.3、批量发送

kafka允许进行批量发送消息，producter发送消息的时候，可以将消息缓存在本地,等到了固定条件发送到kafka

1. 等消息条数到固定条数

2. 一段时间发送一次

5.4、数据压缩

============

Kafka还支持对消息集合进行压缩，Producer可以通过GZIP或Snappy格式对消息集合进行压缩 压缩的好处就是减少传输的数据量，减轻对网络传输的压力

6 kafka防止消息丢失和重复

================

6.1 ack简介

=========

Kafka的ack机制，指的是producer的消息发送确认机制，这直接影响到Kafka集群的吞吐量和消息可靠性。

ack有3个可选值，分别是1，0，-1，ack的默认值就是1

ack=1，简单来说就是，producer只要收到一个leader成功写入的通知就认为推送消息成功了——至少一次（at least once）: 消息不会丢失，但可能被处理多次。

ack=0，简单来说就是，producer发送一次就不再发送了，不管是否发送成功——最多一次（at most once）: 消息可能丢失也可能被处理，但最多只会被处理一次

ack=-1，简单来说就是，producer只有收到分区内所有副本的成功写入的通知才认为推送消息成功了

6.2 生产者丢失和重复

============

6.2.1 数据丢失的情况

=======================

当ack=0时，如果有一台broker挂掉，那么那台broker就会接收不到这条消息

当ack=1时，如果有一台follower挂掉，那么这台follower也会丢失这条消息，

或者follower还未同步leader的数据，leader挂了，也会丢失消息

6.2.2 数据重复的情况

=======================

当ack=-1时，只要有一台follower没有与leader同步，生产者就会重新发送消息，这就造成了消息的重复

6.2.3 避免方法

====================

开启精确一次性，也就是幂等性， 再引入producer事务 ，即客户端传入一个全局唯一的Transaction ID，这样即使本次会话挂掉也能根据这个id找到原来的事务状态

enable.idempotence=true

开启后，kafka首先会让producer自动将 acks=-1，再将producer端的retry次数设置为Long.MaxValue,再在集群上对每条消息进行标记去重！

6.2.4 去重原理

====================

每个生产者线程生成的每条数据，都会添加由生产者id，分区号，随机的序列号组成的标识符： (producerid,partition,SequenceId),通过标识符对数据进行去重！

但是只能当次会话有效，如果重启了就没有效果，所以需要开启事务的支持，由客户端传入一个全局唯一的Transaction ID，这样即使本次会话挂掉也能根据这个id找到原来的事务状态。

6.3 消费者重复消费

===========

6.3.1 重复消费直接原因

==============

消费者是以维护offset的方式来消费数据的，所以如果在提交offset的过程中出问题，就会造成数据的问题， 即已经消费了数据，但是offset没提交

6.3.2 解决办法

==========

感受：

其实我投简历的时候，都不太敢投递阿里。因为在阿里一面前已经过了字节的三次面试，投阿里的简历一直没被捞，所以以为简历就挂了。

特别感谢一面的面试官捞了我，给了我机会，同时也认可我的努力和态度。对比我的面经和其他大佬的面经，自己真的是运气好。别人8成实力，我可能8成运气。所以对我而言，我要继续加倍努力，弥补自己技术上的不足，以及与科班大佬们基础上的差距。希望自己能继续保持学习的热情，继续努力走下去。

也祝愿各位同学，都能找到自己心动的offer。

分享我在这次面试前所做的准备（刷题复习资料以及一些大佬们的学习笔记和学习路线），都已经整理成了电子文档

阿里一面前已经过了字节的三次面试，投阿里的简历一直没被捞，所以以为简历就挂了。

特别感谢一面的面试官捞了我，给了我机会，同时也认可我的努力和态度。对比我的面经和其他大佬的面经，自己真的是运气好。别人8成实力，我可能8成运气。所以对我而言，我要继续加倍努力，弥补自己技术上的不足，以及与科班大佬们基础上的差距。希望自己能继续保持学习的热情，继续努力走下去。

也祝愿各位同学，都能找到自己心动的offer。

分享我在这次面试前所做的准备（刷题复习资料以及一些大佬们的学习笔记和学习路线），都已经整理成了电子文档

[外链图片转存中…(img-JNVnU2bE-1714411122961)]

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录