一篇文章就足够解决大数据实时面试

原创

已于 2023-10-17 19:09:22 修改 · 350 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#大数据 #面试 #clickhouse #Flink #Kafka

于 2023-10-17 14:14:50 首次发布

大数据实习面试题详解

··by suki

Kafka参数调优的注意事项

监控和了解系统瓶颈：在调优之前，首先要监控和了解系统的瓶颈。通过监控Kafka的各项指标，如吞吐量、延迟、堆积情况等，可以确定哪些参数需要进行调优。

确定目标和需求：在调优之前，明确目标和需求非常重要。考虑业务需求、数据量、消息大小、可用资源等因素，以便选择正确的参数来满足需求。

考虑硬件配置：Kafka的性能受到硬件配置的影响。确保Kafka运行在足够的内存、磁盘和网络带宽上，并避免资源争用问题。

配置文件调优：Kafka的配置文件（server.properties）包含了很多参数，可以对其进行调整。关注一些重要的参数，如broker数量、分区数量、副本数量、批处理大小、最大网络连接数等，根据需求合理设置这些参数。

分区和副本配置：根据负载和可用资源，合理分配分区和副本。较少的分区和副本数量有助于提高写入性能，但可能降低消费性能。

堆内存和文件描述符限制：对于较大的Kafka集群，堆内存的分配和文件描述符限制是需要注意的。根据集群规模和消息大小，调整JVM堆内存大小，并确保操作系统的文件描述符限制足够高。

生产者和消费者参数设置：根据不同的使用场景，生产者和消费者端也有一些参数可以调优，如acks参数、batch.size、linger.ms等。根据需求选择合适的参数来平衡吞吐量和延迟。

定期优化和测试：Kafka的负载和需求可能会随时间变化，因此定期进行性能测试和参数调优是必要的。通过监控和测试，及时发现问题并进行调整。

请注意，Kafka参数调优并非一劳永逸的过程，需要根据实际情况进行持续的监控和调整。在调优过程中，建议先进行小范围的测试和验证，再逐步扩大规模和负载，以确保系统的稳定性和可靠性。
Properties props = new Properties();
props.put("bootstrap.servers", "localhost:9092");       
props.put("group.id", "test");
props.put("enable.auto.commit", "true");
props.put("auto.commit.interval.ms", "1000");
props.put("auto.offset.reset", "earliest");
props.put("session.timeout.ms", "30000");
props.put("fetch.min.bytes", "1048576");
props.put("fetch.max.wait.ms", "2000");
props.put("max.partition.fetch.bytes", "2097152");
props.put("max.poll.records", "10000");
props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");

KafkaConsumer<String, String> consumer = new KafkaConsumer<String, String>(props);

Kafka生产者如何实现幂等性写入和事务 &Kafka的producer如何实现幂等性?

答：

首先什么是幂等性？ Kafka作为分布式MQ，大量用于分布式系统中，如消息推送系统、业务平台系统（结算平台）等，就拿结算来说，业务方作为上游把数据打到结算平台，如果一份数据被计算、处理了多次，产生的后果将会特别严重。

其次那些因素影响幂等性？使用Kafka时,需要保证exactly-once语义。要知道在分布式系统中，出现网络分区是不可避免的，如果Kafka broker 在回复ack时，出现网络故障或者是Full gc导致ack timeout，producer将会重发，如何保证producer重试时不造成重复or乱序？又或者producer 挂了，新的producer并没有old producer的状态数据，这个时候如何保证幂等？即使Kafka 发送消息满足了幂等，consumer拉取到消息后，把消息交给线程池workers，workers线程对message的处理可能包含异步操作，又会出现以下情况：

先commit，再执行业务逻辑：提交成功，处理失败。造成丢失

先执行业务逻辑，再commit：提交失败，执行成功。造成重复执行

先执行业务逻辑，再commit：提交成功，异步执行fail。造成丢失

因此Kafka在0.11版新增了幂等型producer和事务型producer。前者解决了单会话幂等性等问题，后者解决了多会话幂等性。

单会话幂等性 为解决producer重试引起的乱序和重复。Kafka增加了pid和seq。Producer中每个RecordBatch都有一个单调递增的seq; Broker上每个tp（主题分区）也会维护pid-seq的映射，并且每Commit都会更新lastSeq。这样recordBatch到来时，broker会先检查RecordBatch再保存数据：如果batch中 baseSeq(第一条消息的seq)比Broker维护的序号(lastSeq)大1，则保存数据，否则不保存(inSequence方法)。

多会话幂等性 事务指的是在跨多个Kafka主题或分区上进行的一组操作，这些操作具有原子性，即要么全部成功，要么全部失败。因此，Kafka生产者可以使用事务来确保消息发送具有原子性和一致性。kafka事务引入了transactionId （事务id）和Epoch（时代），设置transactional.id后，一个transactionId只对应一个pid, 且Server 端会记录最新的 Epoch 值。这样有新的producer初始化时，会向TransactionCoordinator发送InitPIDRequest请求， TransactionCoordinator 已经有了这个 transactionId对应的 meta，会返回之前分配的 PID，并把 Epoch 自增 1 返回，这样当old producer恢复过来请求操作时，将被认为是无效producer抛出异常。如果没有开启事务，TransactionCoordinator会为新的producer返回new pid，这样就起不到隔离效果，因此无法实现多会话幂等。

注意：

消费者必须设置isolation.level参数为read_committed，以读取只有提交事务的消息。

如果使