欢迎光临
Kafka常见问题解析
   

Kafka常见问题解析

文章目录

  • 1. kafka为什么不支持读写分离?这样做的优点有哪些?
  • 2. Kafka可靠性研究
    • 2.1生产者
    • 2.2 服务端
    • 2.3 消费者
    • 3. Kafka零拷贝原理
    • 4. Kafka生产者发送消息流程

      1. kafka为什么不支持读写分离?这样做的优点有哪些?

      Kafka 不直接支持主写从读(Master-Slave)模式的原因是,Kafka 的设计目标是提供高吞吐量和低延迟的分布式消息传递系统,而不是传统的主从复制数据库系统。

      以下是一些原因解释为什么 Kafka 不支持主写从读模式:

        1. 数据一致性:Kafka 保证副本之间的数据一致性,而不是强一致性。主写从读模式通常要求强一致性,即主节点写入的数据必须立即同步到所有从节点。这样的强一致性要求会对性能和可用性产生负面影响,与 Kafka 的设计目标不符。
        1. 读扩展性:Kafka 的设计重点是提供高吞吐量的读取能力。通过允许消费者直接从副本读取数据,Kafka 可以水平扩展读取操作,从而实现更高的吞吐量。如果支持主写从读模式,读取将受到主节点的限制,并且无法获得与 Kafka 的分布式读取能力相媲美的性能。
        1. 失效容错性:Kafka 的设计考虑了节点故障的情况。副本可以接管主节点的角色,从而确保数据的可用性和持久性。如果支持主写从读模式,可能会引入更复杂的故障处理和故障转移机制,增加系统的复杂性和维护成本。

        Kafka 只支持主写 主读有几个优点 :

          1. 可以简化代码的 实现逻辑,减少出错的可能;
          1. 将负载粒度细化均摊,与主写从读相比,不仅负载效能更好,而 且对用户可控;
          1. 没有延时的 影 响;
          1. 在副本稳定的情况下,不会出现数据不一致的情况。

          2. Kafka可靠性研究

          2.1生产者

          消息确认机制:Kafka 提供了消息的生产者确认机制,确保消息已经被成功写入到 Kafka 中。生产者可以选择同步等待消息的确认,或者异步发送消息。同步方式可以确保消息写入的可靠性,但会引入一定的延迟,而异步方式则可以提供更高的吞吐量。

          ACKS参数的值有三种,0,1,-1:

          • 0:生产者发送消息后不需要等待来自 Kafka 代理的确认。这意味着生产者不会知道消息是否成功发送到 Kafka,也无法感知到消息发送失败的情况。这是最低延迟的设置,但也是最不可靠的设置,因为消息可能会丢失。
          • 1: 生产者在将消息写入 Kafka 分区的 leader 副本后会收到来自 leader 副本的确认。这意味着至少有一个副本成功接收到消息。对于单个副本的故障而言,消息可能会丢失。
          • -1:生产者在将消息写入 Kafka 分区的所有副本后才会收到来自所有副本的确认。这是最安全的设置,因为只有在所有副本都成功接收到消息后,生产者才会认为消息发送成功。这种设置提供了最高的可靠性保证,但也需要更多的时间和资源。

            2.2 服务端

              1. 持久性:Kafka 使用日志(log)的方式来存储消息,使得消息可以持久化保存在磁盘上。这意味着即使在消息被消费之后,它们仍然可以在 Kafka 中保留,并且可以根据需要重新消费。
              1. 复制机制:Kafka 支持将消息复制到多个副本(replica)中。副本分布在不同的节点上,可以提供数据的冗余和高可用性。如果某个节点故障,可以从其他副本中获取数据,确保数据的可靠性和持久性。
              1. ISR(In-Sync Replicas)机制:Kafka 使用 ISR 机制来确保数据的可靠性。ISR 是与主副本(leader replica)保持同步的副本集合。只有 ISR 中的副本才能被认为是可靠的,并且可以被消费者读取。如果一个副本与主副本的同步延迟超过一定阈值,它将被移出 ISR,直到追赶上主副本的进度。
              1. 故障转移:Kafka 具有故障转移机制,可以在节点故障时自动进行副本的重新分配和重新平衡。当节点故障时,Kafka 可以将副本的角色切换到其他可用节点上,从而确保数据的可用性和持久性。

              2.3 消费者

              手动位移提交。

              3. Kafka零拷贝原理

              Kafka 使用零拷贝(Zero-copy)技术来提高性能和减少数据传输的开销。零拷贝是一种技术,使数据从一个应用程序传输到另一个应用程序时,避免了数据的多次复制,从而减少了 CPU 的开销和内存带宽的消耗。

              下面是 Kafka 实现零拷贝的原理:

                1. 文件发送:Kafka 使用文件系统进行消息的存储,每个分区都有一个或多个日志段(log segment)文件。当消息被写入 Kafka 时,它们首先被追加到日志段文件的末尾。
                1. 零拷贝技术:Kafka 使用 Java NIO(New I/O)库中的 FileChannel 和 ByteBuffer 类来实现零拷贝。当消息被写入日志段文件时,Kafka 生产者使用 FileChannel 来将数据从内存缓冲区(例如 ByteBuffer)直接写入文件系统,而无需通过用户空间和内核空间之间的数据拷贝。
                1. 内核空间和用户空间:传统的数据传输方式涉及将数据从用户空间复制到内核空间,然后再从内核空间复制到网络套接字进行传输。而采用零拷贝技术后,数据可以直接从用户空间传输到网络套接字,避免了额外的数据复制。
                1. DMA(Direct Memory Access):通过使用 DMA,Kafka 生产者可以绕过 CPU,直接将数据从内存缓冲区传输到网络适配器,从而进一步减少 CPU 的介入和数据复制的开销。

                  通过使用零拷贝技术,Kafka 可以在消息传输过程中减少数据的复制次数,提高了性能和吞吐量,并降低了资源消耗。这对于高性能的消息传递系统非常重要,特别是在需要处理大量数据和高并发的情况下。

                传统的文件读写或者网络传输,通常需要将数据从内核态转换为用户态。应用程序读取用户态内存数据,写入文件 / Socket之前,需要从用户态转换为内核态之后才可以写入文件或者网卡当中。我们可以称之为read/write模式,此模式的步骤为:

                • 首先,调用read时,磁盘文件拷贝到了内核态;
                • 之后,CPU控制将内核态数据copy到用户态下;
                • 调用write时,先将用户态下的内容copy到内核态下的socket的buffer中;
                • 最后将内核态下的socket buffer的数据copy到网卡设备中传送;

                  Kafka常见问题解析,在这里插入图片描述,第1张

                  零拷贝

                  Kafka常见问题解析,在这里插入图片描述,第2张

打赏
版权声明:本文采用知识共享 署名4.0国际许可协议 [BY-NC-SA] 进行授权
文章名称:《Kafka常见问题解析》
文章链接:https://goodmancom.com/wl/176026.html