本篇博客是阅读完《深入理解Kafka:核心设计与实践原理》后对作者博客中提到的面试题整理的解答

已解答

Kafka的用途有哪些？使用场景如何？

Kafka是一个分布式的消息系统，作为消息系统，他具备系统解耦，冗余存储，流量削峰，缓冲、异步通信等功能。同时他还是一个存储系统和流式处理平台，作为存储系统他能够把消息持久化到磁盘，降低数据丢失的风险；作为流式处理平台，不仅能够为各个流式处理框架提供稳定的数据来源，还提供了一些流式处理的库

Kafka中的ISR、AR又代表什么？ISR的伸缩又指什么？

分区中的所有副本统称为AR(Assigned Replicas)。所有与 leader副本保持一定程度同步的副本(包括 leader副本在内)组成ISR(In-Sync Replicas)，ISR集合是AR集合中的一个子集。消息会先发送到 leader副本，然后 follower副本才能从 leader副本中拉取消息进行同步，同步期间内 follower副本相对于 leader副本而言会有一定程度的滞后。前面所说的“一定程度的同步”是指可忍受的滞后范围，这个范围可以通过参数进行配置。与 leader副本同步滞后过多的副本(不包括 leader副本)组成OSR(Out-of-Sync Replicas)，由此可见，AR=ISR+OSR。在正常情况下，所有的 follower副本都应该与 leader副本保持一定程度的同步，即AR=ISR，OSR集合为空。
ISR的伸缩是指leader副本负责跟踪ISR集合中所有follower副本的滞后状态，有follower副本滞后太多的时候将他从ISR中剔除，OSR集合中有follower副本”追上“了leader副本将其加入ISR集合中
Kafka中的HW、LEO、LSO、LW等分别代表什么？

HW是 High Watermark的缩写，俗称高水位，它标识了一个特定的消息偏移量(offset)，消费者只能拉取到这个offset之前的消息。
LEO是 Log End Offset的缩写，它标识当前日志文件中下一条待写入消息的 offset。LEO的大小相当于当前日志分区中最后一条消息的 offset值加1。分区ISR集合中的每个副本都会维护自身的LEO，而ISR集合中最小的LEO即为分区的HW，对消费者而言只能消费HW之前的消息。
LSO(Last Stable Offset) 对未完成的事务而言，LSO 的值等于事务中第一条消息的位置(firstUnstableOffset)，对已完成的事务而言，它的值同 HW 相同
LW:Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值
Kafka中是怎么体现消息顺序性的？

通过Topic和Partition来提现，Topic是消息归类的主题是逻辑概念，Topic下有多个Partition，其在存储层面可以看成是一个可追加的日志文件，消息在被追加到Partition日志文件中的时候会分配一个特定的偏移量（offset）。offset是消息在分区中的唯一标识，Kafka通过offset来保证消息在分区内的顺序性
Kafka中的分区器、序列化器、拦截器是否了解？它们之间的处理顺序是什么？

分区器、序列化器、拦截器都是生产者客户端中的东西。
分区器是将消息发送给指定的分区的，如果在发送的消息中指定了Partition，就不需要分区器了，默认的分区器中对key进行哈希（采用MurmurHash2算法，具备高运算性能及低碰撞率），同时也可以自定义分区器
序列化器把消息对象转换成字节数组，这样才能够通过网络发送给Kafka。
生产者拦截器既可以用来在消息发送前做一些准备工作,比如按照某个规则过滤不符合要求的消息、修改消息的内容等,也可以用来在发送回调逻辑前做一些定制化的需求,比如统计类工作。
他们之间工作的顺序是拦截器 -> 序列化器 -> 分区器
Kafka生产者客户端的整体结构是什么样子的？
Kafka生产者客户端中使用了几个线程来处理？分别是什么？

使用了两个线程来进行处理：主线程和Sender线程。
主线程负责由KafkaProducer创建消息，通过拦截器、序列化器和分区器作用以后缓存到消息累加器；Sender线程负责从消息累加器中获取消息并将其发送到Kafka中
“消费组中的消费者个数如果超过topic的分区，那么就会有消费者消费不到数据”这句话是否正确？如果正确，那么有没有什么hack的手段？

是正确的，可以让多个消费线程消费同一个分区来hack，通过assign()、seek()等方法实现，这样可以打破原有的消费线程的个数不能超过分区的限制。
消费者提交消费位移时提交的是当前消费到的最新消息的offset还是offset+1?

提交的是offset + 1，表示下一条需要拉取的消息的位置
有哪些情形会造成重复消费？

位移提交动作在消费完所有拉取到的消息后才执行会造成重复消费，因为批量拉取一批消息以后，中间消费处理的过程中可能会出现异常，这样的会前面消费的消息就会再消费一次
Rebalance 的时候也会出现，一个分区在原有消费者的位移没有上传的时候分配给另外一个消费者，另外一个消费会从上一次位移的地方继续拉取消息进行消费，这样就造成了消息的重复消费，后续可以通过添加Rebalance的监听器来做一些Rebalance的工作来解决位移未提交的问题
那些情景下会造成消息漏消费？

位移提交动作在消费消息之前会造成消息漏消费，因为提交新的位移以后，可能拉取到的那一批消息中间出现异常，那么那一批消息后面的那一部分消息就不会被消费到，这样就导致了消息的漏消费
KafkaConsumer是非线程安全的，那么怎么样实现多线程消费？

第一种方式：线程封闭，每个线程实例化一个KafkaConsumer对象，一个消费线程可以消费一个或者多个分区中的消息，所有的消费线程都隶属于同一个消费者组。
第二种方式：多个消费线程同时消费同一个分区，通过assign()、seek()等方法实现，这样可以打破原有的消费线程的个数不能超过分区的限制，进一步提高消费能力。但是这种方式会导致位移提交和顺序控制的处理变得更加复杂。
简述消费者与消费组之间的关系

每一个消费者都属于一个消费者组中，消费者组能够消费到一个主题中的所有消息（实现多播），然后把这些消息通过Partition负载均衡分配给具体的消费者进行消费。