Kafka学习笔记

番茄ligang
189 阅读17分钟

环境说明

  • Kafka版本：2.8.0
  • Scala版本：2.13
  • Zookeeper版本：3.7
  • SpringBoot.2.5 + Maven + IDEA旗舰版 + JDK8 或 JDK11

介绍什么是MQ消息中间件和应用场景

  • 什么是MQ消息中间件

    • 全称MessageQueue，主要是用于程序和程序直接通信，异步+解耦

  • 使用场景：

    • 核心应用

      • 解耦：订单系统-》物流系统
      • 异步：用户注册-》发送邮件，初始化信息
      • 削峰：秒杀、日志处理

    • 跨平台 、多语言

    • 分布式事务、最终一致性

    • RPC调用上下游对接，数据源变动->通知下属

image.png

image.png

JMS消息服务和和常见核心概念介绍

简介：讲解什么是AMQP和JMS消息服务

  • 什么是JMS: Java消息服务（Java Message Service),Java平台中关于面向消息中间件的接口

    • JMS是一种与厂商无关的 API，用来访问消息收发系统消息，它类似于JDBC(Java Database Connectivity)。这里，JDBC 是可以用来访问许多不同关系数据库的 API
    • 是由Sun公司早期提出的消息标准，旨在为java应用提供统一的消息操作，包括create、send、receive
    • JMS是针对java的，那微软开发了NMS（.NET消息传递服务）

image-20210107150715725

  • 特性

    • 面向Java平台的标准消息传递API
    • 在Java或JVM语言比如Scala、Groovy中具有互用性
    • 无需担心底层协议
    • 有queues和topics两种消息传递模型
    • 支持事务、能够定义消息格式（消息头、属性和内容）

  • 常见概念

    • JMS提供者：连接面向消息中间件的，JMS接口的一个实现，RocketMQ,ActiveMQ,Kafka等等
    • JMS生产者(Message Producer)：生产消息的服务
    • JMS消费者(Message Consumer)：消费消息的服务
    • JMS消息：数据对象
    • JMS队列：存储待消费消息的区域
    • JMS主题：一种支持发送消息给多个订阅者的机制
    • JMS消息通常有两种类型：点对点（Point-to-Point)、发布/订阅（Publish/Subscribe）

  • 基础编程模型

    • MQ中需要用的一些类
    • ConnectionFactory ：连接工厂，JMS 用它创建连接
    • Connection ：JMS 客户端到JMS Provider 的连接
    • Session： 一个发送或接收消息的线程
    • Destination ：消息的目的地;消息发送给谁.
    • MessageConsumer / MessageProducer： 消息消费者，消息生产者

介绍什么是AMQP高级消息队列协议和MQTT科普

  • 背景

    • JMS或者NMS都没有标准的底层协议，API是与编程语言绑定的，每个消息队列厂商就存在多种不同格式规范的产品，对使用者就产生了很多问题, AMQP解决了这个问题，它使用了一套标准的底层协议

  • 什么是AMQP

    • AMQP（advanced message queuing protocol）在2003年时被提出，最早用于解决金融领不同平台之间的消息传递交互问题,就是是一种协议，兼容JMS
    • 更准确说的链接协议 binary- wire-level-protocol 直接定义网络交换的数据格式，类似http
    • 具体的产品实现比较多，RabbitMQ就是其中一种

image.png

  • AMQP和JMS的主要区别

    • AMQP不从API层进行限定，直接定义网络交换的数据格式,这使得实现了AMQP的provider天然性就是跨平台
    • 比如Java语言产生的消息，可以用其他语言比如python的进行消费
    • AQMP可以用http来进行类比，不关心实现接口的语言，只要都按照相应的数据格式去发送报文请求，不同语言的client可以和不同语言的server进行通讯
    • JMS消息类型：TextMessage/ObjectMessage/StreamMessage等
    • AMQP消息类型：Byte[]

  • 核心概念

    • Broker

      • Kafka的服务端程序，可以认为一个mq节点就是一个broker
      • broker存储topic的数据

    • Producer生产者

      • 创建消息Message，然后发布到MQ中
      • 该角色将消息发布到Kafka的topic中

    • Consumer消费者:

      • 消费队列里面的消息

       

    • ConsumerGroup消费者组

    • 同个topic, 广播发送给不同的group，一个group中只有一个consumer可以消费此消息

       

    • Topic

    • 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic，主题的意思

       

    • Partition分区

      • kafka数据存储的基本单元，topic中的数据分割为一个或多个partition，每个topic至少有一个partition，是有序的
      • 一个Topic的多个partitions, 被分布在kafka集群中的多个server上
      • 消费者数量 <=小于或者等于Partition数量

       

    • Replication 副本（备胎）

      • 同个Partition会有多个副本replication ，多个副本的数据是一样的，当其他broker挂掉后，系统可以主动用副本提供服务
      • 默认每个topic的副本都是1（默认是没有副本，节省资源），也可以在创建topic的时候指定
      • 如果当前kafka集群只有3个broker节点，则replication-factor最大就是3了，如果创建副本为4，则会报错

       

    • ReplicationLeader、ReplicationFollower

      • Partition有多个副本，但只有一个replicationLeader负责该Partition和生产者消费者交互
      • ReplicationFollower只是做一个备份，从replicationLeader进行同步

       

    • ReplicationManager

      • 负责Broker所有分区副本信息，Replication 副本状态切换

    • offset

      • 每个consumer实例需要为他消费的partition维护一个记录自己消费到哪里的偏移offset
      • kafka把offset保存在消费端的消费者组里

     

     

Untitled Diagram

  • 特点总结

    • 多订阅者

      • 一个topic可以有一个或者多个订阅者
      • 每个订阅者都要有一个partition，所以订阅者数量要少于等于partition数量

    • 高吞吐量、低延迟: 每秒可以处理几十万条消息

    • 高并发：几千个客户端同时读写

    • 容错性：多副本、多分区，允许集群中节点失败，如果副本数据量为n,则可以n-1个节点失败

    • 扩展性强：支持热扩展

 

 

  • 基于消费者组可以实现：

    • 基于队列的模型：所有消费者都在同一消费者组里，每条消息只会被一个消费者处理
    • 基于发布订阅模型：消费者属于不同的消费者组，假如每个消费者都有自己的消费者组，这样kafka消息就能广播到所有消费者实例上

Kafka数据存储流程、原理、LEO+HW讲解

  • Partition

    • topic物理上的分组，一个topic可以分为多个partition，每个partition是一个有序的队列

    • 是以文件夹的形式存储在具体Broker本机上

      image-20210427181035021

  • LEO（LogEndOffset）

    • 表示每个partition的log最后一条Message的位置。

       

  • HW（HighWatermark）

    • 表示partition各个replicas数据间同步且一致的offset位置，即表示allreplicas已经commit的位置
    • HW之前的数据才是Commit后的，对消费者才可见
    • ISR集合里面最小leo

image-20210427214131614

  • offset：

    • 每个partition都由一系列有序的、不可变的消息组成，这些消息被连续的追加到partition中
    • partition中的每个消息都有一个连续的序列号叫做offset，用于partition唯一标识一条消息
    • 可以认为offset是partition中Message的id

 

  • Segment：每个partition又由多个segment file组成；

    • segment file 由2部分组成，分别为index file和data file（log file），
    • 两个文件是一一对应的，后缀”.index”和”.log”分别表示索引文件和数据文件
    • 命名规则：partition的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset+1

 

  • Kafka高效文件存储设计特点：

    • Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。
    • 通过索引信息可以快速定位message
    • producer生产数据，要写入到log文件中，写的过程中一直追加到文件末尾，为顺序写，官网数据表明。同样的磁盘，顺序写能到600M/S，而随机写只有100K/S

Kafka核心API模块-producer API讲解实战

  • 封装配置属性
public static Properties getProperties(){
        Properties props = new Properties();
​
        props.put("bootstrap.servers", "112.74.55.160:9092");
        //props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "112.74.55.160:9092");
​
        // 当producer向leader发送数据时，可以通过request.required.acks参数来设置数据可靠性的级别,分别是0, 1，all。
        props.put("acks", "all");
        //props.put(ProducerConfig.ACKS_CONFIG, "all");
​
        // 请求失败，生产者会自动重试，指定是0次，如果启用重试，则会有重复消息的可能性
        props.put("retries", 0);
        //props.put(ProducerConfig.RETRIES_CONFIG, 0);
​
​
        // 生产者缓存每个分区未发送的消息,缓存的大小是通过 batch.size 配置指定的，默认值是16KB
        props.put("batch.size", 16384);
​
​
        /**
         * 默认值就是0，消息是立刻发送的，即便batch.size缓冲空间还没有满
         * 如果想减少请求的数量，可以设置 linger.ms 大于0，即消息在缓冲区保留的时间，超过设置的值就会被提交到          服务端
         * 通俗解释是，本该早就发出去的消息被迫至少等待了linger.ms时间，相对于这时间内积累了更多消息，批量发送           减少请求
         * 如果batch被填满或者linger.ms达到上限，满足其中一个就会被发送
         */
        props.put("linger.ms", 1);
​
        /**
         * buffer.memory的用来约束Kafka Producer能够使用的内存缓冲的大小的，默认值32MB。
         * 如果buffer.memory设置的太小，可能导致消息快速的写入内存缓冲里，但Sender线程来不及把消息发送到             Kafka服务器
         * 会造成内存缓冲很快就被写满，而一旦被写满，就会阻塞用户线程，不让继续往Kafka写消息了
         * buffer.memory要大于batch.size，否则会报申请内存不#足的错误，不要超过物理内存，根据实际情况调整
         * 需要结合实际业务情况压测进行配置
         */
        props.put("buffer.memory", 33554432);
​
​
        /**
         * key的序列化器，将用户提供的 key和value对象ProducerRecord 进行序列化处理，key.serializer必须被          设置，
         * 即使消息中没有指定key，序列化器必须是一个实
          org.apache.kafka.common.serialization.Serializer接口的类，
         * 将key序列化成字节数组。
         */
        props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        props.put("value.serializer","org.apache.kafka.common.serialization.StringSerializer");
​
        return props;
    }
  • 生产者投递消息API实战（同步发送）
   /**
     * send()方法是异步的，添加消息到缓冲区等待发送，并立即返回
     * 生产者将单个的消息批量在一起发送来提高效率,即 batch.size和linger.ms结合
     *
     * 实现同步发送：一条消息发送之后，会阻塞当前线程，直至返回 ack
     * 发送消息后返回的一个 Future 对象，调用get即可
     *
     * 消息发送主要是两个线程：一个是Main用户主线程，一个是Sender线程
     *  1)main线程发送消息到RecordAccumulator即返回
     *  2)sender线程从RecordAccumulator拉取信息发送到broker
     *  3) batch.size和linger.ms两个参数可以影响 sender 线程发送次数
     *
     *
     */
    @Test
    public void testSend(){
​
        Properties props = getProperties();
        Producer<String, String> producer = new KafkaProducer<>(props);
        for (int i = 1; i < 3; i++){
            Future<RecordMetadata>  future = producer.send(new ProducerRecord<>("my-topic", "xdclass-key"+i, "xdclass-value"+i));
            try {
                RecordMetadata recordMetadata = future.get();//不关心是否发送成功，则不需要这行
                System.out.println("发送状态："+recordMetadata.toString());
​
            } catch (InterruptedException e) {
                e.printStackTrace();
            } catch (ExecutionException e) {
                e.printStackTrace();
            }
            System.out.println(i+"发送："+LocalDateTime.now().toString());
        }
        producer.close();
    }

ProducerRecord介绍和key的作用

  • ProducerRecord（简称PR）

    • 发送给Kafka Broker的key/value 值对, 封装基础数据信息
    -- Topic （名字）
-- PartitionID (可选)
-- Key(可选)
-- Value

image-20210504114907360

image-20210504114837228

 

  • key默认是null，大多数应用程序会用到key

    • 如果key为空，kafka使用默认的partitioner，使用RoundRobin算法将消息均衡地分布在各个partition上
    • 如果key不为空，kafka使用自己实现的hash方法对key进行散列，决定消息该被写到Topic的哪个partition，拥有相同key的消息会被写到同一个partition，实现顺序消息

Kafka核心API模块-producerAPI回调函数实战

  • 生产者发送消息是异步调用，怎么知道是否有异常？

    • 发送消息配置回调函数即可， 该回调方法会在 Producer 收到 ack 时被调用，为异步调用
    • 回调函数有两个参数 RecordMetadata 和 Exception，如果 Exception 是 null，则消息发送成功，否则失败

  • 异步发送配置回调函数

    @Test
    public void testSendWithCallback(){
​
        Properties props = getProperties();
        Producer<String, String> producer = new KafkaProducer<>(props);
        for (int i = 1; i < 3; i++){
            producer.send(new ProducerRecord<>("my-topic", "xdclass-key" + i, "xdclass-value" + i), new Callback() {
                @Override
                public void onCompletion(RecordMetadata metadata, Exception exception) {
                    if (exception == null) {
                        System.out.println("发送状态："+metadata.toString());
                    } else {
                        exception.printStackTrace();
                    }
                }
            });
​
            System.out.println(i+"发送："+LocalDateTime.now().toString());
        }
        producer.close();
    }
​

Consumer消费者机制和分区策略讲解《上》

简介： Kafka的Consumer消费者机制和分区策略讲解

  • 思路：从面试题角度去讲解原理流程，大家更好接收

  • 消费者根据什么模式从broker获取数据的？

    • 为什么是pull模式，而不是broker主动push？

      • 消费者采用 pull 拉取方式，从broker的partition获取数据

      • pull 模式则可以根据 consumer 的消费能力进行自己调整，不同的消费者性能不一样

        • 如果broker没有数据，consumer可以配置 timeout 时间，阻塞等待一段时间之后再返回

      • 如果是broker主动push，优点是可以快速处理消息，但是容易造成消费者处理不过来，消息堆积和延迟。

  • 消费者从哪个分区进行消费？

    • 一个 topic 有多个 partition，一个消费者组里面有多个消费者，那是怎么分配过

      • 一个主题topic可以有多个消费者，因为里面有多个partition分区 ( leader分区)
      • 一个partition leader可以由一个消费者组中的一个消费者进行消费
      • 一个 topic 有多个 partition，所以有多个partition leader，给多个消费者消费，那分配策略如何？

消费者从哪个分区进行消费？两个策略

  • 顶层接口
org.apache.kafka.clients.consumer.internals.AbstractPartitionAssignor

  • round-robin （RoundRobinAssignor非默认策略）轮训

    • 【按照消费者组】进行轮训分配，同个消费者组监听不同主题也一样，是把所有的 partition 和所有的 consumer 都列出来， 所以消费者组里面订阅的主题是一样的才行，主题不一样则会出现分配不均问题，例如7个分区，同组内2个消费者

    • topic-p0/topic-p1/topic-p2/topic-p3/topic-p4/topic-p5/topic-p6

    • c-1: topic-p0/topic-p2/topic-p4/topic-p6

    • c-2:topic-p1/topic-p3/topic-p5

    • 弊端

      • 如果同一消费者组内，所订阅的消息是不相同的，在执行分区分配的时候不是轮询分配，可能会导致分区分配的不均匀
      • 有3个消费者C0、C1和C2，他们共订阅了 3 个主题：t0、t1 和 t2
      • t0有1个分区(p0)，t1有2个分区(p0、p1)，t2有3个分区(p0、p1、p2))
      • 消费者C0订阅的是主题t0，消费者C1订阅的是主题t0和t1，消费者C2订阅的是主题t0、t1和t2

image.png

  • range （RangeAssignor默认策略）范围

    • 【按照主题】进行分配，如果不平均分配，则第一个消费者会分配比较多分区， 一个消费者监听不同主题也不影响，例如7个分区，同组内2个消费者

    • topic-p0/topic-p1/topic-p2/topic-p3/topic-p4/topic-p5//topic-p6

    • c-1: topic-p0/topic-p1/topic-p2/topic-p3

    • c-2:topic-p4/topic-p5/topic-p6

    • 弊端

      • 只是针对 1 个 topic 而言，c-1多消费一个分区影响不大
      • 如果有 N 多个 topic，那么针对每个 topic，消费者 C-1 都将多消费 1 个分区，topic越多则消费的分区也越多，则性能有所下降

Consumer消费者重新分配策略和offset维护机制

  • 什么是Rebalance操作

    • kafka 怎么均匀地分配某个 topic 下的所有 partition 到各个消费者，从而使得消息的消费速度达到最快，这就是平衡（balance），前面讲了 Range 范围分区 和 RoundRobin 轮询分区，也支持自定义分区策略。

    • 而 rebalance（重平衡）其实就是重新进行 partition 的分配，从而使得 partition 的分配重新达到平衡状态

       

     

  • 面试

    • 例如70个分区，10个消费者，但是先启动一个消费者，后续再启动一个消费者，这个会怎么分配？

      • Kafka 会进行一次分区分配操作，即 Kafka 消费者端的 Rebalance 操作 ，下面都会发生rebalance操作

        • 当消费者组内的消费者数量发生变化（增加或者减少），就会产生重新分配patition
        • 分区数量发生变化时(即 topic 的分区数量发生变化时)

 

  • 面试：当消费者在消费过程突然宕机了，重新恢复后是从哪里消费，会有什么问题？

    • 消费者会记录offset，故障恢复后从这里继续消费，这个offset记录在哪里？

    • 记录在zk里面和本地，新版默认将offset保证在kafka的内置topic中，名称是 __consumer_offsets

      • 该Topic默认有50个Partition，每个Partition有3个副本，分区数量由参数offset.topic.num.partition配置
      • 通过groupId的哈希值和该参数取模的方式来确定某个消费者组已消费的offset保存到__consumer_offsets主题的哪个分区中
      • 由 消费者组名+主题+分区，确定唯一的offset的key，从而获取对应的值
      • 三元组：group.id+topic+分区号，而 value 就是 offset 的值

Kafka数据存储流程和log日志讲解

  • Kafka 采取了分片和索引机制，将每个partition分为多个segment，每个segment对应2个文件 log 和 index
  • 新增备注
index文件中并没有为每一条message建立索引，采用了稀疏存储的方式
每隔一定字节的数据建立一条索引，避免了索引文件占用过多的空间和资源，从而可以将索引文件保留到内存中
缺点是没有建立索引的数据在查询的过程中需要小范围内的顺序扫描操作。

 

image-20210428190212421

  • 配置文件 server.properties
# The maximum size of a log segment file. When this size is reached a new log segment will be created. 默认是1G,当log数据文件大于1g后，会创建一个新的log文件（即segment，包括index和log）
log.segment.bytes=1073741824

image-20210427200839940

  • 例子
#分段一
00000000000000000000.index  00000000000000000000.log
#分段二 数字 1234指的是当前文件的最小偏移量offset，即上个文件的最后一个消息的offset+1
00000000000000001234.index  00000000000000001234.log
#分段三
00000000000000088888.index  00000000000000088888.log

Kafka数据可靠性保证原理之副本机制Replica介绍《上》

  • 背景

    • Kafka之间副本数据同步是怎样的？一致性怎么保证，数据怎样保证不丢失呢

     

  • kafka的副本（replica）

    • topic可以设置有N个副本, 副本数最好要小于broker的数量
    • 每个分区有1个leader和0到多个follower，我们把多个replica分为Learder replica和follower replica

image-20210427205840695

  • 生产者发送数据流程

    • 保证producer 发送到指定的 topic， topic 的每个 partition 收到producer 发送的数据后
    • 需要向 producer 发送 ack 确认收到，如果producer 收到 ack， 就会进行下一轮的发送否则重新发送数据

     

  • 副本数据同步机制

    • 当producer在向partition中写数据时，根据ack机制，默认ack=1，只会向leader中写入数据
    • 然后leader中的数据会复制到其他的replica中，follower会周期性的从leader中pull数据，
    • 对于数据的读写操作都在leader replica中，follower副本只是当leader副本挂了后才重新选取leader，，，，follower并不向外提供服务，假如还没同步完成，leader副本就宕机了，怎么办？

Kafka数据可靠性保证原理之副本机制Replica介绍《下》

  • 问题点：Partition什么时间发送ack确认机制（要追求高吞吐量，那么就要放弃可靠性）

     

    • 当producer向leader发送数据时，可以通过request.required.acks参数来设置数据可靠性的级别

       

    • 副本数据同步策略 , ack有3个可选值，分别是0, 1，all。

      • ack=0

        • producer发送一次就不再发送了，不管是否发送成功
        • 发送出去的消息还在半路，或者还没写入磁盘， Partition Leader所在Broker就直接挂了，客户端认为消息发送成功了，此时就会导致这条消息就丢失

         

      • ack=1(默认)

        • 只要Partition Leader接收到消息而且写入【本地磁盘】，就认为成功了，不管他其他的Follower有没有同步过去这条消息了
        • 问题：万一Partition Leader刚刚接收到消息，Follower还没来得及同步过去，结果Leader所在的broker宕机了

         

      • ack= all（即-1）

        • producer只有收到分区内所有副本的成功写入全部落盘的通知才认为推送消息成功

         

        • 备注：leader会维持一个与其保持同步的replica集合，该集合就是ISR，leader副本也在isr里面

        • 问题一：如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复

          • 数据发送到leader后 ，部分ISR的副本同步，leader此时挂掉。比如follower1和follower2都有可能变成新的leader, producer端会得到返回异常，producer端会重新发送数据，数据可能会重复

           

        • 问题二：acks=all 就可以代表数据一定不会丢失了吗

          • Partition只有一个副本，也就是一个Leader，任何Follower都没有
          • 接收完消息后宕机，也会导致数据丢失，acks=all，必须跟ISR列表里至少有2个以上的副本配合使用
          • 在设置request.required.acks=-1的同时，也要min.insync.replicas这个参数设定 ISR中的最小副本数是多少，默认值为1，改为 >=2，如果ISR中的副本数少于min.insync.replicas配置的数量时，客户端会返回异常

Kafka数据可靠性保证原理之ISR机制讲解

  • 什么是ISR (in-sync replica set )

    • leader会维持一个与其保持同步的replica集合，该集合就是ISR，每一个leader partition都有一个ISR，leader动态维护, 要保证kafka不丢失message，就要保证ISR这组集合存活（至少有一个存活），并且消息commit成功
    • Partition leader 保持同步的 Partition Follower 集合, 当 ISR 中的Partition Follower 完成数据的同步之后，就会给 leader 发送 ack
    • 如果Partition follower长时间(replica.lag.time.max.ms) 未向leader同步数据，则该Partition Follower将被踢出ISR
    • Partition Leader 发生故障之后，就会从 ISR 中选举新的 Partition Leader。

  • OSR （out-of-sync-replica set）

  • 与leader副本分区 同步滞后过多的副本集合

  • AR（Assign Replicas）

  • 分区中所有副本统称为AR

Kafka的中的日志数据清理你知道多少

  • Kafka将数据持久化到了硬盘上，为了控制磁盘容量，需要对过去的消息进行清理

  • 问题：如果让你去设计这个日志删除策略，你会怎么设计？【原理思想】很重要的体现，下面是kafka答案

    • 内部有个定时任务检测删除日志，默认是5分钟 log.retention.check.interval.ms
    • 支持配置策略对数据清理
    • 根据segment单位进行定期清理

  • 启用cleaner

    • log.cleaner.enable=true
    • log.cleaner.threads = 2 (清理线程数配置)

  • 日志删除

    • log.cleanup.policy=delete
    #清理超过指定时间的消息,默认是168小时，7天，
#还有log.retention.ms, log.retention.minutes, log.retention.hours，优先级高到低
log.retention.hours=168
​
#超过指定大小后，删除旧的消息，下面是1G的字节数，-1就是没限制
log.retention.bytes=1073741824
​
还有基于日志起始位移（log start offset)，未来社区还有更多
    • 基于【时间删除】 日志说明
    配置了7天后删除，那7天如何确定呢？
​
每个日志段文件都维护一个最大时间戳字段，每次日志段写入新的消息时，都会更新该字段
​
一个日志段segment写满了被切分之后，就不再接收任何新的消息，最大时间戳字段的值也将保持不变
​
kafka通过将当前时间与该最大时间戳字段进行比较，从而来判定是否过期
    • 基于【大小超过阈值】 删除日志 说明
    假设日志段大小是500MB，当前分区共有4个日志段文件，大小分别是500MB，500MB，500MB和10MB
​
10MB那个文件就是active日志段。
​
此时该分区总的日志大小是3*500MB+10MB=1500MB+10MB
​
如果阈值设置为1500MB，那么超出阈值的部分就是10MB，小于日志段大小500MB，故Kafka不会执行任何删除操作，即使总大小已经超过了阈值；
​
如果阈值设置为1000MB，那么超过阈值的部分就是500MB+10MB > 500MB，此时Kafka会删除最老的那个日志段文件
​
注意：超过阈值的部分必须要大于一个日志段的大小
    • log.retention.bytes和log.retention.minutes任意一个达到要求，都会执行删除

  • 日志压缩

    • log.cleanup.policy=compact 启用压缩策略
    • 按照消息key进行整理，有相同key不同value值，只保留最后一个

Kafka的高性能原理分析归纳ZeroCopy

  • 零拷贝ZeroCopy（SendFile）

    • 例子：将一个File读取并发送出去（Linux有两个上下文，内核态，用户态）

      • File文件的经历了4次copy

        • 调用read,将文件拷贝到了kernel内核态
        • CPU控制 kernel态的数据copy到用户态
        • 调用write时，user态下的内容会copy到内核态的socket的buffer中
        • 最后将内核态socket buffer的数据copy到网卡设备中传送

      • 缺点：增加了上下文切换、浪费了2次无效拷贝(即步骤2和3)

      image-20210509180416238

    • ZeroCopy：

      • 请求kernel直接把disk的data传输给socket，而不是通过应用程序传输。Zero copy大大提高了应用程序的性能，减少不必要的内核缓冲区跟用户缓冲区间的拷贝，从而减少CPU的开销和减少了kernel和user模式的上下文切换，达到性能的提升

      • 对应零拷贝技术有mmap及sendfile

        • mmap:小文件传输快
        • sendfile:大文件传输比mmap快

         

      • 应用：Kafka、Netty、RocketMQ等都采用了零拷贝技术

avatar
文章
阅读
粉丝