Kafka

我们可以看出 KRaft 替换 ZK，并不是元数据存储重新造轮子，而核心是集群协调机制的演进。整个通信协调机制本质上是事件驱动模型，也就是 Metadata as an Event Log，Leader 通过 KRaft 生产权威的事件，Follower 和 Broker 通过监听 KRaft 来获得这些事件，并且顺序处理事件，达到集群状态和期望的最终一致。

Flink 就会从 Kafka 的 input_topic​ 主题中读取数据，每隔五分钟按定义的 SQL 查询进行处理，并将结果写入 output_topic 主题。

选择 RocketMQ 或 Kafka 主要取决于具体的业务需求、系统要求以及团队的技术栈偏好。如果需要处理具有复杂业务逻辑的事务性消息，或需要精确控制消息顺序和定时发送的功能，RocketMQ 可能是更合适的选择。

Apache Kafka 是一个高吞吐量、分布式的流处理平台，广泛应用于实时数据管道和流处理应用中。Kafka 以其高性能、低延迟、扩展性和可靠性，成为了大数据生态系统中的重要组件。

Kafka 与其他两个主流的中间件 RabbitMQ 和 RocketMQ 相比，Kafka 最大的优势就是高吞吐量。

本次使用的Kafka版本为2.4.1，是2020年3月12日发布的版本。 可以注意到Kafka的版本号为：kafka_2.12-2.4.1，因为kafka主要是使用scala语言开发的，2.12为scala的版本号。

Kafka 最常见的应用场景就是作为消息队列。 Kafka 提供了一个可靠且可扩展的消息队列，可以处理大量数据。

值得一提的是，国内最近有个Kafka Eagle框架非常不错。它是国人维护的，而且目前还在积极地演进着。根据Kafka Eagle官网的描述，它支持最新的Kafka 2.x版本，除了提供常规的监控功能之外，还开放了告警功能（Alert），非常值得一试。

使用消息队列可以帮助我们实现系统解耦、流量管控等功能。但使用过程中可能会遇到各种各样的问题，比如系统资源使用率高、集群节点宕机等，进而影响我们生产业务正常开展。

通过本文的深入分析，我们了解到 Kafka 的事务消息功能是如何在流处理场景中提供 Exactly-Once 语义的。Kafka 通过其事务 API 和内部机制，实现了消息发送的原子性、最终一致性、隔离性和持久性，尽管在实际应用中可能存在一些性能和功能上的限制。

消息积压问题的处理取决于消息积压的类型，例如，消息积压是突发性消息积压问题？还是缓慢持续增长的消息积压问题？不同的问题的解决方案略有不同，接下来我们一起来看。

针对数据积压和数据重复问题的解决方案需要根据具体的业务需求和系统情况进行调整和优化。此外，监控和度量系统也是非常重要的，可以帮助及时发现和解决数据积压和重复问题。

kafka 是消息队列，像消息队列投递消息的是生产者，消费消息的是消费者。增加生产者和消费者的实例个数可以提升系统吞吐。多个消费者可以组成一个消费者组，不同消费者组维护自己的消费进度，互不打搅。

负载均衡方式会引起比较明显的惊群效应，比如在 Kafka Connect 集群扩缩容的时候，不是新扩缩容的节点也会出现较长的 stop-the-world 问题，在 K8s 环境中如果有节点需要进行滚动升级，也会出现类似的问题。这种负载均衡方式在 Kafka 中称之为 Eager Rebalance。

本文介绍了 Kafka 丢失消息的六个场景，使用 Kafka 时需要根据实际情况制定解决方案，希望本文介绍的场能够对你有所帮助。