kafka面试总结

1、kafka同步租户时如何防止信息丢失（事务：commit、autocommit）

在使用Kafka时，确保消息不丢失可以通过以下几个策略来实现：

（1） 设置正确的生产者确认模式（Producer Acks）:
Kafka 生产者客户端允许你指定一个称为 acks 的设置，以此来控制分区领导者在认为写操作完成之前需要收到的确认数量。你可以将其配置为：

• acks=0: 生产者不会等待来自服务器的任何确认。这种模式存在较高的数据丢失风险。
• acks=1(默认值): 只要分区领导者已经将数据写入其本地日志，就会发送确认，但是不会等待所有的副本（followers）都同步了该数据。这种模式下，如果领导者在确认写操作后、其他副本同步之前崩溃，则数据可能会丢失。
• acks=all 或 acks=-1: 这会要求所有的ISR（In-Sync Replicas）都收到数据后才认为写操作完成。这种方式提供了最高的数据持久性保证。

（2） 合理配置消费者偏移量提交（Consumer Offset Commit）:
对于消费者而言，可以通过以下两种方式来管理offsets的提交，以避免信息丢失：

• 自动提交（Auto-commit）: Kafka 提供了自动提交偏移量的功能，由 enable.auto.commit 参数控制。如果开启了自动提交（默认每5秒提交一次），确保 auto.commit.interval.ms 设置成一个合适的时间间隔，以便在处理完消息和提交偏移量之间不会丢失太多数据。

• 手动提交（Manual commit）: 关闭自动提交并手动调用 commitSync 或 commitAsync 方法来提交偏移量。这样消费者可以更精确地控制何时提交偏移量，从而防止重复或丢失消息的问题。

（3）确保幂等性生产者（Idempotent Producer）:
Kafka 0.11版本以后引入了幂等生产者的概念，通过设置 enable.idempotence=true 来确保即使生产者发送相同的消息多次，也不会导致数据的重复。

（4）利用事务（Transactional Messaging）:
如果需要跨多个分区或主题进行原子写操作，可以使用Kafka的事务支持。通过将 transactional.id 配置为非空，并在发送消息之前初始化事务 (producer.initTransactions())，然后开始事务 (producer.beginTransaction())，发送消息，并根据需要提交 (producer.commitTransaction()) 或回滚事务 (producer.abortTransaction())。

（5）合理配置消息持久化:
在 broker 端，可以通过设置如 log.flush.interval.messages 和 log.flush.interval.ms 来控制日志刷新到磁盘的频率。

（6）监控和调整副本机制:
对于关键数据，应确保有足够的副本数（replication.factor），并且副本处于同步状态。同时，可以调整 min.insync.replicas 参数来定义在认为生产请求成功之前必须确认写入的最小副本数。

通过上述方法结合使用，可以大幅度降低Kafka中信息丢失的风险。然而，系统设计总是需要在性能和持久性之间做权衡，因此具体的配置需要基于你的业务需求来决定。

Kafka和Redis都提供了消息发布与订阅的能力，但它们在设计上有一些根本性的区别，适用于不同的使用场景。

2、Kafka和Redis 消息订阅比较

（1）Kafka 消息订阅

Kafka是一个分布式流处理平台，主要用于构建实时数据管道和流应用程序。其特点包括：

1. 持久化存储：Kafka将消息持久化到磁盘，并且可以配置消息保留策略（如按时间、大小或永久保存）。
2. 高吞吐量：Kafka针对高吞吐量优化，在分布式环境下能够处理大量的数据。
3. 可扩展性：Kafka集群可以横向扩展，增加更多的broker来处理更多的负载。
4. 消费者组：多个消费者可以组成一个消费者组，每个消费者读取分配给它的分区中的消息，提高并行处理能力。
5. 消息顺序性：在单个分区内，Kafka保证消息的顺序性。
6. 重放能力：由于消息被持久化，所以消费者可以重新读取和处理旧消息。

（2） Redis 订阅

Redis是一个高性能的键值数据库，其发布订阅模式比较简单，适用于轻量级的消息通知机制。其特点包括：

1. 非持久化：标准的Redis发布订阅机制（Pub/Sub）不支持持久化，一旦消息发送给订阅者后，该消息就会丢失。
2. 低延迟：Redis的发布订阅具有极低的延迟，适合需要快速通知的场景。
3. 没有消费者状态：Redis不跟踪消费者的状态，所有订阅某个频道的客户端都会收到消息，类似于广播。
4. 不保证顺序或消息不丢失：因为没有持久化和状态跟踪，Redis不能保证消息顺序或者消息不丢失。
5. 不支持消息确认：Redis的Pub/Sub不提供任何消息确认机制。
6. 流（Stream）：Redis 5.0 中引入了 Stream 数据类型，可以支持一定程度的消息队列功能，包括持久化和消费者群组特性，这使得Redis在消息队列方面的功能更为强大。

总结

• Kafka 更适合用作可靠的消息队列，需要消息持久化、高吞吐量、消息重放、消费者状态跟踪等场景。
• Redis 的传统订阅/发布更适合作为轻量级的实时消息系统，如聊天室消息推送等；而其Stream数据类型提供了更接近消息队列的特性，但相比Kafka而言，仍然更轻量级一些。

选择哪种技术取决于你的具体需求，包括系统的规模、可靠性要求、数据量、性能目标等因素。