kafka面试题

叁歲伎倆 2022-02-15 11:09 202阅读 0赞

### 第一部分：kafka优势 ###

1.  请说明什么是Apache Kafka?  
    Apache Kafka是由Apache开发的一种发布订阅消息系统，它是一个分布式的、分区的日志服务。
2.  kafka主要特征（kafka的高可用机制是什么？）
    
    1.  kafka将消息保存在磁盘中，以顺序读写的方式访问磁盘，从而避免了随机读写磁盘导致的性能瓶颈
    2.  kafka支持批量读写消息，并且对消息批量压缩，提高了网络利用率和压缩效率
    3.  kafka支持消息分区，每个分区中的消息保证顺序传输，而分区之间可以并发操作，提高了kafka的并发能力
    4.  kafka支持在线增加分区，支持在线水平扩展
    5.  kafka支持为每个分区创建多个副本，其中只会有一个leader副本负责读写，其他副本只负责与leader副本同步，这种方式提高了数据的容灾能力，kafka会将leader副本均匀的分布在集群中的服务器上，实现性能最大化
    6.  kafka具有近乎实时性的消息处理能力，面对海量数据，高效的存储消息和查询消息。
3.  Kafka服务器能接收到的最大信息是多少?  
    Kafka服务器可以接收到的消息的最大大小是1000000字节。
4.  请说明什么是传统的消息传递方法?  
    传统的消息传递方法包括两种：
    
    1.  排队：在队列中，一组用户可以从服务器中读取消息，每条消息都发送给其中一个人。
    2.  发布-订阅：在这个模型中，消息被广播给所有的用户。
5.  请说明Kafka相对传统技术有什么优势?
    
    1.  高吞吐量：单一的Kafka代理可以处理成千上万的客户端，每秒处理数兆字节的读写操作。
    2.  分布式系统：它以集群的方式运行，可以灵活伸缩，在内部通过复制数据提升容错能力和高可用性
    3.  持久：消息是持久性的，这些日志可以被重复读取和无限期保留。
    4.  Kafka 支持实时的流式处理
6.  Kafka的设计是什么样的呢？
    
    1.  Kafka将消息以topic为单位进行归纳  
        将向Kafka topic发布消息的程序成为producers.  
        将预订topics并消费消息的程序成为consumer.  
        Kafka以集群的方式运行，可以由一个或多个服务组成，每个服务叫做一个broker.  
        producers通过网络将消息发送到Kafka集群，集群向消费者提供消息
7.  列举kafka的应用场景  
    它可以用于两大类别的应用:
    
    1.  构造实时流数据管道，它可以在系统或应用之间可靠地获取数据。 (相当于message queue)
    2.  构建实时流式应用程序，对这些流数据进行转换或者影响。 (就是流处理，通过kafka stream topic和topic之间内部进行变化)
8.  为什么需要消息系统，mysql不能满足需求吗？
    
    1.  解耦：允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
    2.  冗余：消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。
    3.  扩展性：因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。
    4.  灵活性 & 峰值处理能力：在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。
    5.  可恢复性：系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。
    6.  顺序保证：在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。（Kafka 保证一个 Partition 内的消息的有序性）
    7.  缓冲：有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。
    8.  异步通信：很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

### 第二部分：kafka知识点 ###

1.  **broker、主题、分区、消息**
    
    1.  什么是broker？作用是什么?  
        一个单独的kafka server就是一个broker，broker主要工作就是接收生产者发过来的消息，分配offset，之后保存到磁盘中。同时，接收消费者、其他broker的请求，根据请求类型进行相应的处理并返回响应，在一般的生产环境中，一个broker独占一台物理服务器。
    2.  **kafka主题分区的作用**  
        kafka的每个topic都可以分为多个partition，每个partition都有多个replica（副本），每个分区中的消息是不同的，提高了并发读写的能力，而同一分区的不同副本中保存的是相同的消息，副本之间是一主多从关系，其中leader副本处理读写请求，follower副本只与leader副本进行消息同步，当leader副本出现故障时，则从follower副本中重新选举leader副本对外提供服务。这样，通过提高分区的数量，就可以实现水平扩展，通过提高副本数量，就可以提高容灾能力。
    3.  **Kafka创建Topic时如何将分区放置到不同的Broker中**
        
        1.  副本因子不能大于 Broker 的个数；
        2.  第一个分区（编号为0）的第一个副本放置位置是随机从 brokerList 选择的；
        3.  其他分区的第一个副本放置位置相对于第0个分区依次往后移。也就是如果我们有5个 Broker，5个分区，假设第一个分区放在第四个 Broker 上，那么第二个分区将会放在第五个 Broker 上；第三个分区将会放在第一个 Broker 上；第四个分区将会放在第二个 Broker 上，依次类推；
        4.  剩余的副本相对于第一个副本放置位置其实是由 nextReplicaShift 决定的，而这个数也是随机产生的
    4.  **消息的顺序**  
        kafka保证一个partition内消息是有序的，但是并不保证多个partition之间的数据有顺序，每个topic可以划分成多个分区，同一个topic下的不同分区包含的消息是不同的，每个消息在被添加到分区时，都会被分配一个offset，它是此消息在分区中的唯一编号，kafka通过offset保证消息在分区内的顺序，offset顺序不跨分区，即kafka只保证在同一个分区内的消息是有序的。
    5.  **kafaka生产数据时数据的分组策略**  
        生产者决定数据产生到集群的哪个partition中  
        每一条消息都是以（key，value）格式  
        Key是由生产者发送数据传入  
        所以生产者（key）决定了数据产生到集群的哪个partition
    6.  **Kafka新建的分区会在哪个目录下创建**  
        在启动 Kafka 集群之前，我们需要配置好 log.dirs 参数，其值是 Kafka 数据的存放目录，这个参数可以配置多个目录，目录之间使用逗号分隔，通常这些目录是分布在不同的磁盘上用于提高读写性能。  
        当然我们也可以配置 log.dir 参数，含义一样。只需要设置其中一个即可。  
        如果 log.dirs 参数只配置了一个目录，那么分配到各个 Broker 上的分区肯定只能在这个目录下创建文件夹用于存放数据。  
        但是如果 log.dirs 参数配置了多个目录，那么 Kafka 会在哪个文件夹中创建分区目录呢？答案是：Kafka 会在含有分区目录最少的文件夹中创建新的分区目录，分区目录名为 Topic名+分区ID。注意，是分区文件夹总数最少的目录，而不是磁盘使用量最少的目录！也就是说，如果你给 log.dirs 参数新增了一个新的磁盘，新的分区目录肯定是先在这个新的磁盘上创建直到这个新的磁盘目录拥有的分区目录不是最少为止。
2.  **生产者和消费者**
    
    1.  **consumer是推还是拉？**  
        Kafka最初考虑的问题是，customer应该从broker拉取消息还是brokers将消息推送到consumer，也就是pull还push。在这方面，Kafka遵循了一种大部分消息系统共同的传统的设计：producer将消息推送到broker，consumer从broker拉取消息。  
          
        一些消息系统比如Scribe和Apache Flume采用了push模式，将消息推送到下游的consumer。这样做有好处也有坏处：由broker决定消息推送的速率，对于不同消费速率的consumer就不太好处理了。消息系统都致力于让consumer以最大的速率最快速的消费消息，但不幸的是，push模式下，当broker推送的速率远大于consumer消费的速率时，consumer恐怕就要崩溃了。最终Kafka还是选取了传统的pull模式。Pull模式的另外一个好处是consumer可以自主决定是否批量的从broker拉取数据。  
          
        Push模式必须在不知道下游consumer消费能力和消费策略的情况下决定是立即推送每条消息还是缓存之后批量推送。如果为了避免consumer崩溃而采用较低的推送速率，将可能导致一次只推送较少的消息而造成浪费。Pull模式下，consumer就可以根据自己的消费能力去决定这些策略。  
          
        Pull有个缺点是，如果broker没有可供消费的消息，将导致consumer不断在循环中轮询，直到新消息到t达。为了避免这点，Kafka有个参数可以让consumer阻塞直到新消息的数量达到某个特定的量这样就可以批量发送。
    2.  **消费者如何不自动提交偏移量，由应用提交**
    3.  **如何控制消费的位置**  
        kafka使用seek(TopicPartition, long)指定新的消费位置。用于查找服务器保留的最早和最新的offset的特殊的方法也可用（seekToBeginning(Collection) 和 seekToEnd(Collection)
    4.  **consumer水平扩展如何实现**  
         kafka支持consumer水平扩展，可以让多个consumer加入一个consumer group，在一个consumer group中，每个分区只能分配给一个consumer，当kafka服务端增加分区数量进行水平扩展后，可以向consumer group中增加新的consumer来提高整个consumer group的消费能力，当consumer group 中的一个consumer出现故障下线时，会通过rebalance操作下线consumer，它负责处理的分区将分配给其他consumer。
    5.  **消费者负载均衡策略**  
        一个消费者组中的每个消费者成员对应主题下的每一个分区。
    6.  **producer是否直接将数据发送到broker的leader(主节点)？**  
        producer直接将数据发送到broker的leader(主节点)，不需要在多个节点进行分发，为了帮助producer做到这点，所有的Kafka节点都可以及时的告知:哪些节点是活动的，目标topic目标分区的leader在哪。这样producer就可以直接将消息发送到目的地了
    7.  **Kafa consumer是否可以消费指定分区消息？**  
        Kafa consumer消费消息时，向broker发出"fetch"请求去消费特定分区的消息，consumer指定消息在日志中的偏移量（offset），就可以消费从这个位置开始的消息，customer拥有了offset的控制权，可以向后回滚去重新消费之前的消息，这是很有意义的
    8.  [Consumer Offset Tracking（消费者offset跟踪）][Consumer Offset Tracking_offset]  
        高级别的consumer跟踪每个分区已消费的offset，并定期提交，以便在重启的情况下可以从这些offset中恢复。Kafka提供了一个选项在指定的broker中来存储所有给定的consumer组的offset，称为offset manager。例如，该consumer组的所有consumer实例向offset manager（broker）发送提交和获取offset请求。高级别的consumer将会自动处理这些过程。如果你使用低级别的consumer，你将需要手动管理offset。目前在低级别的java consumer中不支持，只能在Zookeeper中提交或获取offset。如果你使用简单的Scala consumer，将可拿到offset manager，并显式的提交或获取offset。对于包含offset manager的consumer可以通过发送GroupCoordinatorRequest到任意kafka broker，并接受GroupCoordinatorResponse响应，consumer可以继续向\`offset manager broker\`提交或获取offset。如果offset manager位置变动，consumer需要重新发现offset manager。如果你想手动管理你的offset，你可以看看[OffsetCommitRequest 和 OffsetFetchRequest的源码][OffsetCommitRequest _ OffsetFetchRequest]是如何实现的。  
        当offset manager接收到一个OffsetCommitRequest，它将追加请求到一个特定的[压缩][Link 1]名为\_\_consumer\_offsets的kafka topic中，当offset topic的所有副本接收offset之后，offset manager将发送一个提交offset成功的响应给consumer。万一offset无法在规定的时间内复制，offset将提交失败，consumer在回退之后可重试该提交（高级别consumer自动进行）。broker会定期压缩offset topic，因为只需要保存每个分区最近的offset。offset manager会缓存offset在内存表中，以便offset快速获取。  
          
        当offset manager接收一个offset的获取请求，将从offset缓存中返回最新的的offset。如果offset manager刚启动或新的consumer组刚成为offset manager（成为offset topic分区的leader），则需要加载offset topic的分区到缓存中，在这种情况下，offset将获取失败，并报出OffsetsLoadInProgress异常，consumer回滚后，重试OffsetFetchRequest（高级别consumer自动进行这些操作）。
    9.  [从ZooKeeper迁移offset到kafka][ZooKeeper_offset_kafka]  
        Kafka consumers在早先的版本中offset默认存储在ZooKeeper中。可以通过下面的步骤迁移这些consumer到Kafka：
        
        1.  在consumer配置中设置`offsets.storage=kafka` 和 `dual.commit.enabled=true`。
        2.  consumer做滚动消费，验证你的consumer是健康正常的。
        3.  在你的consumer配置中设置`dual.commit.enabled=false`。
        4.  consumer做滚动消费，验证你的consumer是健康正常的。  
            回滚（就是从kafka回到Zookeeper）也可以使用上面的步骤，通过设置 `offsets.storage=zookeeper`。
3.  **复制**
    
    1.  **Kafka为什么需要复制?**  
        保证数据的可靠性。Kafka的信息复制确保了任何已发布的消息不会丢失，并且可以在机器错误、程序错误或更常见些的软件升级中使用。
    2.  **讲一下主从同步**
    3.  **讲一讲kafka的ack的三种机制**
    4.  **同一分区的多个副本包括的消息是否一致？**  
        每个副本中包含的消息是一样的，但是再同一时刻，副本之间并不是完全一样的
    5.  为什么kafka不支持主从分离？
        
        1.  主从分离与否没有绝对的优劣，它仅仅是一种架构设计，各自有适用的场景。
        2.  第二、如你所说，Redis和MySQL都支持主从读写分离，我个人觉得这和它们的使用场景有关。对于那种读操作很多而写操作相对不频繁的负载类型而言，采用读写分离是非常不错的方案——我们可以添加很多follower横向扩展，提升读操作性能。反观Kafka，它的主要场景还是在消息引擎而不是以数据存储的方式对外提供读服务，通常涉及频繁地生产消息和消费消息，这不属于典型的读多写少场景，因此读写分离方案在这个场景下并不太适合。
        3.  第三、Kafka副本机制使用的是异步消息拉取，因此存在leader和follower之间的不一致性。如果要采用读写分离，必然要处理副本lag引入的一致性问题，比如如何实现read-your-writes、如何保证单调读（monotonic reads）以及处理消息因果顺序颠倒的问题。相反地，如果不采用读写分离，所有客户端读写请求都只在Leader上处理也就没有这些问题了——当然最后全局消息顺序颠倒的问题在Kafka中依然存在，常见的解决办法是使用单分区，其他的方案还有version vector，但是目前Kafka没有提供。
        4.  kafka不是数据库哦，不会有读的并发问题
4.  **ISR**
    
    1.  **ISR集合是什么？谁维护着？如何维护？**
        
        1.  ISR（In-Sync Replica）集合表示的是目前可用并且消息量与leader相差不多的副本集合，这是整个副本集合的一个子集
        2.  ISR集合的副本必须满足：副本所在节点必须维持着与zookeeper的连接；副本最后一条消息的offset与leader副本最后一条消息的offset之间的差值不能超出指定的阈值
        3.  每个分区的leader副本都会维护此分区的ISR集合，写请求首先由leader副本处理，之后follower副本会从leader副本上拉取写入的消息，这个过程会有一定的延迟，导致follower副本中保存的消息略少于leader副本，只要未超出阈值都是可以容忍的
    2.  **Kafka判断一个节点是否还活着有那两个条件？**
        
        1.  节点必须可以维护和ZooKeeper的连接，Zookeeper通过心跳机制检查每个节点的连接
        2.  如果节点是个follower,他必须能及时的同步leader的写操作，延时不能太久
    3.  **broker什么时候离开ISR?**  
        ISR是一组与leaders完全同步的消息副本，也就是说ISR中包含了所有提交的消息。ISR应该总是包含所有的副本，直到出现真正的故障。如果一个副本从leader中脱离出来，将会从ISR中删除。
    4.  **如果副本在ISR中停留了很长时间表明什么?**  
        如果一个副本在ISR中保留了很长一段时间，那么它就表明，跟踪器无法像在leader收集数据那样快速地获取数据。
5.  **数据丢失与重复**
    
    1.  **如何保证kafka消息不丢失？**  
        从以下3个方面分析
        
        1.  从生产者到kafka
        2.  kafka内部
        3.  kafka到消费者
    2.  **kafka如何不消费重复数据？（也就是kafka如何保证并发情况下消息只被消费一次）比如扣款，我们不能重复的扣。**
    3.  **解释一下，在数据制作过程中，你如何能从Kafka得到准确的信息?**  
        在数据中，为了精确地获得Kafka的消息，你必须遵循两件事: ，在数据生产过程中避免重复，在数据消耗期间避免重复。  
        这里有两种方法，可以在数据生成时准确地获得一个语义:  
        ·每个分区使用一个单独的写入器，每当你发现一个网络错误，检查该分区中的最后一条消息，以查看您的最后一次写入是否成功  
        在消息中包含一个主键(UUID或其他)，并在用户中进行反复制。
6.  **数据传输的事务定义有哪三种？**
    
    1.  最多一次: 消息不会被重复发送，最多被传输一次，但也有可能一次不传输
    2.  精确的一次（Exactly once）: 不会漏传输也不会重复传输,每个消息都传输被一次而且仅仅被传输一次，这是大家所期望的
    3.  最少一次: 消息不会被漏发送，最少被传输一次，但也有可能被重复传输.
7.  **Zookeeper对于Kafka的作用是什么？可以在没有Zookeeper的情况下使用Kafka吗?**  
    Zookeeper是一个开放源码的、高性能的协调服务，它用于Kafka的分布式应用。  
    Zookeeper主要用于在集群中不同节点之间进行通信。  
    在Kafka中，它被用于提交偏移量，因此如果节点在任何情况下都失败了，它都可以从之前提交的偏移量中获取。  
    除此之外，它还执行其他活动，如: leader检测、分布式同步、配置管理、识别新节点何时离开或连接、集群、节点实时状态等等。
8.  Kafka如何解决数据堆积或者说什么情况会导致 kafka 运行变慢？  
    [https://blog.csdn.net/ggh5201314/article/details/81271166][https_blog.csdn.net_ggh5201314_article_details_81271166]  
    [记一次线上Kafka消息堆积踩坑总结][Kafka]  
    [Kafka消息队列堆积问题][Kafka 1]
9.  Leader选举
    
      如果某个分区所在的服务器除了问题，不可用，kafka会从该分区的其他的副本中选择一个作为新的Leader。之后所有的读写就会转移到这个新的Leader上。现在的问题是应当选择哪个作为新的Leader。显然，只有那些跟Leader保持同步的Follower才应该被选作新的Leader。  
      Kafka会在Zookeeper上针对每个Topic维护一个称为ISR（in-sync replica，已同步的副本）的集合，该集合中是一些分区的副本。只有当这些副本都跟Leader中的副本同步了之后，kafka才会认为消息已提交，并反馈给消息的生产者。如果这个集合有增减，kafka会更新zookeeper上的记录。  
      如果某个分区的Leader不可用，Kafka就会从ISR集合中选择一个副本作为新的Leader。  
      显然通过ISR，kafka需要的冗余度较低，可以容忍的失败数比较高。假设某个topic有f+1个副本，kafka可以容忍f个服务器不可用。
    
    为什么不用少数服从多数的方法
    
      少数服从多数是一种比较常见的一致性[算法][Link 2]和Leader选举法。它的含义是只有超过半数的副本同步了，系统才会认为数据已同步；选择Leader时也是从超过半数的同步的副本中选择。这种算法需要较高的冗余度。譬如只允许一台机器失败，需要有三个副本；而如果只容忍两台机器失败，则需要五个副本。而kafka的ISR集合方法，分别只需要两个和三个副本。
    
    如果所有的ISR副本都失败了怎么办
    
      此时有两种方法可选，一种是等待ISR集合中的副本复活，一种是选择任何一个立即可用的副本，而这个副本不一定是在ISR集合中。这两种方法各有利弊，实际生产中按需选择。  
      如果要等待ISR副本复活，虽然可以保证一致性，但可能需要很长时间。而如果选择立即可用的副本，则很可能该副本并不一致。

### **第三部分：kafka日志** ###

1.  **为什么Kafka使用的是磁盘而不是内存并可以高效快速的存储**
    
    1.  存储方式：Kafka把topic中存储到多个分区中，并且每一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。
    2.  顺序写入：磁盘顺序读写速度超过内存随机读写  
        因为硬盘是机械结构，每次读写都会寻址->写入，其中寻址是一个“机械动作”，它是最耗时的。所以硬盘最“讨厌”随机I/O，最喜欢顺序I/O。为了提高读写硬盘的速度，Kafka就是使用顺序I/O。如果一个topic建立多个分区那么每个parathion都是一个文件，收到消息后Kafka会把数据插入到文件末尾。
    3.  message查找机制
        
        1.  通过索引信息可以快速定位message。
        2.  通过index元数据全部映射到memory（内存映射文件），可以避免segment file的IO磁盘操作。
        3.  通过索引文件稀疏存储，可以大幅降低index文件元数据占用空间大小。
2.  **Kafka数据存储（日志的形式）:[log日志说明][log]**
    
    1.  数据文件的分段  
        Kafka解决查询效率的手段之一是将数据文件分段，比如有100条Message，它们的offset是从0到99。假设将数据文件分成5段，第一段为0-19，第二段为20-39，以此类推，每段放在一个单独的数据文件里面，数据文件以该段中最小的offset命名。这样在查找指定offset的Message的时候，用二分查找就可以定位到该Message在哪个段中。
    2.  为数据文件建索引
        
        1.  数据文件分段使得可以在一个较小的数据文件中查找对应offset的Message了，但是这依然需要顺序扫描才能找到对应offset的Message。为了进一步提高查找的效率，Kafka为每个分段后的数据文件建立了索引文件，文件名与数据文件的名字是一样的，只是文件扩展名为.index。
        2.  索引文件中包含若干个索引条目，每个条目表示数据文件中一条Message的索引。索引包含两个部分（均为4个字节的数字），分别为相对offset和position。
        3.  相对offset：因为数据文件分段以后，每个数据文件的起始offset不为0，相对offset表示这条Message相对于其所属数据文件中最小的offset的大小。举例，分段后的一个数据文件的offset是从20开始，那么offset为25的Message在index文件中的相对offset就是25-20 = 5。存储相对offset可以减小索引文件占用的空间。
        4.  position，表示该条Message在数据文件中的绝对位置。只要打开文件并移动文件指针到这个position就可以读取对应的Message了。
        5.  index文件中并没有为数据文件中的每条Message建立索引，而是采用了稀疏存储的方式，每隔一定字节的数据建立一条索引。这样避免了索引文件占用过多的空间，从而可以将索引文件保留在内存中。但缺点是没有建立索引的Message也不能一次定位到其在数据文件的位置，从而需要做一次顺序扫描，但是这次顺序扫描的范围就很小了。
    3.  定期清除或删除已经消费完文件，减少磁盘占用。
    4.  查询机制  
        ![aHR0cHM6Ly9pbWcyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvODI1ODg3LzIwMTkwMy84MjU4ODctMjAxOTAzMjYyMTM3MzM5NDItMTY5Nzc1NjEwMi5wbmc][]
3.  **partition的数据如何保存到硬盘**  
    topic中的多个partition以文件夹的形式保存到broker，每个分区序号从0递增，且消息有序  
    Partition文件下有多个segment（xxx.index，xxx.log）  
    segment 文件里的 大小和配置文件大小一致可以根据要求修改 默认为1g  
    如果大小大于1g时，会滚动一个新的segment并且以上一个segment最后一条消息的偏移量命名
4.  **Kafka存储在硬盘上的消息格式是什么？**  
    消息由一个固定长度的头部和可变长度的字节数组组成。头部包含了一个版本号和CRC32校验码。  
    消息长度: 4 bytes (value: 1+4+n)  
    版本号: 1 byte  
    CRC校验码: 4 bytes  
    具体的消息: n bytes
5.  kafka 同时设置了 7 天和 10G 清除数据，到第五天的时候消息达到了 10G，这个时候 kafka 将如何处理？  
    进行数据合并处理。
6.  kafka 有几种数据保留的策略？（**为了避免磁盘被占满，kafka会周期性的删除陈旧的消息，删除策略是什么？**）
    
    1.   一种是根据消息保留的时间
    2.  一种是根据topic存储的数据大小
7.  **什么是日志压缩**  
    在很多场景中，消息的key与value之间的对应关系是不断变化的，消费者只关心key对应的最新value，此时，可以开启kafka的日志压缩功能，kafka会在后台启动一个线程，定期将相同key的消息进行合并，只保留最新的value值。

### 第四部分：项目实践 ###

1.  你们公司生产环境用的是什么消息中间件？为什么选择kafka？  
    这个首先你可以说下你们公司选用的是什么消息中间件，比如用的是kafka，然后可以初步给一些你对不同MQ中间件技术的选型分析。  
    因为是基于大数据项目，我们在使用的过程中，对数据吞吐量有一定的要求，主要的一个原因是kafka是apache下的一个技术，可以和其他几个大数据技术更完美的契合。
2.  为什么要在系统里引入消息中间件？或者说是解决什么样的问题？  
    回答这个问题，其实就是让你先说说消息中间件的常见使用场景，然后结合你们自身系统对应的使用场景，说一下在你们系统中引入消息中间件是解决了什么问题。
    
    1.  分析用户行为，以便做出更好的广告位
    2.  对用户的关键字进行统计，分析当前的流行趋势
    3.  有些数据，存储数据库浪费，直接存储硬盘效率低
    4.  假设用户在软件中注册，服务端收到用户的注册请求后，它会做这些操作：
        
        1.  校验用户名等信息，如果没问题会在数据库中添加一个用户记录
        2.  如果是用邮箱注册会给你发送一封注册成功的邮件，手机注册则会发送一条短信
        3.  分析用户的个人信息，以便将来向他推荐一些志同道合的人，或向那些人推荐他
        4.  发送给用户一个包含操作指南的系统通知
        5.  等等
    5.  [为什么要在系统里引入消息中间件？][Link 3]
3.  是否需要保证消息的顺序性？  
    对用户行为进行分析，不需要保证消息顺序性。
4.  下游的消费系统如果宏机了，导致几百万条消息在消息中间件里积压，此时怎么处理？或者说你们线上是否遇到过消息积压的生产故障？如果没有遇到过，你考虑如何应对？  
    **消费者负载均衡策略：**可以横向扩展消费系统，使用消费者组。  
    遇到过，开始上线的时候，消费者使用自动提交的方式，但是在提过的过程的出现了问题，一直在重复消费，导致消息积压，然后将其改为手动提交，就解决的了这个问题，虽然说这个问题不复杂，但是还是需要对其考虑清楚。
5.  你们kafka线上如何部署，部署了多少台机器，机器的配置如何？  
    4台机器，也就是4个broker。liunx系统，内存，硬盘容量大小。
    
    Kafka 集群配置推荐
    
    <table> 
     <thead> 
      <tr> 
       <th>名字</th> 
       <th>数量</th> 
       <th>内存</th> 
       <th>CPU</th> 
       <th>硬盘</th> 
      </tr> 
     </thead> 
     <tbody> 
      <tr> 
       <td>Kafka</td> 
       <td>4+</td> 
       <td>16G</td> 
       <td>8+</td> 
       <td>2+ 1TB</td> 
      </tr> 
      <tr> 
       <td>ZooKeeper</td> 
       <td>4+</td> 
       <td>8G</td> 
       <td>4+</td> 
       <td>2+ 300G</td> 
      </tr> 
     </tbody> 
    </table>
    
    内存大小分析：  
    Kafka 对于 Java 堆内存的使用反而不是很多，因为 Kafka 中的消息通常都属于“朝生夕灭”的对象实例，可以很快地垃圾回收 CGC ）。一般情况下， broker 所需的堆内存都不会超过 6GB 。所以对于一台 16GB 内存的机器而言，文件系统 page cache 的大小甚至可以达到 10～14GB!  
      
    硬盘大小分析：  
    假设在你的业务场景中， clients每天会产生 1亿条消息，每条消息保存两份并保留一周的时间，平均一条消息的大小是 1KB，那么我们需要为 Kafka 规划多少磁盘空间呢？如果每天 1 亿条消息，那么每天产生的消息会占用 1 亿 × 2 ×1KB / 1000 / 1000 = 200GB 的磁盘空间 。 我们最好再额外预留 10%的磁盘空间用于其他数据文件（比如索引文件等）的存储，因此在这种使用场景下每天新发送的消息将占用210GB 左右的磁盘空间 。 因为还要保存一周的数据，所以整体的磁盘容量规划是 210 × 7 G=1.5TB 。 当然，这是无压缩的情况 。 如果在 clients 启用了消息压缩，我们可以预估一个平均的压缩比（比如 0.5)，那么整体的磁盘容量就是 0.75TB 。  
    总之对于磁盘容量的规划和以下多个因素有关。
    
    1.  新增消息数 。
    2.  消息留存时间。
    3.  平均消息大小 。
    4.  副本数。
    5.  是否启用压缩。
6.  你们用的是kafka？那你说说kafka的底层架构原理，整体分布式架构如何实现的？磁盘上数据如何存储的？  
    zookeeper+kafka集群。  
    数据保存7天，我们经过分析，7天产生的硬盘的大小在1.5T左右，所以直接存储在硬盘中即可。
7.  zookeeper的作用：分布式锁、注册服务中心
    
    zookeeper如何实现分布式锁、其他分布式锁怎么实现
8.  Kafka如何解决数据堆积
    
    kafka消息的存储机制
    
    如何用kafka保证消息的有序性
    
    kafka如何保证并发情况下消息只被消费一次

[Consumer Offset Tracking_offset]: http://kafka.apachecn.org/documentation.html#impl_offsettracking
[OffsetCommitRequest _ OffsetFetchRequest]: https://cwiki.apache.org/confluence/display/KAFKA/Committing+and+fetching+consumer+offsets+in+Kafka
[Link 1]: http://kafka.apachecn.org/documentation.html#compaction
[ZooKeeper_offset_kafka]: http://kafka.apachecn.org/documentation.html#offsetmigration
[https_blog.csdn.net_ggh5201314_article_details_81271166]: https://blog.csdn.net/ggh5201314/article/details/81271166
[Kafka]: https://blog.csdn.net/xiaoguozi0218/article/details/80513849
[Kafka 1]: https://blog.csdn.net/StrideBin/article/details/78040177
[Link 2]: http://www.dataguru.cn/article-5747-1.html?union_site=innerlink
[log]: https://mp.csdn.net/postedit/86380368
[aHR0cHM6Ly9pbWcyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvODI1ODg3LzIwMTkwMy84MjU4ODctMjAxOTAzMjYyMTM3MzM5NDItMTY5Nzc1NjEwMi5wbmc]: /images/20220215/2b8b888a322b415e8d2acdb0463d447b.png
[Link 3]: https://www.cnblogs.com/east7/p/10323391.html