kafka使用的总结

kafka是什么

1.在2016年之前，Kafka的定位是高吞吐量分布式消息系统，以下图片是2016年之前Kafka官网的标志图片：

2.但是从2016年后，Kafka的定位是分布式流式处理平台，以下图片是Kafka官网的标志图片：

kafka的一些应用场景

1.Messaging System(消息系统)
2.Storge System(存储系统，Kafka支持分布式数据存储，但是数据默认只存储168h，可以配置)
3.连接器(数据导出导入)
4.Streaming Processing(流式处理)

在大数据中，一般都是使用Kafka作为大数据实时流处理项目中的数据源，使用的就是Kafka的分布式消息系统的功能

kafka的术语

1.Kafka Cluster：即Kafka集群，因为Kafka是分布式的消息系统，所以一般这个分布式系统都是由若干个服务器组成的一个集群
2.Broker Server：Kafka集群中的每一个服务器上启动一个Broker Server进程，所以Kafka集群是由若干个Broker Server进程组成的，Broker Server是基于JVM之上的服务进程
3.topic：Kafka集群中的消息都是使用topic组织起来的，说白了，topic就是消息类别，也可以解释成主题，不同应用产生不同类别的消息，可以设置不同的主题
4.Producer：消息发送者，将消息发送给某一个指定的topic
5.Consumer：消息消费者，消费某个topic或者某几个topic的消息

Kafka基本术语-topic

要使用Kafka的消息功能的话，需要先在Kafka集群中创建一个topic，有了topic后，消息发送者才可以将消息发送到这个topic中，消息消费者也可以指定消费这个topic的消息了，所以topic是Kafka消息系统最基本的概念了，可以有多个Producer发送消息给同一个topic，同一个topic的数据也可以被多个Consumer消费
其实topic就是消息的类别而已，Kafka集群中的消息都是通过topic来组织的，每一条消息肯定需要对应一个topic

为了提高消息处理的并行度，一个topic的数据可以被分为多个partition(其实就是分区了)，每一个partition是一个有序、不变的消息序列，新的消息会不断的追加到这个消息序列中。在partition中每一条消息会按照时间顺序分配到一个单调递增的顺序编号，这个编号我们称之为消息的偏移量，即offset

一个topic下的所有的patitions是分布式的分布在多个Broker Server中,就好比hdfs的备份一样
假设我们有一个三个partition的topic:topic-test,这个topic的三个partition是均匀的分布在3个Broker Server中的,这样的设计可以使得存在于不同的Broker Server中的partition都可以独立的对外提供消息的存储以及消息的发送或者消费的服务，所以可以提高吞吐量和并行能力，理论上，一个topic的分区越大，吞吐量越大，但实际上不是这样的

Producer

Producer中包含的组件有：
1.Sender：这个组件中包含一个NetworkClient，用于和Kafka中的Broker Server进行RPC通讯的，比如将数据发往某个Broker Server，或者从Kafka集群中查询某个topic的元数据信息
2.Metadata：topic的元数据信息，比如这个topic包含哪些partition，每一个partition存在于哪一个Broker Server上，这部分信息是会缓存在Producer的内存中，但是到了一定的时候后，内存的元数据会失效，需要从Kafka集群中查询最新的元数据信息
3.Partitioner：给消息分区的分区器
4.Record Accumulator：用于将分区好的消息组织成一个batch，然后通过Sender，将这个batch的消息发往到对应的分区中

一条消息发送的流程步骤如下:
1.根据topic向MetaData请求对应的topic的元数据
2.如果topic的元数据不存在的话，则需要请求Sender向Kafka集群中查询该topic的元数据信息
3.将查询到的topic的元数据更新到MetaData的内存中
4.对消息进行分区，这个分区器是可以自定义的，如果没有自定义的话，则是使用Kafka默认的分区器，其分区的逻辑如下：
a.如果消息的key是空的，那么采用轮询的方式，即第一条消息发往p0，第二条消息则发往p1，第三条消息发往p0，第四条消息又发往p1… 以此类推
b.如果消息的key不是空的话，则按照key的hash值与topic的分区数取模得到这条消息应该属于哪一个分区
5.将分完区的消息追加到Record Accumulator相对应的分区数据上，当Record Accumulator达到以下两个条件之一的时候，则将接收到的消息组织成一个batch发往到Broker Server:
a.当Record Accumulator接收到的消息的速度大于向Kafka集群发送的速度，那么当Record Accumulator接收到的消息的大小达到了一个阈值(batchSize)
b.当Record Accumulator接收到的消息的速度小于向Kafka集群发送的速度，那么Record Accumulator持续接收消息，当达到一定的时间阈值(lingerMs)
6.拿到Record Accumulator组织好的batch消息，并且拿到相应的分区存储的broker server信息
7.通过组件Sender将batch消息发往到指定的broker server中
可以得出一个结论：消息的发送是一个异步的过程，即将消息分区后，然后追加到Record Accumulator就返回了
就比如flume中的这个往kafka发送数据的配置:pro.sinks.k1.kafka.producer.linger.ms = 0 0就是立即返回,这样的操作就可能丢失数据,1就是有一个分区返回了,就完成,-1就是等所有的分区都返回

备注:
1.一个partition的数据都是存储在某个Broker Server上的文件目录(我配置的是log.dirs=/home/hadoop-jrq/bigdata/kafka-logs)(后面我会写一个文章做说明)
2.一个partition只存在一个Broker Server上会有问题，假设这个Broker Server挂掉了，那么存在于这个Broker Server上的partition都没了，对外提供不了服务了，为了解决这个问题，Kafka引入了partition的ISR机制(后面我会写一个文章做说明)

Cosumer和Consumer Group

Consumer

Producer发送的消息不管有没有被Consumer消费，都会持久化到Kafka集群管理的文件中，当然这个消息也不是会永远的存储在Kafka集群中，可以设置参数log.retention.hours(默认是168小时(7天))，表示消息在Kafka集群中保留的时间超过这个参数的时间就会被删除掉。在消息没有被删除之前，Consumer可以在任何的时间去消费这个消息

每一个Consumer在消费消息的时候，都是根据offset来消费的，这个offset是由Consumer自己来控制的，所以Consumer可以按照任何的方式访问任何的offset的消息:
1.一般的话，Consumer是线性的消费消息，每当消费完一个消息后，Consumer就会将自己控制的offset往前加1
2.因为offset是Consumer自己控制的，所以Consumer可以按照任何的顺序重新消费以前已经消费过的消息(设置offset)

当我们执行下面的命令的时候，启动的Consumer消费消息的方式是：从最新的消息开始消费
cd ~/bigdata/kafka_2.11-1.0.0
bin/kafka-console-consumer.sh --bootstrap-server master:9092 --topic test-1

当我们执行下面的命令的时候，启动的Consumer消费消息的方式是：从topic的开头开始消费
cd ~/bigdata/kafka_2.11-1.0.0
bin/kafka-console-consumer.sh --bootstrap-server master:9092 --topic test-1 --from-beginning

当我们执行下面的命令的时候，启动的Consumer消费消息的方式是：从指定的offset开始消费
cd ~/bigdata/kafka_2.11-1.0.0
bin/kafka-console-consumer.sh --bootstrap-server master:9092 --topic test-1 --partition 0 --offset 1
注意:当指定–offset的时候，一定要指定–partition
有的时候，在执行上面的指定offset消费消息的时候，不知道这个topic的offset的范围是多少，这样的话你就不知道这个topic中是否存在你需要消费的offset了，那么我们现在可以使用下面的命令来查询指定topic的offset的范围:
## 查询在时间戳等于1899233222时候的test-1这个topic的每一个分区的offset
## --time表示时间戳，即我们需要查询指定时间戳的时候的offset
bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list master:9092 -topic test-1 --time 1899233222

## --time -2 表示查询最早的(即earliest)的offset，即最小的offset了
## 查询test-1这个topic的每一个分区的最小offset
bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list master:9092 -topic test-1 --time -2

 ## 查询test-1这个topic的每一个分区的最大offset
 ## --time -1 表示查询最新的(即latest)的offset，即最大的offset了
bin/kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list master:9092 -topic test-1 --time -1

上面两个步骤得出的结果就是你的offset区间,比如:第一个结果是0,第二个是3 那么offset的区间就是[0,3)
也可以直接在kafka-manager上去看:
![在这里插入图片描述](https://img-blog.csdnimg.cn/20190816120214323.png

Consumer Group

1.每一个Consumer需要归属于一个Consumer Group
2.一个Consumer Group可以包含一到多个Consumer
3.一个topic中的一条Record会被所有订阅了这个topic的Consumer Group消费

如果所有的Consumer都属于同一个Consumer Group，那么这个消费组中的所有的消费者会均匀的消费指定topic中的消息，启动负载均衡的功效
如果所有的Consumer在不同的Consumer Group的话，那么每一个Consumer都需要消费指定topic中的所有的消息

在使用Consumer Group的时候，我们经常会碰到想去操作:
1.查看有哪些消费组
2.每一个消费组中的消费者消费消息的状态是怎么样的？
3.对消费者进行reset offset
上面的事情我们都可以使用bin/kafka-consumer-groups.sh这个脚本来做到

Java开发Producer和Consumer

Producer的代码：

package com.jrq.streaming.kafka.example;

import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.Producer;
import org.apache.kafka.clients.producer.ProducerRecord;

import java.util.Properties;

public class SimpleProducer {
    public static void main(String[] args) {
        Properties props = new Properties();
        // Kafka Broker Server的监听地址，多个可以使用逗号分隔开
        props.put("bootstrap.servers", "master:9092,slave1:9092,slave2:9092");
        
        // ack机制相关配置
        props.put("acks", "all");
        
        // 重发机制
        props.put("retries", 2);
        
        // 批量发送的相关参数
        props.put("buffer.memory", 33554432);
        props.put("compression.type", "snappy");
        props.put("batch.size", 10);
        props.put("linger.ms", 1);
        
        // key-value序列化相关配置
        props.put("key.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        props.put("value.serializer", "org.apache.kafka.common.serialization.StringSerializer");
        

        Producer<String, String> producer = new KafkaProducer<>(props);
        for (int i = 0; i < 100; i++) {
            producer.send(new ProducerRecord<String, String>("test-group",
                    Integer.toString(i), Integer.toString(i)));
        }

        producer.close();
    }
}

解释下上面的配置:
1.ack 机制相关的两个配置参数:
// acks可以的取值为[0, 1, -1或者all]， -1和all的功能是一样的
props.put(“acks”, “all”);
和上面所说的flume配置:pro.sinks.k1.kafka.producer.linger.ms = 0 解释一样的
2.重发机制
props.put(“retries”, 2);
当Producer发送消息的时候，如果消息发送失败的话，则会尝试重发这个消息，这个配置默认的值是0，即默认是禁用重发机制
3.批量发送的相关四个配置参数
props.put(“buffer.memory”, 33554432);
props.put(“compression.type”, “snappy”);
props.put(“batch.size”, 10);
props.put(“linger.ms”, 1);
Producer发送消息的时候，是先对消息进行分区，然后将分区之后的消息发送到Record Accumulator这个内存缓存中。然后将消息组织成batch再发送，下面是对上面四个参数配置的说明:
1.Record Accumulator这个内存缓存的大小就是用配置buffer.memory来控制，这个配置的大小是33554432字节(即32M)，这个参数建议配置成比Producer进程堆内存大小小一点最好
2.每一条消息发往Record Accumulator后，可以通过配置参数compression.type来决定是否需要对消息进行压缩，压缩算法的类型有：none、gzip、snappy以及lz4，默认是none(即对消息不压缩)
3.消息是在Record Accumulator中组织成batch再发送到Broker Server中的，那么这个batch的大小由配置batch.size(单位是字节)来控制了，这个参数如果设置太小的话就会使得发送消息的次数变多，也可能降低了吞吐量；当然，如果设置太大的话可能会浪费内存，也会导致消息发送的延迟。这个值默认是16384字节
4.通常来说只有在消息产生速度大于发送速度的时候才会将消息组织成batch，然后再一起发送，那如果消息产生的速度小于发送的速度的话，当然是来一条消息就发送一条消息了，这样的话消息的发送就没有延迟了，但是来一条消息就发送一条消息的话，会导致请求数太多了，就是需要不断的网络传输，会有性能损耗，如果我们设置一个时间段，当消息来了的时候，先不发送消息，让消息等待一段时间，在这段时间内可能会等到其他的消息，然后再将这段时间内的消息当成一个batch再发送，这样可以减少发送请求的次数，这个时间段我们可以通过linger.ms(单位是毫秒)配置来设置，这个配置默认的值是0，表示来一条消息发送一条消息，就不进行等待了

4.key-value序列化相关的两个配置参数：
props.put(“key.serializer”, “org.apache.kafka.common.serialization.StringSerializer”);
props.put(“value.serializer”, “org.apache.kafka.common.serialization.StringSerializer”);
key.serializer和value.serializer的功能分别是将消息的key和value序列化成字节(因为网络传输传输的是字节)
Kafka支持常用的序列化器有：
// 字符串类型
org.apache.kafka.common.serialization.StringSerializer
org.apache.kafka.common.serialization.JsonSerializer
// byte类型的数组
org.apache.kafka.common.serialization.ByteArraySerializer
org.apache.kafka.common.serialization.ByteBufferSerializer
// 基本类型
org.apache.kafka.common.serialization.DoubleSerializer
org.apache.kafka.common.serialization.FloatSerializer
org.apache.kafka.common.serialization.IntegerSerializer
org.apache.kafka.common.serialization.LongSerializer
org.apache.kafka.common.serialization.ShortSerializer

Consumer的代码

package com.jrq.streaming.kafka.example;

import org.apache.kafka.clients.consumer.ConsumerRecord;
import org.apache.kafka.clients.consumer.ConsumerRecords;
import org.apache.kafka.clients.consumer.KafkaConsumer;

import java.util.Arrays;
import java.util.Properties;

public class SimpleComsumerGroup1 {
    public static void main(String[] args) {
        Properties props = new Properties();
        props.put("bootstrap.servers", "master:9092");
        props.put("group.id", "group1");
        
        // key-value反序列化的配置
        props.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");
        props.put("value.deserializer", "org.apache.kafka.common.serialization.StringDeserializer");

        KafkaConsumer<String, String> consumer = new KafkaConsumer<String, String>(props);
        consumer.subscribe(Arrays.asList("test-group"));

        while (true) {
            // 采用的是pull模式来消费消息
            ConsumerRecords<String, String> records = consumer.poll(100);
            for (ConsumerRecord<String, String> record : records) {
                System.out.printf("offset = %d, key = %s, value = %s, topic = %s, partition = %d",
                        record.offset(), record.key(), record.value(), record.topic(), record.partition());
                System.out.println();
            }
        }
    }
}

1.key-value反序列化的两个配置:
props.put(“key.deserializer”, “org.apache.kafka.common.serialization.StringDeserializer”);
props.put(“value.deserializer”, “org.apache.kafka.common.serialization.StringDeserializer”);
key.deserializer和value.deserializer的功能分别是将字节类型消息的key和value反序列化成对应的类型(因为从网络传输传输过来的字节) 和上面的一样
2.pull or push
Kafka的Producer是将消息发送给Broker Server的，采用的push机制，即发送端将消息推送到Broker Server

Kafka的Consumer则是消费Broker Server的消息，采用是pull机制，即消费者是从Broker Server端拉取的消息，然后进行消费。Kafka之所以选择使用pull机制，是因为考虑到如下的两点优点：
1.当一个消费者消费消息落后的时候，当它想赶上消息进度的时候，都是很好控制的
2.更加容易控制批量的消费消息，如果是push机制的话，要么就是来了一条消息就消费一条消息，要么在Broker端累积一定的消息后，然后push给消费者，但是呢，消费者不一定立马可以处理这个batch消息，所以呢，如果消费者掌握主动权的话，就可以很容易的控制批量消费了