kafka学习笔记

深碍√TFBOYSˉ_ 2023-10-15 13:21 9阅读 0赞

**目录**

1.kafka简介

2.详细图解

3.kafka性能为什么这么高

4.log日志详解

5.kafka的选举机制

6.kafka怎么保证消息不丢失

7.kafka的3种消息传递语义acks

--------------------

### 1.kafka简介 ###

Kafka是由Apache软件基金会开发并开源的一个分布式流处理平台和消息队列系统。它以高吞吐量、可扩展性和持久性而闻名，广泛应用于构建实时数据管道和大规模数据处理应用。

Kafka主要由以下几个核心组件组成：

controller/master:集群中控制器，它负责管理整个集群中所有分区和副本的状态和元数据的管理
    
    Producer：消息生产者，就是向 kafka broker 发消息的客户端；
    
    Consumer：消息消费者，向 kafka broker 取消息的客户端；
    
    Consumer Group（CG）：消费者组，由多个consumer 组成。消费者组内每个消费者负责消费不同分区的数据，一个分区只能由一个组内消费者消费；消费者组之间互不影响。
    					所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。
    
    Broker：一台kafka服务器就是一个broker。一个集群由多个 broker 组成。一个 broker可以容纳多个 topic。
    		为了支持Producer直接向Leader Partition写数据，所有的Kafka服务节点都支持Topic Metadata的请求，返回哪些Server节点存活的、Partition的Leader节点的分布情况。
    
    Topic：可以理解为一个队列，生产者和消费者面向的都是一个 topic；
    
    Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，
    		一个 topic可以分为多个partition，每个partition是一个有序的队列；
    
    Replica：副本，为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作，kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower。
    
    leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader。
    
    follower：每个分区多个副本中的“从”，实时从leader中同步数据，保持和 leader数据的同步。leader发生故障时，某个follower会成为新的 follower。

Kafka采用基于磁盘的持久化机制，在消息被处理之前将其持久化到磁盘上，保证消息的可靠性。此外，Kafka支持水平扩展，能够处理大规模的消息流，并提供了丰富的API和工具，支持实时数据处理、流式处理、日志收集和传输等多种应用场景。

总结起来，Kafka是一个高性能、分布式的流处理平台和消息队列系统，它通过主题、分区和副本的概念，实现了高吞吐量、可靠性和可扩展性，为构建实时数据管道和大规模数据处理应用提供了一种强大而灵活的解决方案。

### 2.详细图解 ###

![9c9860f7074542f7b6db7875b2704ec2.png][]

### 3.kafka性能为什么这么高 ###

1.避免小的I/O请求，将消息组合在一起（同分区的消息一起发送）并分摊网络往返的开销，而不是一次发送单个消息。服务器依次将消息块一次性附加到其日志中，而消费者一次获取大的线性块。  
这种简单的优化会产生数量级的加速。批处理导致更大的网络数据包、更大的顺序磁盘操作、连续的内存块等等，所有这些都允许 Kafka 将突发的随机消息写入流转换为流向消费者的线性写入。  
**优化方式：数据设置批处理大小，异步发送**  
2：磁盘的顺序写入性能比随机写高很多倍。  
**优化方式：分区内只顺序追加写入**  
3：生产和消费时数据的字节频繁复制。写入时副本间的复制，读取时的多次复制。  
数据从文件传输到套接字的常用数据路径：

操作系统从磁盘读取数据到内核空间的pagecache中  
应用程序从内核空间读取数据到用户空间缓冲区  
应用程序将数据写回内核空间到套接字缓冲区  
操作系统将数据从套接字缓冲区复制到 NIC 缓冲区，然后通过网络发送

4：**数据压缩**避免网络带宽瓶颈。Kafka 支持 GZIP、Snappy 和 LZ4 压缩协议

### 4.log日志详解 ###

Kafka中的日志（Log）是Kafka核心组件之一，它在Kafka中扮演着重要的角色，具有以下几个作用：

1.  持久化消息： Kafka的日志作为消息持久化的主要存储介质，将生产者发送的消息以追加写入的方式保存到磁盘上的主题日志文件中。每个主题都有一个或多个分区，每个分区的消息都按顺序追加到对应的日志文件中。这种方式可以确保消息被可靠地保存在磁盘上，即使在消息被消费之后仍然保留。
2.  实现高性能读写： 由于Kafka日志将消息追加到磁盘中的主题日志文件中，而不是逐条写入，这种追加写的方式使得Kafka能够实现高吞吐量的消息读写操作。同时，Kafka还利用顺序读写的特性，结合操作系统缓存和零拷贝技术，提升了IO性能，使得Kafka可以处理大规模的消息流。
3.  提供消息顺序性： Kafka保证了同一个分区内的消息顺序性。即在一个分区中，消息按生产的顺序进行追加，并且消费者从该分区读取消息时也会按照相同的顺序进行消费。这对于某些应用场景非常重要，比如日志处理和事件驱动系统。
4.  支持消息回溯： Kafka的日志文件是按顺序追加写入的，因此可以支持消息的回溯（Message Backward）操作。消费者可以在任何时间点消费指定偏移量之前的消息，这种特性对于数据重放、故障恢复和离线数据分析等非常有用。
5.  容错和复制： Kafka通过将每个分区的日志文件进行复制，实现了数据的冗余存储，提供了高可用性和容错性。每个分区的副本（replica）会被复制到多个Broker上，并保持同步。如果其中一个Broker发生故障，其他副本将继续提供服务。这种复制机制确保了数据不会因为单点故障而丢失，并且能够在副本之间实现负载均衡。

总之，Kafka的日志在持久化消息、实现高性能读写、提供消息顺序性、支持消息回溯以及实现容错和复制等方面起着关键作用。它是Kafka的核心组件之一，为构建高可靠、高吞吐量的分布式消息系统提供了基础。

### 5.kafka的选举机制 ###

当涉及到Kafka的选举机制时，我们需要从三个方面来了解：topics、broker和consumer group。

1.  Topics（主题）： 在Kafka中，topics是消息的逻辑分类。每个topic可以被分为多个分区，每个分区可以在不同的broker上进行复制以实现高可用性。对于一个特定的topic，Kafka通过选举机制选择一个leader broker来负责该topic的读写操作。选举的过程将确保只有一个broker成为leader，其他broker则作为followers。
2.  Broker（代理服务器）： Kafka集群由多个broker组成，每个broker负责维护一部分分区的数据。当一个broker被选举为topic的leader时，它负责处理该topic所有分区的读写请求。在Kafka中，专门有一个选举协议来确定leader的选举过程，这个协议被称为Controller选举。

Controller选举是ZooKeeper协调服务来完成的。ZooKeeper是Kafka用于协调和管理集群状态的分布式系统。当集群中原先的Controller节点失效或发生故障时，ZooKeeper会触发一次Controller选举。选举的过程是，每个broker都会尝试争取成为新的Controller，并通过与其他broker进行通信来达成共识。最终，一个broker会被选举为新的Controller节点，负责管理整个集群的状态和元数据信息。

1.  Consumer Group（消费者组）： Kafka允许多个消费者加入到同一个消费者组中，以实现消息的并行处理。在一个消费者组中，每个分区只能由组内的一个消费者进行消费，其他消费者只能处于空闲状态。当一个消费者离开或新的消费者加入时，Kafka通过选举机制来重新分配分区。

消费者组的选举机制是由GroupCoordinator来协调的。每个消费者组都有一个GroupCoordinator，它负责分配分区给消费者，并跟踪消费者的偏移量（offset）。当一个消费者离开或新的消费者加入时，GroupCoordinator将触发一次重新平衡（rebalance）操作。在重新平衡过程中，消费者组中的消费者会协商确定分区的分配情况，保证每个消费者只消费自己被分配到的分区。

总结：Kafka的选举机制涉及topics、broker和consumer group三个方面。在topics中，选举机制确保每个分区有一个leader和若干followers。在broker中，Controller选举确保集群中有一个负责管理整个集群状态和元数据的Controller节点。在consumer group中，GroupCoordinator负责重新平衡分区的分配情况，以实现消费者之间的负载均衡。这些选举机制的运行依赖于ZooKeeper提供的协调服务。

### 6.kafka怎么保证消息不丢失 ###

Kafka采用多种机制来确保消息不丢失：

1.  持久化： Kafka将消息持久化到磁盘上，以防止数据丢失。每个消息都被追加写入到文件系统中的主题日志（Topic Log）中。即使在消息被消费之后，它们仍然会保留在磁盘上，直到达到保留策略所指定的时间或大小限制。
2.  复制： Kafka通过复制机制提供高可用性和故障容错性。每个分区都有多个副本（replica），其中一个副本作为leader负责处理读写请求，其他副本作为followers同步leader的数据。如果leader副本发生故障，其中一个follower副本会被选举为新的leader继续提供服务。这样可以确保即使某个副本发生故障，仍然可以从其他副本中获取消息。
3.  批量发送： Kafka支持批量发送消息，这意味着生产者可以将一批消息打包发送到Kafka代理服务器，而不是逐条发送。批量发送可以降低网络开销和增加吞吐量，同时减少了传输中的延迟，从而减少了消息丢失的可能性。
4.  同步复制和异步复制： Kafka提供了两种复制模式：同步复制和异步复制。在同步复制模式下，生产者会等待所有副本成功写入消息，然后才返回提交确认（acknowledgement）。这样可以确保消息被可靠地复制到多个副本中，但会增加延迟。在异步复制模式下，生产者无需等待所有副本的写入确认，而是立即返回提交确认。这种方式可以降低延迟，但也增加了一定的消息丢失风险。
5.  副本监控和健康检查： Kafka提供了副本监控和健康检查机制。每个副本都会定期向Controller节点报告自己的状态，包括复制进度、健康状态等。Controller节点会监控副本的状态，并在发现异常情况时采取相应的措施，例如选择新的leader或重新平衡分区。

综上所述，通过持久化、复制、批量发送、复制模式、副本监控和健康检查等机制，Kafka能够高效地确保消息不丢失，并提供高可用性和故障容错性的特性。然而，在特殊情况下（例如硬件故障或网络中断），仍然存在极小的消息丢失可能性。因此，在设计应用程序时，需要根据具体需求来选择合适的配置和策略，以最大程度地减少消息丢失的风险。

### 7.kafka的3种消息传递语义acks ###

Kafka提供了三种不同的消息传递语义，其中acks参数用于指定生产者收到确认的副本数量。以下是这三种消息传递语义以及对应的acks参数解释：

1.  At most once（至多一次）： 当acks设置为0时，生产者不会等待任何来自服务器的确认，并认为消息已经成功发送。这种传递语义下，可能会出现消息丢失的情况，因为生产者不会收到任何确认，也不会尝试重试发送。
2.  At least once（至少一次）： 当acks设置为1时，生产者会等待服务器的确认，只要至少一个副本成功接收到消息，生产者就会收到确认。如果生产者在等待确认过程中发生故障或超时，它将会重试发送消息，确保消息至少被传递一次。由于可能存在重试，所以在这种语义下可能会出现重复消息的情况。
3.  Exactly once（恰好一次）： 当acks设置为all（或-1）时，生产者会等待所有副本都成功接收到消息并进行确认。这种传递语义下，可以确保消息仅被传递一次，不会出现丢失或重复的情况。实现恰好一次的传递语义需要结合Kafka的事务功能以及正确的客户端配置。

根据应用的需求，可以选择适合的消息传递语义。至多一次的语义适用于一些无需保证消息可靠性和顺序的场景，而至少一次和恰好一次的语义则适用于对消息可靠性和顺序有严格要求的场景。

[9c9860f7074542f7b6db7875b2704ec2.png]: https://img-blog.csdnimg.cn/9c9860f7074542f7b6db7875b2704ec2.png