Kafka基础与架构1.Kafka是什么核心定位与核心价值是什么Kafka是一个分布式消息队列也可以叫分布式事件流平台。它最常见的用途是做系统解耦、异步处理、削峰填谷、日志采集和实时数据流转。Kafka的核心定位不是“简单发一条消息给消费者”而是高吞吐、可持久化、可拓展的消息流系统。核心价值解耦生产者和消费者不用之间依赖异步耗时操作可以通过消息异步处理削峰流量高峰先写入Kafka消费者按能力慢慢处理广播一个Topic可以被多个消费者分组消费可回溯消费保留一段时间后消费者可以按offset重新消费高吞吐适合日志、埋点、订单事件、同步任务等海量消息场景Kafka更像一个高性能、可持久化、可拓展的消息日志系统。2.Kafka的核心架构有哪些Producer、Consumer、Broker等核心作用Kafka常见核心组件Producer生产者负责发送消息到KafkaConsumer消费者负责从Kafka拉取并处理消息BrokerKafka服务节点一台Kafka服务器就是一个BrokerTopic主题消息的逻辑分类Partition分区Topic的物理拆分单位Replica副本用于高可用Consumer Group消费组同一个组内多个消费者共同消费一个TopicController集群控制者负责分区leader选举等管理工作生产者把消息发到某个Topic的某个PartitonBroker负责存储消息消费者按消费组从partition中拉取消息并提交offset3.Topic、Partition、Replica三者的核心关系是什么Topic是逻辑概念用来区分业务消息类型比如order_topic、user_log_topicPartition是Topic的分片一个Topic可以有多个Partition每个Partition内部消息是有序追加的Replica是Partition的副本每个Partition可以有多个副本其中一个是leader其他是follower。各自作用Topic业务分类Partition提升并发和吞吐支持水平扩展。Replica提升可用性Broker宕机后仍然继续服务面试重点Kafka只保证单个Partition内有序不保证多个Partition全局有序。4.Kafka为什么吞吐量极高核心优化机制有哪些Kafka高吞吐不是靠单一技术而是一组工程优化叠加出来的核心原因第一顺序写磁盘。Kafka消息以追加方式写入日志文件顺序写比随机写快很多第二Page Cache,Kafka大量依赖操作系统页缓存数据先写入内存缓存在由系统刷盘第三零拷贝消费者读取消息时可以通过sendfile等机制减少用户态和内核态之间的数据拷贝第四批量发送Producer会把多条消息合并成批次发送减少网络请求次数第五压缩支持gzip、snappy、lz4、zstd等压缩减少网络和磁盘IO第六分区并行多个Partition可以分布到多个Broker上实现并行写入和消费第七拉模式消费Consumer自己控制拉取速度Broker压力更可控。Kafka快主要靠顺序写、Page Cache、零拷贝、批量压缩和分区并行5.Kafka适用场景和不适用场景分别是什么适用场景日志采集用户行为埋点订单、支付、库存等业务事件流异步解耦削峰填谷实时数仓、Flink/Spark Streaming数据源多系统数据同步不适用场景极低延时强实时请求例如必须毫秒级同步返回单条消息强事务一致性要求极高的核心链路消息量很小、系统简单不值得引入Kafka运维成本复杂路由、延迟消息、死信队列等能力要求很强的场景RocketMQ或RabbitMQ可能更合适Kafka的强项是高吞吐、可回放、可扩展不是所有消息场景都必须用Kafka6.Kafka和RocketMQ、RabbitMQ全方位对比Kafka吞吐量极高适合日志、埋点、流处理、大数据场景消息以Partition日志形式持久化天然支持回放顺序按Partition保证功能偏“事件流”传统消息队列能力需要业务配合RabbitMQ基于AMQP功能成熟路由能力强支持exchange、routing、key、死信队列等延迟较低适合业务消息、任务分发吞吐量通常不如KafkaRocketMQ阿里开源适合电商交易场景支持事务消息、延迟消息、顺序消息、消息轨迹等可靠性和业务能力强运维和生态要结合团队经验选择简单选择大数据日志流Kafka复杂路由和传统队列RabbitMQ电商业务消息、事务消息、延迟消息RocketMQ7.Kafka中的Broker、Controller是什么关系Controller的核心作用Broker是Kafka集群中的服务节点复杂存储和读写消息。Controller是Kafka集群中被选出来的一个特殊Broker角色它本身也是Broker只是额外承担集群管理职责Controller的核心作用监听Broker上下线负责Partition Leader选举管理分区和副本状态通知其他Broker元数据变化在KRaft架构下参与元数据管理一句话Broker负责干活Controller负责协调集群状态和leader变化8.Kafka的ZooKeeper架构与KRaft架构区别为什么新版本弃用ZooKeeper早期Kafka依赖ZooKeeper管理元数据例如Broker注册、Controller选举、Topic元数据、分区状态等。KRaft是Kafka自己实现的基于Raft思想的元数据管理机制用Kafka内部的Controller Quorum替代ZooKeeper区别ZooKeeper架构需要额外维护ZK集群KRaft架构不在依赖外部ZK架构更简单KRaft元数据管理在Kafka内部扩展性更好KRaft启动、选主、元数据传播效率更广为什么弃用ZooKeeper降低部署和运维复杂度避免ZooKeeper和Kafka两套系统协作带来的问题提升元数据管理扩展能力让Kafka架构更自洽面试可以说新版本Kafka的方向是KRaftZooKeeper架构会逐步退出历史舞台消息可靠性丢失、重复、顺序1.Kafka消息丢失可能发生在哪些环节每个环节的丢失原因是什么Kafka可能在三个环节丢失生产者、Broker、消费者生产者端发送后没等ACK就认为成功acks0或配置太弱发送失败没有重试缓冲区满了或程序异常退出Broker端Leader写入后还没有同步到副本就宕机副本数太少min.insync.replicas配置不合理磁盘故障或数据未刷盘消费者端先提交offset在处理业务处理失败后消息就丢失了消费逻辑异常但没有重试手动提交offset提交错了所以保证消息不丢失要从Producer、Broker、Consumer三端一起做2.如何全方位保证Kafka消息不会丢生产者、Broker、消费者各环节如何优化生产者端设置acksall等待所有ISR副本确认开启重试retries设置合理的delivery.timeout.ms、request.timeout.ms开启幂等生产者enable.idempotemcetrue对发送结果做回调检查Broker端Topic设置副本数大于1常见是3设置min.insync.replicas2Broker配合Producer的acksall保证磁盘、网络、监控告警可靠消费者端关闭自动提交offset处理成功后再手动提交消费失败要重试或写入死信队列业务处理和offset提交顺序要谨慎消费逻辑要做好幂等最常见的组合acksallreplication.factor3min.insync.replicas2手动提交 offset消费幂等3.Kafka为什么会出现消费重复消费常见场景有哪些Kafka默认更容易做到“至少一次”也就是消息不丢但可能重复常见重复消费场景消费者处理完业务还没提交offset就宕机offset提交失败消费者重启后从旧offset继续消费Rebalance后分区被分配给新消费者新消费者从以提交offset开始消费生产者发送成功但ACK丢失生产者重试导致重复写入网络抖动、超时重试导致重复消息重复是分布式系统常见现象业务端必须做幂等4.消息重复消费的解决方案是什么业务层如何实现幂等性解决重复消费的核心是幂等常见幂等方案数据库唯一索引用消息唯一id做唯一键重复插入直接失败Redis去重消费前setnx messageId成功才处理状态机判断订单只能从待支付到已支付重复消息不改变状态业务流水表处理前先查流水处理过就跳过乐观锁版本号更新时带version生产端可以开启幂等生产者避免部分重复写入但消费者端仍然要做幂等一句话Kafka可以减少重复但不能替代业务幂等5.Kafka如何保证消息的顺序性分区内有序与全局有序的区别Kafka只保证单个Partition内消息有序因为一个Partition是追加日志同一个消费者按offset顺序消费所以分区内天然有序但多个Partition之间是并行写入、并行消费的不保证全局顺序如果要保证某类消息有序通常做法是让同一个业务key的消息进入同一个Partition例如同一个订单号keyorderIdKafka Producer会根据key计算分区同一个key会进入同一个Partition从而保证这个订单维度有序。6.为什么多分区无法保证全局有序如何实现全局有序多分区无法保证全局有序是因为每个Partition都是独立日志不同Partition的写入和消费都是并行的。比如消息1进入p0消息2进入p1。p1的消费者可能先处理完消息2所以全局顺序无法保证。实现全局有序的方法只实现一个Partition只让一个消费者消费生产端严格按顺序发送但这样吞吐量会明显下降特殊场景下也可以按业务维度有序比如订单维度、用户维度而不是全局有序。实际项目中更推荐“局部有序”因为全局有序代价太高7.消息乱序的常见原因是什么如何避免消息乱序常见乱序原因同一业务key的消息被发送到不同PartitionProducer开启重试且允许多个未确认请求并发发送消费端多线程处理同一个Partition的消息Rebalance后处理逻辑不当业务异步处理导致后发消息先落库避免方式同一业务key固定发送到同一Partition需要强顺序时控制Producer端发送例如关注max.in.flight.requests.per.connection单个Partition内单线程顺序处理如果要多线程消费可以按业务key分发到同一个工作队列业务层用状态机或版本号兜底顺序性和吞吐量往往是矛盾的要按业务维度取舍消息积压与线上排查1.Kafka消息积压的常见原因是什么消费端、生产端、Broker端分别有哪些消息积压指生产速度大于消费速度导致未消费消息越来越多消费端原因消费者数量不足消费逻辑太慢比如调用外部接口、数据库慢SQL单条消息处理耗时过长消费者频繁重启或Rebalance消费失败一直重试生产端原因突发流量过大批量任务集中发送上游没有限流Broker端原因Broker磁盘IO高网络带宽瓶颈分区分布不足副本同步慢集群资源不足排查时不要只盯消费者也要看生产速度和Broker资源2.线上消息积压的完整排查步骤是什么如何定位问题根源排查步骤看消费者lag确认哪个Topic哪个Consumer Group积压看积压集中在哪些Partition判断是否分区不均看生产速率和消费速度确认是生产突增还是消费变慢查看消费者日志是否有异常、重试、超时查看消费耗时定位慢在业务逻辑、数据库、RPC还是外部接口查看Consumer是否频繁Rebalance查看Broker磁盘、CPU、网络、请求延时查看下游依赖是否异常比如数据库连接池满、接口限流根据根因选择扩容、限流、优化SQL、批量消费或临时跳过异常消息一句话先定位Topic和消费者再看lag分区最后从消费端、生产端、Broker、下游依赖逐层排查3.解决消息积压的最优方案有哪些不同场景如何选择不同原因对应不同方案如果是消费者能力不足增加消费者实例但不能超过分区数提高单条消息处理效率批量拉取、批量写库优化数据库和外部接口如果是分区不足增加Topic分区数配合增加消费者数量注意增加分区可能影响key顺序性如果是某些消息处理失败加重试次数上限异常消息进入死信队列避免一条坏消息阻塞整个分区如果是突发流量上游限流临时扩容消费者降级非核心逻辑如果是Broker瓶颈扩容Broker均衡Partition优化磁盘和网络调整副本同步和刷盘相关配置最优方案不是固定的关键是先定位瓶颈4.增加消费者数量能解决积压吗为什么不能超过分区数量增加消费者数量可以提升消费能力但前提是Topic有足够分区在同一个消费组内一个Partition同一时刻只能被一个消费者消费这样才能保证分区内顺序如果一个Topic有6个Partition那么同一个消费组最多6个消费者能并行消费第7个消费者会闲置。所以消费者数量超过分区数不会继续提升吞吐要提升并行度一般需要增加分区数增加消费者数优化单消费者处理速度5.分区数量的设置原则是什么过多或过少会有什么问题分区数量决定了Kafka的并行能力设置原则根据目标吞吐量估算根据消费者并行度估算考虑Broker数量和副本数给未来增长留一定余量有顺序性要求时不能盲目增加分区分区太少问题并行度不足消费者扩容受限容易积压分区太多文件句柄和内存占用增加Controller管理压力变大Rebalance成本变高Leader选举和副本同步开销增加单个Broker上小文件和日志段更多面试可以说分区数不是越多越好要在吞吐、顺序性和运维成本之间平衡6.如何避免消息积压日常运维需要注意哪些点避免积压要靠日常监控和容量规划需要关注Consumer Lag监控和告警生产速率和消费速率Broker磁盘使用率Broker网络、CPU、请求延迟消费者异常率、重试次数、处理耗时Rebalance频率下游数据库、接口、缓存状态日常优化Topic分区数提前规划消费者处理逻辑保持轻量慢操作异步化或批量化异常消息进入死信队列上游突发流量做好限流核心Topic做容量压测真正线上稳点的Kafka不是只靠参数而是靠监控、告警、限流、扩容和降级一起兜底总结Kafka是分布式事件流平台核心价值是高吞吐、可持久化、可回放、可扩展Topic是逻辑主题Partition是并行和存储单位Replica是高可用副本Kafka高吞吐靠顺序写、Page Cache、零拷贝、批量压缩、分区并行Kafka只保证单Partition有序不保证多Partition全局有序消息不丢要从Producer、Broker、Consumer三端一起保证消息重复很常见业务层必须做幂等全局有序通常只能单分区吞吐会下降实际更推荐业务维度有序消息积压先看lag再看生产速率、消费速率、分区分布和下游依赖同一消费组内消费者数量超过分区数不会提升消费能力KRaft是Kafka去ZooKeeper的新架构方向降低运维复杂度架构Producer、Consumer、Broker、Topic、Partition、Replica、Controller性能顺序写、Page Cache、零拷贝、批量、压缩、分区并行可靠性不丢、不重、幂等、顺序性分别从生产者、消费者、Broker看运维消息积压、分区规划、消费者扩容、Broker资源瓶颈