当前位置：首页 > article >正文

Kafka相关知识点（上）

article 2024/12/26 13:04:03

为什么要使用消息队列？

使用消息队列的主要目的主要记住这几个关键词:解耦、异步、削峰填谷。

解耦: 在一个复杂的系统中，不同的模块或服务之间可能需要相互依赖，如果直接使用函数调用或者 API 调用的方式，会造成模块之间的耦合，当其中一个模块发生改变时，需要同时修改调用方和被调用方的代码。而使用消息队列作为中间件，不同的模块可以将消息发送到消息队列中，不需要知道具体的接收方是谁，接收方可以独立地消费消息，实现了模块之间的解耦。

异步: 有些操作比较耗时，例如发送邮件、生成报表等，如果使用同步的方式处理，会阻塞主线程或者进程，导致系统的性能下降。而使用消息队列，可以将这些操作封装成消息，放入消息队列中，异步地处理这些操作，不影响主流程的执行，提高了系统的性能和响应速度。

削峰填谷:削峰填谷是一种在高并发场景下平衡系统压力的技术，通常用于平衡系统在高峰期和低谷期的资源利用率，提高系统的吞吐量和响应速度。在削峰填谷的过程中，通常使用消息队列作为缓冲区，将请求放入消息队列中，然后在系统负载低的时候进行处理。这种方式可以将系统的峰值压力分散到较长的时间段内，减少瞬时压力对系统的影响，从而提高系统的稳定性和可靠性。

另外消息队列还有以下优点:

1**.可靠性高：**消息队列通常具有高可靠性，可以实现消息的持久化存储、消息的备份和故障恢复等功能，保证消息不会丢失。

2.**扩展性好：**通过增加消息队列实例或者添加消费者实例，可以实现消息队列的水平扩展，提高系统的处理能力。

**3.灵活性高：**消息队列通常支持多种消息传递模式，如点对点模式和发布/订阅模式，可以根据不同的业务场景选择不同的模式。

扩展知识

消息队列实现

市面上有很多成熟的消息队列中间件可以供我们使用，其中比较常用的有kafka、activeMQ、RabbitMQ和RocketMQ等。

Kafka、ActiveMQ、RabbitMQ和RocketMQ都有哪些区别？

典型回答

Kafka、ActiveMO、RabbitMQ和RocketMQ都是常见的消息中间件，它们都提供了高性能、高可用、可扩展的消息传递机制，但它们之间也有以下一些区别:

1.消息传递模型：Kafka主要支持发布-订阅模型，ActiveMQ、RabbitMQ和RocketMQ则同时支持点对点和发布-订阅两种模型。

2.性能和吞吐量：Kafka在数据处理和数据分发方面表现出色，可以处理每秒数百万条消息，而ActiveMQ、RabbitMQ和RocketMQ的吞吐量相对较低。

3.消息分区和负载均衡：Kafka将消息划分为多个分区，并分布在多个服务器上，实现负载均衡和高可用性。ActiveMQ、RabbitMQ和RocketMQ也支持消息分区和负载均衡，但实现方式不同，例如RabbitMQ使用了一种叫做Sharding的机制。

4.开发和部署复杂度:Kafka相对比较简单，易于使用和部署，但在实现一些高级功能时需要进行一些复杂的配置。ActiveMQ、RabbitMQ和RocketMQ则提供了更多的功能和选项，也更加灵活，但相应地会增加开发和部署的复杂度。

5.社区和生态:Kafka、ActiveMQ、RabbitMQ和RocketMQ都拥有庞大的社区和完善的生态系统，但Kafka和RocketMQ目前的发展势头比较迅猛，社区活跃度也相对较高。

6.功能支持:

总的来说，这些消息中间件都有自己的优缺点，选择哪一种取决于具体的业务需求和系统架构。

扩展知识

如何选型

在选择消息队列技术时，需要根据实际业务需求和系统特点来选择，以下是一些参考因素:

1.性能和吞吐量:如果需要处理海量数据，需要高性能和高吞吐量，那么Kafka是一个不错的选择

2.可靠性：如果需要保证消息传递的可靠性，包括数据不丢失和消息不重复投递，那么RocketMQ和RabbitMQ都提供了较好的可靠性保证。

3.消息传递模型:如果需要支持发布-订阅和点对点模型，那么RocketMQ和RabbitMQ是一个不错的选择。如果只需要发布-订阅模型，Kafka则是一个更好的选择

4.消息持久化:如果需要更快地持久化消息，并且支持高效的消息查询，那么Kafka是一个不错的选择。如果需要更加传统的消息持久化方式，那么RocketMO和RabbitMO可以满足需求

5.开发和部署复杂度:Kafka比较简单，易于使用和部署，但在实现一些高级功能时需要进行一些复杂的配置RocketMQ和RabbitMQ提供了更多的功能和选项，也更加灵活，但相应地会增加开发和部署的复杂度。

6.社区和生态:Kafka、RocketMQ和RabbitMQ都拥有庞大的社区和完善的生态系统，但Kafka和RocketMO目前的发展势头比较迅猛，社区活跃度也相对较高。

7.实现语言方面，kafka是基于scala和java开发的，rocketmg、activemg等都是基于iava语言的，rabbitmg是基于erlang的。

8.功能性，上面列举过一些功能，我们在选型的时候需要看哪个可以满足我们的需求,

需要根据具体情况来选择最适合的消息队列技术。如果有多个因素需要考虑，可以进行性能测试和功能评估来辅助选择。

Kafka 为什么这么快？

kafka是一个成熟的消息队列，一直以性能高著称，它之所以能够实现高吞吐量和低延迟，主要是由于以下几个方面的优化，我试着从发送端，存储端以及消费端分别介绍一下。

消息发送

1.批量发送：Kafka 通过将多个消息打包成一个批次，减少了网络传输和磁盘写入的次数，从而提高了消息的吞吐量和传输效率。

2.异步发送:生产者可以异步发送消息，不必等待每个消息的确认，这大大提高了消息发送的效率。

3.消息压缩:支持对消息进行压缩，减少网络传输的数据量。

4.并行发送:通过将数据分布在不同的分区(Partitions)中，生产者可以并行发送消息，从而提高了吞吐量。

消息存储

1.零拷贝技术:Kafka 使用零拷贝技术来避免了数据的拷贝操作，降低了内存和 CPU 的使用率，提高了系统的性能。

2.磁盘顺序写入:Kafka把消息存储在磁盘上，且以顺序的方式写入数据。顺序写入比随机写入速度快很多，因为它减少了磁头寻道时间。避免了随机读写带来的性能损耗，提高了磁盘的使用效率。

3.页缓存:Kafka 将其数据存储在磁盘中，但在访问数据时，它会先将数据加载到操作系统的页缓存中，并在页缓存中保留一份副本，从而实现快速的数据访问。

4.稀疏索引:Kafka 存储消息是通过分段的日志文件，每个分段都有自己的索引文件。这些索引文件中的条目不是对分段中的每条消息都建立索引，而是每隔一定数量的消息建立一个索引点，这就构成了稀疏索引。稀疏索引减少了索引大小，使得加载到内存中的索引更小，提高了查找特定消息的效率

5.分区和副本:Kafka 采用分区和副本的机制，可以将数据分散到多个节点上进行处理，从而实现了分布式的高可用性和负载均衡。

消息消费

1.消费者群组：通过消费者群组可以实现消息的负载均衡和容错处理

2.并行消费：不同的消费者可以独立地消费不同的分区，实现消费的并行处理。

3.批量拉取：Kafka支持批量拉取消息，可以一次性拉取多个消息进行消费。减少网络消耗，提升性能

Kafka的架构是怎么样的？

典型回答

Kafka 的整体架构比较简单，是显式分布式架构，主要由 Producer(生产者)、broker(Kafka集群)和consumer(消费者)组成

生产者(Producer):生产者负责将消息发布到Kafka集群中的一个或多个主题(Topic)，每个Topic包含一个或多个分区(Partition)。

主题:Topic。主题是承载消息的逻辑容器，在实际使用中多用来区分具体的业务。

分区：Partition。一个有序不变的消息序列。每个主题下可以有多个分区。

消费者(Consumer)：消费者负责从Kafka集群中的一个或多个主题消费消息，并将消费的偏移量(Offset)提交回Kafka以保证消息的顺序性和一致性。

偏移量:Offset。表示分区中每条消息的位置信息，是一个单调递增且不变的值。

Kafka集群：Kafka集群是由多个Kafka节点(Broker)组成的分布式系统。每个节点都可以存储一个或多个主题(topic)的分区(partition)副本，以提供高可用性和容错能力。

如下图中，包含了 Broker1、Broker2和 Broker3组成了一个集群。用来提升高可用性。

**在集群中，每个分区(partition)都可以有多个副本。这些副本中包含了一个Leader(也可以叫做LeaderPartition 或者 Leader Replication)和多个Follower(也可以叫做Follower Partition 或者 FollowerReplication)，****只有Leader 才能处理生产者和消费者的请求，而Follower 只是Leader 的备份，用于提供数据的冗余备份和容错能力。**如果 Leader 发生故障，Kafka 集群会自动将 Follower 提升为新的 Leader，从而实现高可用性和容错能力。

ZooKeeper：ZooKeeper是Kafka集群中使用的分布式协调服务，用于维护Kafka集群的状态和元数据信息，例如主题和分区的分配信息、消费者组和消费者偏移量等。

Kafka如何保证消息不丢失？

典型回答

Kafka作为一个消息中间件，他需要结合消息生产者和消费者一起才能工作，一次消息发送包含以下是三个过程

1)Producer 端发送消息给 Kafka Broker

2)Kafka Broker 将消息进行同步并持久化数据.

3)Consumer端从Kafka Broker 将消息拉取并进行消费,

Kafka只对已提交的消息做最大限度的持久化保证不丢失，但是没办法保证100%。

但是，Kafka还是提供了很多机制来保证消息不丢失的。要想知道Kafka如何保证消息不丢失，需要从生产者、消费者以及kafka集群三个方面来分析。

1、生产者：当我们采用异步发送的时候，可以设置一个回调函数，如果发送失败，会进行重试。并且使用acks机制，比如acks=-1，就必须保证消息写入了所有的同步副本才写入成功，否则就会重试。

2、Broker集群：①具有消息的持久化机制，当消息被写入消息队列后，会被持久化到磁盘。②有同步副本：每个分区都有多个副本，副本可以分布在不同的节点上。当一个节点宕机时，其他节点上的副本仍然可以提供服务，保证消息不丢失。

3、消费者：①消费者记录每个分区消息消费的偏移量，每次都会记录下来，为了保证消息不丢失，建议使用手动提交偏移量的方式，避免拉取了消息以后，业务逻辑没处理完，提交偏移量后但是消费者挂了的问题。②Kafka消费者还可以组成消费者组，每个消费者组可以同时消费多个分区。当一个消费者组中的消费者宕机或者不可用时，其他消费者仍然可以消费该组的分区，保证消息不丢失，

Producer

消息的生产者端，最怕的就是消息发送给Kafka集群的过程中失败，所以，我们需要有机制来确保消息能够发送成功，但是，因为存在网络问题，所以基本没有什么办法可以保证一次消息一定能成功。

所以，就需要有一个确认机制来告诉生产者这个消息是否有发送成功，如果没成功，需要重新发送直到成功。

我们通常使用Kafka发送消息的时候，通常使用的 producer.send(msg)其实是一种异步发送，发送消息的时候，方法会立即返回，但是并不代表消息一定能发送成功。(producer.send(msg).get() 是同步等待返回的。)

那么，为了保证消息不丢失，通常会建议**使用 producer.send(msg，callback)方法，**这个方法支持传入一个callback，我们可以在消息发送时进行重试。

同时，我们也可以通过给producer设置一些参数来提升发送成功率:

Broker

Kafka的集群有一些机制来保证消息的不丢失，比如复制机制、持久化存储机制以及ISR机制。

·持久化存储:Kafka使用持久化存储来存储消息。这意味着消息在写入Kafka时将被写入磁盘，这种方式可以防止消息因为节点宕机而丢失。

·ISR复制机制:Kafka使用ISR机制来确保消息不会丢失，Kafka使用复制机制来保证数据的可靠性。每个分区都有多个副本，副本可以分布在不同的节点上。当一个节点宕机时，其他节点上的副本仍然可以提供服务，保证消息不丢失。

在服务端，也有一些参数配置可以调节来避免消息丢失:

Consumer

作为Kafka的消费者端，只需要确保投递过来的消息能正常消费，并且不会胡乱的提交偏移量就行了。

Kafka消费者会跟踪每个分区的偏移量，消费者每次消费消息时，都会将偏移量向后移动。当消费者宕机或者不可用时，Kafka会将该消费者所消费的分区的偏移量保存下来，下次该消费者重新启动时，可以从上一次的偏移量开始消费消息。

另外，Kafka消费者还可以组成消费者组，每个消费者组可以同时消费多个分区。当一个消费者组中的消费者宕机或者不可用时，其他消费者仍然可以消费该组的分区，保证消息不丢失，

为了保证消息不丢失，建议使用手动提交偏移量的方式，避免拉取了消息以后，业务逻辑没处理完，提交偏移量后但是消费者挂了的问题:

Kafka怎么保证消费只消费一次的?（防止重复消费）

典型回答

Kafka消息只消费一次，这个需要从多方面回答，既包含Kafka自身的机制，也需要考虑客户端自己的重复处理。

可以从以下几个方面回答:

首先，在Kafka中，每个消费者都必须加入至少一个消费者组。同一个消费者组内的消费者可以共享消费者的负载。因此，如果一个消息被消费组中的任何一个消费者消费了，那么其他消费者就不会再收到这个消息了。

另外，消费者可以通过手动提交消费位移来控制消息的消费情况。通过手动提交位移，消费者可以跟踪自己已经消费的消息，确保不会重复消费同一消息。

还有就是客户端自己可以做一些幂等机制，防止消息的重复消费。

另外可以借助Kafka的Exactly-once消费语义，其实就是引入了事务，消费者使用事务来保证消息的消费和位移提交是原子的，而生产者可以使用事务来保证消息的生产和位移提交是原子的。Exactly-once消费语义则解决了重复问题，但需要更复杂的设置和配置。

回答：

1、首先kafka使用消费者组的机制，可以确保如果一个消息被消费组中的任何一个消费者消费了，那么其他消费者就不会再收到这个消息了。

2、使用kafka的消息语义Exactly-once，它是使用了事务来保证消息的消费和位移提交是原子的，不会说消费了消息但是位移提交失败，并且生产者使用事务来保证消息的生产和位移提交是原子的，不会重复发送消息。

3、客户端做一些幂等机制，使得消息即使重复消费了，最后的结果也是一样的。

扩展知识

Kafka的三种消息传递语义

在Kafka中，有三种常见的消息传递语义：At-least-once、At-most-once和Exactly-once。其中At-least-once和Exactly-once是最常用的。

At-least-once消费语义

At-least-once消费语义意味着消费者至少消费一次消息，但可能会重复消费同一消息。在At-least-once语义中，当消费者从Kafka服务器读取消息时，消息的偏移量会被记录下来。一旦消息被成功处理，消费者会将位移提交回Kafka服务器。如果消费消息成功但是提交位移失败，这意味着该消息将在下一次重试时再次被消费。

At-least-once语义通常用于实时数据处理或消费者不能容忍数据丢失的场景，例如金融交易或电信信令。