kafka基础入门

最新推荐文章于 2024-03-27 17:30:13 发布

网世侠客

最新推荐文章于 2024-03-27 17:30:13 发布

阅读量204

点赞数

分类专栏：流式计算

本文链接：https://blog.csdn.net/qq_39273286/article/details/98785365

版权

流式计算专栏收录该内容

8 篇文章 0 订阅

订阅专栏

官方参考文档：http://kafka.apache.org/documentation/#introduction（翻译页面就行了）

kafka集群搭建：https://blog.csdn.net/zxy987872674/article/details/72466504

一基本介绍

1.1 做什么的

一个分布式的、可分区的、可复制的开源消息系统，构建在系统或应用之间的实时数据流管道、构建实时流应用程序用于转换和响应数据流。可以理解成快递员。（总的来说功能就是解耦，异步和并行）

用户注册

使用消息队列之后

1.2 有啥特点

分布式的消息队列

低延迟处理消息
可扩展，kafka集群支持热扩展
高吞吐量，承受大量积压。能进行持久化，采用内存磁盘相结合的存储方式。
多客户端支持，JAVA、C、PYTHON、Node.js等主流语言都支持。
可靠性：数据备份，副本机制，Follower副本只是从Leader副本上复制数据（多个副本时）
轻量级，Kafka代理是无状态的，代理不记录消息是否被消费，消费者偏移量的管理由消费者自己或者组协调器来维护（记录到zookeeper中），集群本身也不需要生产者和消费者的状态信息。
依赖于zookeeper集群保存一些meta（配置信息和数据处理情况）信息，来保证系统可用性。
不是基于JMS规范的实现，但是和JMS很相似，由Scala写成

补充：

什么是JMS

java消息系统（java提供的一套技术规范）

JMS用来做什么

异构系统集成通信，缓解系统瓶颈，提高系统的伸缩性增强系统用户体验，使得系统模块化和组件化变得可行并更加灵活

通信模式：生产者消费者模式（生产者---》服务器---》消费者）

JMS组件

Destination：消息发送的目的地，也就是前面说的Queue和Topic。
Message：从字面上就可以看出是被发送的消息。
MessageProducer：消息的生产者，要发送一个消息，必须通过这个生产者来发送。
MessageConsumer：消息的消费者或接收者，通过它来接收一个消息。

通信的两种形式

1.点对点（一对一，消费者主动拉取数据，消息收到后消息清除）:数据只有一份消费后就会被删除，但kafka的点对点可以被多个消费者消费

2.发布订阅模式（一对多，数据生产后，推送给所有订阅者）

1.3核心组件

Topic ：消息根据Topic进行归类
Producer：发送消息者
Consumer：消息接受者
broker：每个kafka实例(server)
Zookeeper：依赖集群保存meta信息（比如消费者编号和各个消费数据的情况）。
ConsumerGroup：数据消费者组，ConsumerGroup可以有多个，每个ConsumerGroup消费的数据都是一样的。
可以把多个consumer线程划分为一个组，组里面所有成员共同消费一个topic的数据，组员之间不能重复消费。

1.4 文件存储机制（重点）

partition：数据分片单位，

1.4.1 命名规则

topic名称+有序序号（从0开始）

1.4.2 分片规则

可以为topic创建多个partition，partition在集群中按照哈希取模的方式平均分配在broker中，分配算法（推测的分配方法，是利用哈希取模的算法，将生成的partition分配到存在的broker中），其中broker表示的是broker的数量。

为pamentMq的topic新建5个partition（实验环境拥有3个broker），各个kafka实例上的partition分配情况如下（实际验证）

但是在官方使用的说明图中一共有两个broker，是p0p3一组，p1p2一组，按照哈希取模的算法应该是p0和p2一组，p1和p3一组。

在创建分片信息的时候还可以设置副本数量，并且副本的数量一定和其原始数据分片在不同的broker中

1.4.3 数据存储方式

partion中存放数据两个地方，当内存达到一定的数据量就会被存储到磁盘中，在缓冲区的数据数量可以设置大小

一个partition目录中的数据分段存储在多个segment file中，这些文件会有一个存活期（默认7天，并且达到一定数量默认1G），当达到这个时间并有1G的segment file会被删除，达到时间但未达1G的数据量时，会把元素数据复制到一个新的segment file中，生命周期重新开始计算。（时间和数据量可以在配置文件中配置）每个segment对应至少两个文件，1个日志文件和1个索引文件，分别是.log文件，.index文件。

Segment文件命名规则：partion全局的第一个segment从0开始，后续每个segment文件名为上一个segment文件最后一条消息的offset值（相对偏移量）。数值最大为64位long大小，19位数字字符长度，没有数字用0填充，查找数据时使用二分查找，先确定分段文件，再去分段文件你不查找。

每个partiton只需要支持顺序读写

可以在创建partition数时设置指定数量的副本 ISR：Kafka在Zookeeper中动态维护一个ISR，也就是保存同步的副本列表，该列表中保存的是与Leader副本保持消息同步的所有副本对应的代理节点id。如果一个Follower宕机或者其落后太多，则该Follower副本节点将从ISR列表中移除。只要ISR列表中存在一个存活的副本那么已经提交的消息就不会丢失。

1.5其他相似系统的比较

分布式消息中间件 Metamorphosis

Metamorphosis (MetaQ) 是一个高性能、高可用、可扩展的分布式消息中间件，类似于LinkedIn的Kafka，具有消息存储顺序写、吞吐量大和支持本地和XA事务等特性，适用于大吞吐量、顺序消息、广播和日志数据传输等场景，在淘宝和支付宝有着广泛的应用，现已开源。

主要特点：

生产者、服务器和消费者都可分布
消息存储顺序写
性能极高,吞吐量大
支持消息顺序
支持本地和XA事务
客户端pull，随机读,利用sendfile系统调用，zero-copy ,批量拉数据
支持消费端事务
支持消息广播模式
支持异步发送消息
支持http协议
支持消息重试和recover
数据迁移、扩容对用户透明
消费状态保存在客户端
支持同步和异步复制两种HA
支持group commit

二应用场景

通常用来解耦、异步通信、流量控制，在流式计算中作为消息队列形成flume--》kafKa--》storm--》redis的流式计算框架

三环境搭建

3.1 安装

参考链接：https://blog.csdn.net/qq_39089301/article/details/81777997

3.2 配置文件红色标记需要改动的项

[root@centos1 config]# vi config/server.properties
broker.id=1 #当前机器在集群中的唯一标识，和zookeeper的myid性质一样。我们第一台写1，第二台2
port=19092 #当前kafka对外提供服务的端口默认是9092
host.name=192.168.25.121 #本机id，kafka的ip地址。
num.network.threads=3 #这个是borker进行网络处理的线程数
num.io.threads=8 #这个是borker进行I/O处理的线程数
log.dirs=/opt/kafka/kafkalogs/ #消息存放的目录，这个目录可以配置为“，”逗号分割的表达式，上面的num.io.threads要大于这个目录的个数这个目录，如果配置多个目录，新创建的topic他把消息持久化的地方是，当前以逗号分割的目录中，那个分区数最少就放那一个
socket.send.buffer.bytes=102400 #发送缓冲区buffer大小，数据不是一下子就发送的，先回存储到缓冲区了到达一定的大小后在发送，能提高性能
socket.receive.buffer.bytes=102400 #kafka接收缓冲区大小，当数据到达一定大小后在序列化到磁盘
socket.request.max.bytes=104857600 #这个参数是向kafka请求消息或者向kafka发送消息的请请求的最大数，这个值不能超过 java的堆栈大小
num.partitions=1 #默认的分区数，一个topic默认1个分区数
log.retention.hours=168 #默认消息的最大持久化时间，168小时，7天
message.max.byte=5242880 #消息保存的最大值5M
default.replication.factor=2 #kafka保存消息的副本数，如果一个副本失效了，另一个还可以继续提供服务
replica.fetch.max.bytes=5242880 #取消息的最大直接数
log.segment.bytes=1073741824 #这个参数是：因为kafka的消息是以追加的形式落地到文件，当超过这个值的时候，kafka会新起一个文件
log.retention.check.interval.ms=300000 #每隔300000毫秒去检查上面配置的log失效时间（log.retention.hours=168 ），到目录查看是否有过期的消息如果有，删除
log.cleaner.enable=false #是否启用log压缩，一般不用启用，启用的话可以提高性能
zookeeper.connect=192.168.25.121:12181,192.168.25.122:12181,192.168.25.123:12181 #设置zookeeper的集群ip

3.3 常用命令

查看当前服务器中的所有topic

bin/kafka-topics.sh --list --zookeeper zk地址:2181

创建topic

./kafka-topics.sh --create --zookeeper kafka地址:2181 --replication-factor 1 --partitions 3 --topic first

删除topic

sh bin/kafka-topics.sh --delete --zookeeper zk地址:2181 --topic test

需要server.properties中设置delete.topic.enable=true否则只是标记删除或者直接重启。

通过shell命令发送消息

kafka-console-producer.sh --broker-list kafka地址:9092 --topic itheima

通过shell消费消息

sh bin/kafka-console-consumer.sh --zookeeper zk地址:2181 --from-beginning --topic test1

查看消费位置

sh kafka-run-class.sh kafka.tools.ConsumerOffsetChecker --zookeeper zk地址:2181 --group testGroup

查看某个Topic的详情

sh kafka-topics.sh --topic test --describe --zookeeper zk地址:2181

四使用实例

4.1 生产者

代码中的ip地址均改成了kafka01等序号，在实际应用过程中使用ip地址，这里本地更改了host文件

4.2 消费者

4.3 使用案例

生产者类

/**
 * 这是一个简单的Kafka producer代码
 * 包含两个功能:
 * 1、数据发送
 * 2、数据按照自定义的partition策略进行发送
 * KafkaSpout的类
 */
public class KafkaProducerSimple {
    public static void main(String[] args) {
        /**
         * 1、指定当前kafka producer生产的数据的目的地
         *  创建topic可以输入以下命令，在kafka集群的任一节点进行创建。
         *  bin/kafka-topics.sh --create --zookeeper zk01:2181 --replication-factor 1 -- 
            partitions 1 --topic test
         */
        String TOPIC = "orderMq";
        /**
         * 2、读取配置文件
         */
        Properties props = new Properties();
        /*
         * key.serializer.class默认为serializer.class
		 */
        props.put("serializer.class", "kafka.serializer.StringEncoder");
        /*
		 * kafka broker对应的主机，格式为host1:port1,host2:port2
		 */
        props.put("metadata.broker.list", "kafka01:9092,kafka02:9092,kafka03:9092");
        /*
         * request.required.acks,设置发送数据是否需要服务端的反馈,有三个值0,1,-1
		 * 0，意味着producer永远不会等待一个来自broker的ack，这就是0.7版本的行为。
		 * 这个选项提供了最低的延迟，但是持久化的保证是最弱的，当server挂掉的时候会丢失 
          一些数据。
		 * 1，意味着在leader replica已经接收到数据后，producer会得到一个ack。
		 * 这个选项提供了更好的持久性，因为在server确认请求成功处理后，client才会返回。
		 * 如果刚写到leader上，还没来得及复制leader就挂了，那么消息才可能会丢失。
		 * -1，意味着在所有的ISR都接收到数据后，producer才得到一个ack。
		 * 这个选项提供了最好的持久性，只要还有一个replica存活，那么数据就不会丢失
		 */
        props.put("request.required.acks", "1");
        /*
		 * 可选配置，如果不配置，则使用默认的partitioner partitioner.class
		 * 默认值：kafka.producer.DefaultPartitioner
		 * 用来把消息分到各个partition中，默认行为是对key进行hash。
		 */
        props.put("partitioner.class", "cn.itcast.storm.kafka.MyLogPartitioner");
        // props.put("partitioner.class", "kafka.producer.DefaultPartitioner");
        /**
         * 3、通过配置文件，创建生产者
         */
        Producer<String, String> producer = new Producer<String, String>(new 
        ProducerConfig(props));
        /**
         * 4、通过for循环生产数据
         */
        for (int messageNo = 1; messageNo < 100000; messageNo++) {
            /**
             * 5、调用producer的send方法发送数据
             * 注意：这里需要指定 partitionKey（此例中是messageNo），用来配合自定义的 
              MyLogPartitioner进行数据分发，在分片类中partition中obj参数
             *   "appid" + UUID.randomUUID() + "itcast" 消息内容
             */
            producer.send(new KeyedMessage<String, String>(TOPIC, messageNo + "", 
            "appid" + UUID.randomUUID() + "itcast"));
        }
    }
}

消费者类

public class KafkaConsumerSimple implements Runnable {
    public String title;
    public KafkaStream<byte[], byte[]> stream;
    public KafkaConsumerSimple(String title, KafkaStream<byte[], byte[]> stream) {
        this.title = title;
        this.stream = stream;
    }
    @Override
    public void run() {
        System.out.println("开始运行 " + title);
        ConsumerIterator<byte[], byte[]> it = stream.iterator();
        /**
         * 不停地从stream读取新到来的消息，在等待新的消息时，hasNext()会阻塞
         * 如果调用 `ConsumerConnector#shutdown`，那么`hasNext`会返回false
         * */
        while (it.hasNext()) {
            MessageAndMetadata<byte[], byte[]> data = it.next();
            String topic = data.topic();
            int partition = data.partition();
            long offset = data.offset();
            String msg = new String(data.message());
            System.out.println(String.format(
                    "Consumer: [%s],  Topic: [%s],  PartitionId: [%d], Offset: [%d], 
            msg: [%s]",
                    title, topic, partition, offset, msg));
        }
        System.out.println(String.format("Consumer: [%s] exiting ...", title));
    }

    public static void main(String[] args) throws Exception{
        Properties props = new Properties();
        props.put("group.id", "dashujujiagoushi");
        props.put("zookeeper.connect", "zk01:2181,zk02:2181,zk03:2181");
        props.put("auto.offset.reset", "largest");
        props.put("auto.commit.interval.ms", "1000");
        props.put("partition.assignment.strategy", "roundrobin");
        ConsumerConfig config = new ConsumerConfig(props);
        String topic1 = "orderMq";
        String topic2 = "paymentMq";
        //只要ConsumerConnector还在的话，consumer会一直等待新消息，不会自己退出
        ConsumerConnector consumerConn = Consumer.createJavaConsumerConnector(config);
        //定义一个map
        Map<String, Integer> topicCountMap = new HashMap<>();
        topicCountMap.put(topic1, 3);//消费某个topic的消费者线程数
        //Map<String, List<KafkaStream<byte[], byte[]>> 中String是topic， 
         List<KafkaStream<byte[], byte[]>是对应的流
        Map<String, List<KafkaStream<byte[], byte[]>>> topicStreamsMap = 
        consumerConn.createMessageStreams(topicCountMap);
        //取出 `kafkaTest` 对应的 streams
        List<KafkaStream<byte[], byte[]>> streams = topicStreamsMap.get(topic1);
        //创建一个容量为4的线程池
        ExecutorService executor = Executors.newFixedThreadPool(3);
        //创建20个consumer threads
        for (int i = 0; i < streams.size(); i++)
            executor.execute(new KafkaConsumerSimple("消费者" + (i + 1), 
            streams.get(i)));
    }
}

自定义数据分组类

public class MyLogPartitioner implements Partitioner {
    private static Logger logger = Logger.getLogger(MyLogPartitioner.class);

    public MyLogPartitioner(VerifiableProperties props) {
    } 
    //Object obj 生产者send方法里的第二个参数  numPartitions topic中的partition数量
    public int partition(Object obj, int numPartitions) {
        return Integer.parseInt(obj.toString())%numPartitions;
    //     return 1;
    }

}

五内部原理

5.1 broker（管理数据的进程）

5.1.1怎么产生的

Kakfa Broker Leader的选举：Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。（这个过程叫Controller在ZooKeeper注册Watch）。这个Controller会监听其他的Kafka Broker的所有信息，如果这个kafka broker controller宕机了，在zookeeper上面的那个临时节点就会消失，此时所有的kafka broker又会一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。例如：一旦有一个broker宕机了，这个kafka broker controller会读取该宕机broker上所有的partition在zookeeper上的状态，并选取ISR列表中的一个replica作为partition leader（如果ISR列表中的replica全挂，选一个幸存的replica作为leader; 如果该partition的所有的replica都宕机了，则将新的leader设置为-1，等待恢复，等待ISR中的任一个Replica“活”过来，并且选它作为Leader；或选择第一个“活”过来的Replica（不一定是ISR中的）作为Leader），这个broker宕机的事情，kafka controller也会通知zookeeper，zookeeper就会通知其他的kafka broker。

5.1.2 做什么的

作为缓存代理负责管理数据的存储，当前服务器上的Kafka进程，集群中的每个broker都有自己的编号，

Broker的主要职责是接受Producer和Consumer的请求，并把消息持久化到本地磁盘。Broker以topic为单位将消息分成不同的分区（partition）

5.1.3 特点

Broker没有副本机制，一旦broker宕机，该broker的消息将都不可用。
Broker不保存订阅者的状态，由订阅者自己保存。
无状态导致消息的删除成为难题（可能删除的消息正在被订阅），Kafka采用基于时间的SLA（服务保证），消息保存一定时间（通常7天）后会删除。
消费订阅者可以rewind back到任意位置重新进行消费，当订阅者故障时，可以选择最小的offset(id)进行重新读取消费消息
Kafka Broker能够保证同一topic下同一partition内部的消息是有序的，但无法保证partition之间的消息全局有序
Kafka Broker以追加的方式将消息写到磁盘文件中，且每个分区中的消息被赋予了唯一整数标识，称之为偏移量，Broker仅提供基于offset的读取方式，不会维护各个Consumer当前已消费消息的offset值，而是由Consumer各自维护当前读取的进度。

5.2 数据生产

分组策略

由生产者自行实现，选择数据存储在哪个的partition中

实现相关接口自行实现

/*
 * 可选配置，如果不配置，则使用默认的partitioner partitioner.class
 * 默认值：kafka.producer.DefaultPartitioner
 * 用来把消息分到各个partition中，默认行为是对key进行hash。
 */
 props.put("partitioner.class", "cn.itcast.storm.kafka.MyLogPartitioner");
//   props.put("partitioner.class", "kafka.producer.DefaultPartitioner");

public class MyLogPartitioner implements Partitioner {
    private static Logger logger = Logger.getLogger(MyLogPartitioner.class);
    public MyLogPartitioner(VerifiableProperties props) {
    }
    //返回选择的partition序号
    public int partition(Object obj, int numPartitions) {
        return Integer.parseInt(obj.toString())%numPartitions;
//        return 1;
    }
}

保证数据的完全生产

使用ack机制，在代码中配置

/*
 * request.required.acks,设置发送数据是否需要服务端的反馈,有三个值0,1,-1
     ack机制：broker表示发来的数据已确认接收无误，表示数据已经保存到磁盘。
	 0：不等待broker返回确认消息
	 1：等待topic中某个partition leader保存成功的状态反馈
	-1：等待topic中某个partition 所有副本都保存成功的状态反馈
*/
  props.put("request.required.acks", "1");

异步模式下的数据生产

生产者会有一个缓冲区，达到一定的时间或者数量阈值就会发送到broker。当数据开始积压时，采用删除旧数据的方式无法保证完全生产

5.3 数据消费

消费者按组消费，一个组中可以含有多个消费者（多个线程），
一般一个组的消费者数量最多和其消费的数据partition数相同，否则就会有成员空闲。
一个组中的消费者线程不会同时消费到相同的数据（在生产数据的时候就是把数据分片存放在不同的partition中，消费数据的时候每一个partition只能对应消费者组里的某一个消费者）
消费者会在消费数据时会有产生一个offset值，这个值记录了消费者线程消费到的位置，会定时的保存到zookeeper中,解决了传统消息系统已发送但未确认的消息问题
同一组的消费者消费数据时分配策略：求出来回事一个区间，该区间内的partition的数据由对应的某个消费者线程消费。

m为partition数除以同一组的消费者线程数向上取整，p表示partition，c表示消费者（原图的连接显然是不符合这个算法的）

猜想：当一个消费者需要消费多个partition中的数据时一个broker中的partition应尽量分配到同一个消费者线程上会减少维护多个网络连接的开销（针对一个消费者线程消费多个partition的情况）

猜想不成立。创建topic的partition时在borker中的分配的算法推测是哈希取模，经过创建实例11个和4个partition并且网上的相关文章均确定是这个算法，但在官方说明文档中并未看到说明，再说说官方使用的消费者负载均衡算法Ci = [P(i * M),P((i + 1) * M -1)]，是一个连续的区间，如果partition在集群中不是连续均匀的分配到broker中（也就是形如broker1上是p0p1，broker上是p2p3的分布）就证明了其实在设计的时候并没有考虑维护多了网络连接造成的资源开销，又或者说这一方面的开销很小不会造成很大影响，所以作者不考虑这一点，或者是因为大部分的使用者均创建和partition数相等数量的消费者，这样一对一的连接不可避免的维护多个线程和broker 的网络连接。

如何避免重复消费（对于数据完整性要求较高应用），其实kafka的设计原则是消息“至少一次提交”，也就是说因为消费者宕机会引起数据被重复消费的问题

在kafka均衡策略里确认了同一时间一个consumer group只能有一个consumer线程消费一个，保证了线程间不重复消费，但重复消费可能还会来自于线程本身，当消费者线程消费中宕机了，offset还未及时保存，那么下次消费者恢复消费时会使用最后一次保存的offset值开始消费，消费过处理过但未及时保存的数据就会被重复消费，并且如果这些数据需要对数据库进行操作时那后果可能是严重的，对于平时的日志统计可能没什么很大的影响，就我目前所知的解决方式：

1，设为手动提交，消费一次保存一次offset值（会损耗性能）

2，每个数据都会写的一个标志，消费过的数据的标志（ID）就会被记录在redis中，每次消费前会先做一个判断（有实际应用）

3. 将自动提交的时间尽量设得短一些

避免消费数据丢失问题

一开始我也很疑惑，明明kafka保证“至少一次的提交”会引起数据被重复消费但怎么会引起数据丢失呢，有两种情况

1 .消费者自动提交offset值，当消费者获取一批数据还未完全处理的时候，自动提交offset的时间到了就把当前的offset值（有一部分是还没处理的）提交了，然后消费者宕机了，还没处理完的数据就会丢失。

2 消费者手动提交offset，一个消费者中有多个线程，但是只要有一个线程处理完成选择commit时就会把该消费者进程中所有的partition消费信息都提交，因为kafka提供的commit操作单位是进程，这个时候假设一个还在处理的线程突然挂了，正在处理的数据还没处理完但它的partition的offset已经被提交了，这个时候数据就会丢失。

解决办法

1 在手动提交offset的情况下，使用queue缓存消费者从服务端获取的数据，等到处理完所有数据之后再批量提交offset。（解决了丢失又发生了重复消费）

2 针对问题二，那就是一个进程只占有一个partition。这样一个partition提交offset时不会影响其他partition的消费。（方法局限性高）

如何保证消费者消耗的数据是有序的

这是个伪命题，只有一个可能，就是一个生产者（或者设置全局序号管理器），一个partition，一个消费者。这种场景和大数据应用场景相悖

基于推送和拉动的消费方式问题

两者各有利弊

基于推送系统的缺点

1 当消费率低于生产率时，消费者会不堪重负

2 代理控制数据传输的速率，基于推送的系统难以与不同的消费者打交道

解决：可以通过某种退避协议来缓解，消费者可以通过该协议表明它已经不堪重负，但是转移率会有所下降

基于推送系统的优点

1 有数千个生产者的目标用例中操作磁盘显得更为可靠

基于拉取系统的缺点

1 如果broker（代理/经纪人）中没有数据，消费者就会发生紧密的循环轮询。

解决：设置在尝试多次轮询时使消费者进入休眠状态，直到数据达到一定大小才重新开始拉取数据

基于拉取系统的优点

1 有助于对发送给消费者的数据进行积极的批处理

2 有利于系统的低时延处理。（当数据量不足时消费者总会拉取当前代理中剩余数据的最大值处理）将代理榨干

5.4 快速的秘诀

1 先从缓存区查找数据(底层操作系统提供的PageCache内存缓存页功能：尽可能多的把可能多的内存当成磁盘缓存使用，避免使用JVM缓存)

2. 再从磁盘中查找使用Sendfile技术，调用sendFile()函数采用零拷贝的方式传输。

零拷贝就是省去用户空间到内核空间之间的拷贝，读取的数据在磁盘上，那么OS会把磁盘数据会拷贝到内核读缓存中，然后直接发往网卡缓存等待发送给用户

5.5 运行解析图

网世侠客

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
kafka基础入门

官方参考文档：http://kafka.apache.org/documentation/#introduction（翻译页面就行了）kafka集群搭建：https://blog.csdn.net/zxy987872674/article/details/72466504一基本介绍1.1 做什么的一个分布式的、可分区的、可复制的开源消息系统，构建在系统或应用之间的实...
复制链接

扫一扫