思维导图
面试题
Kafka 都有哪些特点？
- 高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。
- 可扩展性：kafka集群支持热扩展
- 持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
- 容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
- 高并发：支持数千个客户端同时读写
Kafka 缺点？
- 由于是批量发送，数据并非真正的实时；
- 仅支持统一分区内消息有序，无法实现全局消息有序；
- 监控不完善，需要安装插件；
- 依赖zookeeper进行元数据管理；
哪些场景下会选择 Kafka？
- 日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、HBase、Solr等。
- 消息系统：解耦和生产者和消费者、缓存消息等。
- 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
- 运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
- 流式处理：比如spark streaming和 Flink
Kafka 架构分为几个部分?
- Producer ：消息生产者，就是向 kafka broker 发消息的客户端。
- Consumer ：消息消费者，向 kafka broker 取消息的客户端。
- Topic ：可以理解为一个队列，一个 Topic 又分为一个或多个分区，
- Consumer Group：这是 kafka 用来实现一个 topic 消息的广播（发给所有的 consumer）和单播（发给任意一个 consumer）的手段。一个 topic 可以有多个 Consumer Group。
- Broker ：一台 kafka 服务器就是一个 broker。一个集群由多个 broker 组成。一个 broker 可以容纳多个 topic。
- Partition：为了实现扩展性，一个非常大的 topic 可以分布到多个 broker上，每个 partition 是一个有序的队列。partition 中的每条消息都会被分配一个有序的id（offset）。将消息发给 consumer，kafka 只保证按一个 partition 中的消息的顺序，不保证一个 topic 的整体（多个 partition 间）的顺序。
- Offset：kafka 的存储文件都是按照 offset.kafka 来命名，用 offset 做名字的好处是方便查找。例如你想找位于 2049 的位置，只要找到 2048.kafka 的文件即可。当然 the first offset 就是 00000000000.kafka。
Kafka如何防⽌消息丢失?
-
发送⽅： ack是1 或者-1/all 可以防⽌消息丢失，如果要做到99.9999%，ack设成all，把min.insync.replicas配置成分区备份数
-
消费⽅：把⾃动提交改为⼿动提交。
Kafka 如何防⽌消息的重复消费?
⼀条消息被消费者消费多次。如果为了消息的不重复消费，⽽把⽣产端的重试机制关闭、消费端的⼿动提交改成⾃动提交，这样反⽽会出现消息丢失，那么可以直接在防治消息丢失的⼿段上再加上消费消息时的幂等性保证，就能解决消息的重复消费问题。
幂等性如何保证：
- mysql 插⼊业务id作为主键，主键是唯⼀的，所以⼀次只能插⼊⼀条
- 使⽤redis或zk的分布式锁（主流的⽅案）
Kafka如何做到顺序消费?
第一种方式：
-
发送⽅：在发送时将ack不能设置0，关闭重试，使⽤同步发送，等到发送成功再发送下⼀条。确保消息是顺序发送的。
-
接收⽅：消息是发送到⼀个分区中，只能有⼀个消费组的消费者来接收消息。因此，kafka的顺序消费会牺牲掉性能。
第二种方式：
比如说我们建了一个 topic，有三个 partition。生产者在写的时候，其实可以指定一个 key，比如说我们指定了某个订单 id 作为 key，那么这个订单相关的数据，一定会被分发到同一个 partition 中去，而且这个 partition 中的数据一定是有顺序的。
写 N 个内存 queue，具有相同 key 的数据都到同一个内存 queue；然后对于 N 个线程，每个线程分别消费一个内存 queue 即可，这样就能保证顺序性。
Kafka如何解决消息积压问题?
消息积压会导致很多问题，⽐如磁盘被打满、⽣产端发消息导致kafka性能过慢，就容易出现服务雪崩，就需要有相应的⼿段：
- 在⼀个消费者中启动多个线程，让多个线程同时消费。——提升⼀个消费者的消费能⼒。
- 增加分区数量，增加消费者
Kafka 有几种数据保留的策略？
Kafka 有两种数据保存策略：按照过期时间保留和按照存储的消息大小保留。
时间：默认存储168小时（一周）
消息大小：默认 -1 （不删除），可以自行设置
Kafka 生产数据到分区方式？
- 没有指定分区编号，没有指定key时采用轮询方式存储数据
- 没有指定分区编号，指定key时，数据分发策略为对key求取hash值，这个值与分区数量取余，余数就是分区编号
- 指定分区编号，所有数据输入到指定的分区内
- 自定义分区
Kafka 分区的目的？
分区对于 Kafka 集群的好处是：实现负载均衡。分区对于消费者来说，可以提高并发度，提高效率。
数据传输的事物定义有哪三种？
数据传输的事务定义通常有以下三种级别：
- 最多一次: 消息不会被重复发送，最多被传输一次，但也有可能一次不传输
- 最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输
- 精确的一次（Exactly once）: 不会漏传输也不会重复传输,每个消息都传输被一次而且仅仅被传输一次，这是大家所期望的
Kafka 判断一个节点是否还活着有那两个条件？
- 节点必须可以维护和 ZooKeeper 的连接，Zookeeper 通过心跳机制检查每个节点的连接
- 如果节点是个 follower,他必须能及时的同步 leader 的写操作，延时不能太久
partition 的数据如何保存到硬盘?
topic 中的多个 partition 以文件夹的形式保存到 broker，每个分区序号从 0 递增，且消息有序;
Partition 文件下有多个 segment（xxx.index，xxx.log）;
segment 文件里的 大小和配置文件大小一致可以根据要求修改 默认为 1g如果大小大于 1g 时，会滚动一个新的 segment 并且以上一个 segment 最后一条消息的偏移量命名;
kafka 的 ack 机制有几种，分别是什么？
request.required.acks 有三个值 0 1 -1
- 0：生产者不会等待 broker 的 ack，这个延迟最低但是存储的保证最弱当 server 挂掉的时候就会丢数据
- 1：服务端会等待 ack 值 leader 副本确认接收到消息后发送 ack 但是如果 leader 挂掉后他不确保是否复制完成新 leader 也会导致数据丢失
- -1：同样在 1 的基础上 服务端会等所有的 follower 的副本受到数据后才会受到 leader 发出的 ack，这样数据不会丢失
Kafka 的消费者如何消费数据
消费者每次消费数据的时候，消费者都会记录消费的物理偏移量（offset）的位置等到下次消费时，他会接着上次位置继续消费
consumer 消费消息是Push还是pull？
producer 将消息推送到 broker，consumer 从broker 拉取消息。
push 模式，将消息推送到下游的 consumer。这样做有好处也有坏处：由 broker 决定消息推送的速率，对于不同消费速率的 consumer 就不太好处理了。消息系统都致力于让 consumer 以最大的速率最快速的消费消息，但不幸的是，push 模式下，当 broker 推送的速率远大于 consumer 消费的速率时，consumer 恐怕就要崩溃了。最终 Kafka 还是选取了传统的 pull 模式。
Zookeeper 对于 Kafka 的作用是什么？
Zookeeper 主要用于在集群中不同节点之间进行通信
在 Kafka 中，它被用于提交偏移量，因此如果节点在任何情况下都失败了，它都可以从之前提交的偏移量中获取除此之外，它还执行其他活动，如: leader 检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。
什么是Controller Broker?
在分布式系统中，通常需要有一个协调者，该协调者会在分布式系统发生异常时发挥特殊的作用。在Kafka中该协调者称之为控制器(Controller),其实该控制器并没有什么特殊之处，它本身也是一个普通的Broker，只不过需要负责一些额外的工作(追踪集群中的其他Broker，并在合适的时候处理新加入的和失败的Broker节点、Rebalance分区、分配新的leader分区等)。值得注意的是：Kafka集群中始终只有一个Controller Broker。
Controller Broker是如何被选出来的?
实际上，Broker 在启动时，会尝试去 ZooKeeper 中创建 /controller 节点。Kafka 当前选举控制器的规则是：第一个成功创建 /controller 节点的 Broker 会被指定为控制器。
Controller Broker的具体作用是什么?
Controller Broker的主要职责有很多，主要是一些管理行为，主要包括以下几个方面：
- 创建、删除主题，增加分区并分配leader分区
- 集群Broker管理（新增 Broker、Broker 主动关闭、Broker 故障)
- preferred leader选举
- 分区重分配
什么是 Controller 脑裂？
kafka中只有一个控制器controller 负责分区的leader选举，同步broker的新增或删除消息，但有时由于网络问题，可能同时有两个broker认为自己是controller，这时候其他的broker就会发生脑裂，不知道该听从谁的。
如何解决 Controller 脑裂？
每当新的controller产生的时候就会在zk中生成一个全新的、数值更大的controller epoch的标识，并同步给其他的broker进行保存，这样当第二个controller发送指令时，其他的broker就会自动忽略。
kafka 的高可用机制是什么？
-
多副本冗余的高可用机制
-
producer、broker 和 consumer 都会拥有多个
-
分区选举机制 、 消息确认机制
如何控制消费的位置
kafka 使用 seek(TopicPartition, long)指定新的消费位置。用于查找服务器保留的最早和最新的 offset 的特殊的方法也可用（seekToBeginning(Collection) 和seekToEnd(Collection)）
谈谈 Kafka 吞吐量为何如此高？
多分区、batch send、kafka Reator 网络模型、pagecache、sendfile 零拷贝、数据压缩
- 顺序读写
上图就展示了Kafka是如何写入数据的， 每一个Partition其实都是一个文件 ，收到消息后Kafka会把数据插入到文件末尾（虚框部分）。
这种方法有一个缺陷—— 没有办法删除数据 ，所以Kafka是不会删除数据的，它会把所有的数据都保留下来，每个消费者（Consumer）对每个Topic都有一个offset用来表示 读取到了第几条数据 。
- Page Cache
为了优化读写性能，Kafka利用了操作系统本身的Page Cache，就是利用操作系统自身的内存而不是JVM空间内存。
- 零拷贝
零拷贝就是一种避免 CPU 将数据从一块存储拷贝到另外一块存储的技术。
linux操作系统 “零拷贝” 机制使用了sendfile方法， 允许操作系统将数据从Page Cache 直接发送到网络，只需要最后一步的copy操作将数据复制到 NIC 缓冲区， 这样避免重新复制数据 。示意图如下：
通过这种 “零拷贝” 的机制，Page Cache 结合 sendfile 方法，Kafka消费端的性能也大幅提升。这也是为什么有时候消费端在不断消费数据时，我们并没有看到磁盘io比较高，此刻正是操作系统缓存在提供数据。
- 分区分段+索引
Kafka的message是按topic分类存储的，topic中的数据又是按照一个一个的partition即分区存储到不同broker节点。每个partition对应了操作系统上的一个文件夹，partition实际上又是按照segment分段存储的。这也非常符合分布式系统分区分桶的设计思想。
- 批量读写
Kafka数据读写也是批量的而不是单条的。
- 批量压缩
如果每个消息都压缩，但是压缩率相对很低，所以Kafka使用了批量压缩，即将多个消息一起压缩而不是单个消息压缩
ISR、AR 、HW、LEO是什么？
- AR：assigned replicas。通常情况下，每个分区都会被分配多个副本。具体的副本数量由参数offsets.topic.replication.factor指定。分区的AR数据保存在Zookeeper的/brokers/topics/节点中
- ISR：in-sync replicas。与leader副本保持同步状态的副本集合(leader副本本身也在ISR中)。ISR数据保存在Zookeeper的/brokers/topics//partitions//state节点中
- HW：副本高水位值，简称High Watermark，它表示该分区最新一条已提交消息(committed message)的位移
- LEO：log end offset。从名字上来看似乎是日志结束位移，但其实是下一条消息的位移，即追加写下一条消息的位移
谈一谈 Kafka 的再均衡
在Kafka中，当有新消费者加入或者订阅的topic数发生变化时，会触发Rebalance(再均衡：在同一个消费者组当中，分区的所有权从一个消费者转移到另外一个消费者)机制，Rebalance顾名思义就是重新均衡消费者消费。Rebalance的过程如下：
- 所有成员都向coordinator发送请求，请求入组。一旦所有成员都发送了请求，coordinator会从中选择一个consumer担任leader的角色，并把组成员信息以及订阅信息发给leader。
- leader开始分配消费方案，指明具体哪个consumer负责消费哪些topic的哪些partition。一旦完成分配，leader会将这个方案发给coordinator。coordinator接收到分配方案之后会把方案发给各个consumer，这样组内的所有成员就都知道自己应该消费哪些分区了。
所以对于Rebalance来说，Coordinator起着至关重要的作用
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
