业务视角谈谈Kafka（第三篇）

本文接第二篇续，日常工作中使用kafka，可能会遇到的一些问题！欢迎留言补充

问题24：在一个应用中，如果一个topic开始由名为A的消费组消费，后来把消费组名改为B（开始的命名不规范），重新发布应用，这个时候是不是从topic的分区头开始消费？如何保证从上次A消费组的最新偏移量处开始消费？

•把A改成B对于Kafka而言就是新的consumer。新consumer从头还是从最新开始消费取决于auto.offset.reset

问题25：消息经常堆积，常见原因？

•1、生产速度大于消费速度，可以适当增加分区，增加consumer数量，提升消费 TPS；•2、consumer消费性能低，检查是否有很重的消费逻辑（比如拿到消息后写HDFS或Hbase），优化consumer TPS；•3、 确保consumer端有没有因为异常而导致消费hang住;•4、 如果使用的是消费者组，确保没有频繁地发生rebalance

问题26：Producer怎么获取元数据信息？

•集群元数据持久化在ZooKeeper中，同时也缓存在每台Broker的内存中。Producer直接请求broker来获取元数据信息。

问题27：Producer与Broker 的TCP 连接是怎么管理的？

•假设一个Kafka集群中有1000台Broker，Producer只需要与5台Broker交互，它连接池中的链接数量先是1000，空闲检测再回收到5，再创建1000。可能数字不一定准确，但趋势是这样的，有极大的优化空间。

问题28：事务型 Producer 怎么实现多分区以及多会话上的消息无重复的呢？

•两阶段提交（2PC）。引入了事务协调器的组件帮助完成分布式事务

问题29：事务支持多个producer？

•不是，限单个producer

问题30：事务是不是限同一个topic？

•不是，可以同时多个topic

问题31：kafka的消息交付可靠性保障有哪几种？

•最多一次（at most once）：消息可能会丢失，但绝不会被重复发送。•至少一次（at least once）：消息不会丢失，但有可能被重复发送。•精确一次（exactly once）：消息不会丢失，也不会被重复发送。

问题32：同一个consumer 组的两个消费实例通过assign方法订阅同一个TopicPartition，是不是会有一个消费者不能消费到消息？

•使用assign，则表明该consumer是独立consumer（standalone consumer），它不再属于任何consumer组，两个独立consumer可以订阅并消费相同的分区。

问题33：kafka有基于时间戳的消费方式吗？

• KafkaConsumer的offsetsForTimes方法

问题34：follower是异步拉取数据，当生产端设置ack=all时，消息是怎么保证到follower的？

•通过HW机制（high watermark）。leader处的HW要等所有follower LEO都越过了才会前移，consumer无法消费leader副本中位移值大于HW的消息。也就是说，只有消息备份成功才能消费。

问题35：Kafka 会自动调整 ISR 集合，将该一个副本被“踢出”ISR，follow副本还会做同步操作吗？

•会

问题36：幂等性 Producer为什么只能有效于单分区、单会话？

•单分区，是因为采用空间换时间机制，在broker端保留消息的关键属性，每次接收请求后会做重复判断，各分区间不会数据共享。单会话，是因为去重的关键属性有Producer ID和seq number，非重试场景下sendMessage会对seq number递增。

问题37：事务型Producer提交事务消息，如果失败怎么办？

• 直接抛异常，用户自行解决，比如反复重试。RocketMQ 提供了事务反查机制

问题38：kafka的可靠保障采用exactly once（精确一次）模式，消费端是不是天然支持幂等？

• 直不会。有可能consumer消费成功，但ack响应失败，消息还是会再次推送过来。