kafka

1. Kafka概述 2. Kafka安装部署 3. Kafka架构深入 4. Kafka-eagle（kafka监控）

1. Kafka概述

1.1 定义 （1）Kafka是一个分布式的基于发布/订阅模式的消息队列（Message Queue），主要应用于大数据实时处理领域。（传统使用） 分布式：多台服务器干一件事。 发布/订阅：消息的发布者不会将消息直接发送给特点的订阅者，而是将发布的消息（数据）分为不同的类型，订阅者只接收感兴趣的消息，根据需求选择性订阅。 （2）Kafka是一个开源的分布式事件流平台（event streaming platform），被数千家公司用于高性能数据管道、流分析、数据集成和关键任务应用。（最新定位）

1.2 消息队列 1.2.1 传统消息队列的应用场景 使用消息队列的好处 1）解耦 允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。 2）可恢复性 系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。 3）缓冲 有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致的情况。 4）（削峰）灵活性 & 峰值处理能力 在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见。如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。 5）异步通信 很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。 1.2.2 消息队列的两种模式 （1）点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）灵活性非常差，生产者，不好用。 一对一发布订阅模式，kafka 模式一对多模式 消息生产者生产消息发送到Queue中，然后消息消费者从Queue中取出并且消费消息。 消息被消费以后，queue中不再有存储，所以消息消费者不可能消费到已经被消费的消息。Queue支持存在多个消费者，但是对一个消息而言，只会有一个消费者可以消费。  （2）发布/订阅模式（一对多，消费者消费数据之后不会清除消息） Kafka是发布订阅模式。消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。

1.3 Kafka基础架构 1）Producer ：消息生产者，就是向kafka broker发消息的客户端； 2）Consumer ：消息消费者，向kafka broker取消息的客户端； 3）Consumer Group （CG）：消费者组，由多个consumer组成。消费者组内每个消费者负责消费不同分区的数据，同一个topic的一个分区只能由同一个组内一个消费者消费；消费者组之间互不影响。所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。比如组长 组员 大家共同干一件事，每个人干一件事，干了什么是由kafka记录组长也记录一份，这样大家在聚集在一起的时候，还是可以复原原文件。 4）Broker ：一台kafka服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic。 5）Topic ：可以理解为一个队列，生产者和消费者面向的都是一个topic； 6）Partition：为了实现扩展性，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic可以分为多个partition，每个partition是一个有序的队列； 7）Replica：副本，为保证集群中的某个节点发生故障时，该节点上的partition数据不丢失，且kafka仍然能够继续工作，kafka提供了副本机制，一个topic的每个分区都有若干个副本，一个leader和若干个follower。 8）leader：每个分区多个副本的“主”，生产者发送数据的对象，以及消费者消费数据的对象都是leader。 9）follower：每个分区多个副本中的“从”，实时从leader中同步数据，保持和leader数据的同步。leader发生故障时，某个follower会成为新的leader。

2.Kafka安装部署

2.1  单机版安装部署及简单命令操作 解压，改名 [root@kb129 install]# tar -xvf ./kafka_2.12-2.8.0.tgz -C ../soft/ [root@kb129 soft]# mv kafka_2.12-2.8.0/ kafka212 配置环境变量并source [root@kb129 soft]# vim /etc/profile #KAFKA_HOME export KAFKA_HOME=/opt/soft/kafka212 export PATH=$KAFKA_HOME/bin:$PATH 创建kfk消息目录 [root@kb129 kafka212]# mkdir ./kfkdata 编辑配置文件 [root@kb129 kafka212]# vim ./config/server.properties 21 broker.id=0 36 advertised.listeners=PLAINTEXT://192.168.142.129:9092 60 log.dirs=/opt/soft/kafka212/kfkdata       #消息存放目录 103 log.retention.hours=1680                #消息存放时间小时（70天） 123 zookeeper.connect=192.168.142.129:2181   #连接zookeeper 137 delete.topic.enable=true                 #设置可以对topic删除，默认不能删除 启动zookeeper [root@kb129 kafka212]# zkServer.sh start 启动kafka服务 [root@kb129 kafka212]# nohup kafka-server-start.sh /opt/soft/kafka212/config/server.properties & [root@kb129 kafka212]# jps 12162 Kafka 查看zookeeper客户端文件夹 [zk: localhost:2181(CONNECTED) 0] ls / [cluster, controller, brokers, zookeeper, admin, isr_change_notification, log_dir_event_notification, controller_epoch, feature, consumers, latest_producer_id_block, config, hbase] 创建一个topic [root@kb129 kafka212]# kafka-topics.sh --create --zookeeper 192.168.142.129:2181 --topic kb23 --partitions 1 --replication-factor 1 Created topic kb23. 查看topic [root@kb129 kafka212]# kafka-topics.sh --zookeeper 192.168.142.129:2181 --list kb23 打开生产者（发布消息，消费者可以收到消息） [root@kb129 kafka212]# kafka-console-producer.sh --topic kb23 --broker-list 192.168.142.129:9092 > 打开消费者 [root@kb129 kafka212]# kafka-console-consumer.sh --bootstrap-server 192.168.142.129:9092 --topic kb23 --from-beginning --from-beginning会收取以前发布的消息，不加则只接受新消息 查看topic详情 [root@kb129 kafka212]# kafka-topics.sh --zookeeper 192.168.142.129:2181 --describe --topic kb23 Topic: kb23    TopicId: gU3K3a9SR1Gl0zQlPiIuwA   PartitionCount: 1       ReplicationFactor: 1 Configs:        Topic: kb23    Partition: 0     Leader: 0 Replicas: 0      Isr: 0 查看topic分区消息数量 [root@kb129 kafka212]# kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list 192.168.142.129:9092 --topic kb23 kb23:0:1   kb23，0号分区，1条消息 删除topic [root@kb129 kafka212]# kafka-topics.sh --zookeeper 192.168.142.129:2181 --delete --topic kb23 创建3分区topic [root@kb129 kafka212]# kafka-topics.sh --create --zookeeper 192.168.142.129:2181 --topic bigdata --partitions 3 --replication-factor 1 查看topic详情 [root@kb129 kafka212]# kafka-topics.szookeeper 192.168.142.129:2181 --describe --topic bigdata Topic: bigdata TopicId: jGAbV19lRjG_qpF4VyLHaA  PartitionCount: 3       ReplicationFactor: 1 Configs:        Topic: bigdata Partition: 0     Leader: 0 Replicas: 0      Isr: 0        Topic: bigdata Partition: 1     Leader: 0 Replicas: 0      Isr: 0        Topic: bigdata Partition: 2     Leader: 0 Replicas: 0      Isr: 0 发布11条消息后查看分区分布情况 [root@kb129 kafka212]# kafka-run-class.sh kafka.tools.GetOffsetShell --broker-list 192.168.142.129:9092 --topic bigdata bigdata:0:5 bigdata:1:2 bigdata:2:4

2.2  集群版安装部署及简单命令操作 在node1节点上解压，改名 [root@node1 install]# tar -xvf ./kafka_2.12-2.8.0.tgz -C ../soft/ [root@ node1 soft]# mv kafka_2.12-2.8.0/ kafka212 配置环境变量并source [root@ node1 soft]# vim /etc/profile #KAFKA_HOME export KAFKA_HOME=/opt/soft/kafka212 export PATH=$KAFKA_HOME/bin:$PATH 创建kfk消息目录 [root@ node1 kafka212]# mkdir ./kfkdata 编辑配置文件 [root@ node1 kafka212]# vim ./config/server.properties 21 broker.id=0 36 advertised.listeners=PLAINTEXT://192.168.142.136:9092 60 log.dirs=/opt/soft/kafka212/kfkdata       #消息存放目录 103 log.retention.hours=1680                #消息存放时间小时（70天） 123 zookeeper.connect=192.168.142.136:2181, 192.168.142.137:2181, 192.168.142.138:2181   #连接zookeeper 137 delete.topic.enable=true                 #设置可以对topic删除，默认不能删除 拷贝文件至node2和node3节点 [root@node1 ~]# scp /etc/profile root@node2:/etc/ [root@node1 ~]# scp /etc/profile root@node3:/etc/ [root@node1 ~]# scp -r /opt/soft/kafka212/ root@node2:/opt/soft/ [root@node1 ~]# scp -r /opt/soft/kafka212/ root@node3:/opt/soft/ 至node2和node3上source /etc/profile，并更改vim server.properties中的 21行的broker.id=1和broker.id=2 36行的advertised.listeners为本机IP 启动zookeeper [root@ node1 kafka212]# zkServer.sh start [root@ node2 kafka212]# zkServer.sh start [root@ node3 kafka212]# zkServer.sh start 启动kafka服务 [root@ node1 kafka212]# nohup kafka-server-start.sh /opt/soft/kafka212/config/server.properties & [root@ node2 kafka212]# nohup kafka-server-start.sh /opt/soft/kafka212/config/server.properties & [root@ node3 kafka212]# nohup kafka-server-start.sh /opt/soft/kafka212/config/server.properties & [root@ node1 kafka212]# jps 12162 Kafka 创建3分区3副本的topic [root@node1 config]# kafka-topics.sh --create --zookeeper 192.168.142.136:2181,192.168.142.137:2181,192.168.142.138:2181 --topic njzb --partitions 3 --replication-factor 3 Created topic njzb. 或创建6分区，3副本的topic（命令稍优化） [root@node1 ~]# kafka-topics.sh --create --bootstrap-server node1:9092 --topic bigdata --partitions 6 --replication-factor 3 Created topic bigdata. 查看topic详情 [root@node1 shell]# kafka-topics.sh --zookeeper 192.168.142.136:2181,192.168.142.137:2181,192.168.142.138:2181 --describe --topic njzb Topic: njzb     TopicId: 1emHF1NNT-ScfQ5rsgXSAg PartitionCount: 3       ReplicationFactor: 3 Configs:        Topic: njzb     Partition: 0     Leader: 2 Replicas: 2,0,1 Isr: 2,0,1        Topic: njzb     Partition: 1     Leader: 0 Replicas: 0,1,2 Isr: 0,1,2        Topic: njzb     Partition: 2     Leader: 1 Replicas: 1,2,0 Isr: 1,2,0 [root@node1 ~]# kafka-topics.sh --bootstrap-server node1:9092 --describe --topic bigdata Topic: bigdata TopicId: _E1iavb_TiyCxGCnO_UUqA PartitionCount: 6       ReplicationFactor: 3 Configs: segment.bytes=1073741824        Topic: bigdata Partition: 0     Leader: 0 Replicas: 0,2,1 Isr: 0,2,1        Topic: bigdata Partition: 1     Leader: 2 Replicas: 2,1,0 Isr: 2,1,0        Topic: bigdata Partition: 2     Leader: 1 Replicas: 1,0,2 Isr: 1,0,2        Topic: bigdata Partition: 3     Leader: 0 Replicas: 0,1,2 Isr: 0,1,2        Topic: bigdata Partition: 4     Leader: 2 Replicas: 2,0,1 Isr: 2,0,1        Topic: bigdata Partition: 5     Leader: 1 Replicas: 1,2,0 Isr: 1,2,0

3. Kafka架构深入

3.1  Kafka工作流程及文件存储机制 Kafka中消息是以topic进行分类的，生产者生产消息，消费者消费消息，都是面向topic的。 一个topic下的每一个分区都单独维护自己的offset，所以分发到不同分区中的数据是不同的数据。消费者的分区维护是一个消费者组一个主题的一个分区维护一个offset。 topic是逻辑上的概念，而partition是物理上的概念，每个partition对应于一个log文件，该log文件中存储的就是producer生产的数据。Producer生产的数据会被不断追加到该log文件末端，且每条数据都有自己的offset。消费者组中的每个消费者，都会实时记录自己消费到了哪个offset，以便出错恢复时，从上次的位置继续消费。 由于生产者生产的消息会不断追加到log文件末尾，为防止log文件过大导致数据定位效率低下，Kafka采取了分片和索引机制，将每个partition分为多个segment。每个segment对应两个文件——“.index”文件和“.log”文件。这些文件位于一个文件夹下，该文件夹的命名规则为：topic名称+分区序号。例如，first这个topic有三个分区，则其对应的文件夹为first-0,first-1,first-2。 00000000000000000000.index 00000000000000000000.log 00000000000000170410.index 00000000000000170410.log 00000000000000239430.index 00000000000000239430.log index和log文件以当前segment的第一条消息的offset命名。下图为index文件和log文件的结构示意图。 “.index”文件存储大量的索引信息，索引信息按照数组的逻辑排列，“.log”文件存储大量的数据，数据直接紧密排列，索引文件中的元数据指向对应数据文件中message的物理偏移地址。 二分查找的方式迅速定位我们的offset 在哪里！

3.2 Kafka生产者 3.2.1 消息发送流程 Kafka的Producer发送消息采用的是异步发送的方式。在消息发送的过程中，涉及到了两个线程——main线程和Sender线程，以及一个线程共享变量——RecordAccumulator。main线程将消息发送给RecordAccumulator，Sender线程不断从RecordAccumulator中拉取消息发送到Kafka broker。 相关参数： batch.size：只有数据积累到batch.size之后，sender才会发送数据。 linger.ms：如果数据迟迟未达到batch.size，sender等待linger.time之后就会发送数据。 备注：在实际工作中 linger.ms=0; 3.2.2 数据可靠性保证 1）生产者发送数据到topic partition的可靠性保证 为保证producer发送的数据，能可靠的发送到指定的topic，topic的每个partition收到producer发送的数据后，都需要向producer发送ack（acknowledgement确认收到），如果producer收到ack，就会进行下一轮的发送，否则重新发送数据。 2）Topic partition存储数据的可靠性保证 （1）副本数据同步策略 方案 优点 缺点 半数以上完成同步，就发送ack 延迟低 选举新的leader时，容忍n台节点的故障，需要2n+1个副本 全部完成同步，才发送ack 选举新的leader时，容忍n台节点的故障，需要n+1个副本 延迟高 Kafka选择了第二种方案，原因如下： ①同样为了容忍n台节点的故障，第一种方案需要2n+1个副本，而第二种方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。 ②虽然第二种方案的网络延迟会比较高，但网络延迟对Kafka的影响较小。 （2）ISR         采用第二种方案之后，设想以下情景：leader收到数据，所有follower都开始同步数据，但有一个follower，因为某种故障，迟迟不能与leader进行同步，那leader就要一直等下去，直到它完成同步，才能发送ack。这个问题怎么解决呢？         Leader维护了一个动态的in-sync replica set (ISR)，意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后，leader就会给producer发送ack。如果follower长时间未向leader同步数据，则该follower将被踢出ISR，该时间阈值由replica.lag.time.max.ms参数设定。Leader发生故障之后，就会从ISR中选举新的leader。 （3）ack应答级别 对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没必要等ISR中的follower全部接收成功。 所以Kafka为用户提供了三种可靠性级别，用户根据对可靠性和延迟的要求进行权衡，选择以下的配置。 acks参数配置： acks： 0：这一操作提供了一个最低的延迟，partition的leader接收到消息还没有写入磁盘就已经返回ack，当leader故障时有可能丢失数据； 1： partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将会丢失数据； -1（all）： partition的leader和follower全部落盘成功后才返回ack。但是如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复。 3）leader和 follower故障处理细节 LEO：指的是每个副本最大的offset； HW：指的是消费者能见到的最大的offset，ISR队列中最小的LEO。 （1）follower故障 follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW，即follower追上leader之后，就可以重新加入ISR了。 （2）leader故障 leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader同步数据。 注意：这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复。 3.2.3 Producer事务 0.11版本的Kafka同时引入了事务的特性，为了实现跨分区跨会话的事务，需要引入一个全局唯一的Transaction ID，并将Producer获得的PID和Transaction ID绑定。这样当Producer重启后就可以通过正在进行的Transaction ID获得原来的PID。 为了管理Transaction，Kafka引入了一个新的组件Transaction Coordinator。Producer就是通过和Transaction Coordinator交互获得Transaction ID对应的任务状态。Transaction Coordinator还负责将事务所有写入Kafka的一个内部Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。 3.2.4 发送API 1）导入依赖 <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-clients</artifactId> <version>2.8.0</version> </dependency> <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka_2.12</artifactId> <version>2.8.0</version> </dependency> 2）编写代码 需要用到的类： KafkaProducer：需要创建一个生产者对象，用来发送数据 ProducerConfig：获取所需的一系列配置参数 ProducerRecord：每条数据都要封装成一个ProducerRecord对象 import org.apache.kafka.clients.producer.KafkaProducer; import org.apache.kafka.clients.producer.ProducerConfig; import org.apache.kafka.clients.producer.ProducerRecord; import org.apache.kafka.common.serialization.StringSerializer; import java.util.Properties; import java.util.Scanner; /* * kafka生产者 * */ public class MyProducer { public static void main(String[] args) { // 1. 创建kafka生产者配置类 Properties properties = new Properties(); // 2. 添加配置参数 // 添加连接 properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"192.168.142.129:9092"); // 配置key,value序列化 properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class); properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,StringSerializer.class); /*配置ack响应， 0：不等待broker响应，无法确保数据正确送到broker中 1：只需要得到分区副本中Leader确认就OK，可能会数据丢失 -1：等到所有副本确认收到信息，响应时间最长，数据最安全，不会丢失数据，可能会数据重复 */ properties.put(ProducerConfig.ACKS_CONFIG,"-1"); // 3. 创建kafka生产者对象 KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(properties); // 4. 循环输入，调用send方法,发送消息 Scanner scanner = new Scanner(System.in); while (true){ System.out.print("请输入内容："); String msg = scanner.nextLine(); if(msg.equals("tt")){ break; } ProducerRecord<String, String> record = new ProducerRecord<String, String>("bigdata", msg); kafkaProducer.send(record); } // 5. 关闭资源 kafkaProducer.close(); } } 2）多线程测试数据丢失（通过配置参数，线程休眠时间解决） import org.apache.kafka.clients.producer.KafkaProducer; import org.apache.kafka.clients.producer.ProducerConfig; import org.apache.kafka.clients.producer.ProducerRecord; import org.apache.kafka.common.serialization.StringSerializer; import java.util.Properties; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; public class Myproducer2 { public static void main(String[] args) { // 1. 创建kafka生产者配置类 final Properties properties = new Properties(); // 2. 添加配置参数 // 添加连接 properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG,"192.168.142.129:9092"); // 配置key,value序列化 properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class); properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG,StringSerializer.class); // 配置消息发送失败重试次数3（默认为0） properties.put(ProducerConfig.RETRIES_CONFIG,3); //两次重试时间间隔ms（默认为100ms）,设置1000ms后重试 properties.put(ProducerConfig.RECONNECT_BACKOFF_MAX_MS_CONFIG,1000); // 批次大小 默认16K,16384byte properties.put("batch.size", 102400); //发送缓存大小 properties.put(ProducerConfig.SEND_BUFFER_CONFIG,102400); // RecordAccumulator缓冲区大小 默认32M，33554432 properties.put("buffer.memory", 67108864); /* // 等待时间 properties.put("linger.ms", 1); */ /*配置ack响应， 0：不等待broker响应，无法确保数据正确送到broker中 1：只需要得到分区副本中Leader确认就OK，可能会数据丢失 -1：等到所有副本确认收到信息，响应时间最长，数据最安全，不会丢失数据，可能会数据重复 */ properties.put(ProducerConfig.ACKS_CONFIG,"-1"); ExecutorService executorService = Executors.newCachedThreadPool(); // 3. 调用线程循环输入，调用send方法,发送消息 for (int i = 0; i < 10; i++) { Thread thread = new Thread(new Runnable() { public void run() { // 4. 创建kafka生产者对象 KafkaProducer<String, String> kafkaProducer = new KafkaProducer<String, String>(properties); String threadName = Thread.currentThread().getName(); for (int j = 0; j < 100000; j++) { ProducerRecord<String, String> record = new ProducerRecord<String, String>("bigdata", threadName + " " + j); kafkaProducer.send(record); } } }); executorService.execute(thread); } executorService.shutdown(); while (true){ try { //设置主程序休眠时间，程序可以等待，或者进入retries重发 Thread.sleep(10000); } catch (InterruptedException e) { throw new RuntimeException(e); } if (executorService.isTerminated()){ System.out.println("game over"); break; } } } }

3.3 Kafka消费者 3.3.1 消费方式 consumer采用pull（拉）模式从broker中读取数据。 push（推）模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。它的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。 pull模式不足之处是，如果kafka没有数据，消费者可能会陷入循环中，一直返回空数据。针对这一点，Kafka的消费者在消费数据时会传入一个时长参数timeout，如果当前没有数据可供消费，consumer会等待一段时间之后再返回，这段时长即为timeout。 3.3.2 基础消费者 注意：在消费者代码中必须配置消费者组，命令行启动消费者不填写消费者组会被自动填写随机的消费者组。 1）编写代码 需要用到的类： KafkaConsumer：需要创建一个消费者对象，用来消费数据 ConsumerConfig：获取所需的一系列配置参数 ConsuemrRecord：每条数据都要封装成一个ConsumerRecord对象 为了使我们能够专注于自己的业务逻辑，Kafka提供了自动提交offset的功能。 自动提交offset的相关参数： enable.auto.commit：是否开启自动提交offset功能 auto.commit.interval.ms：自动提交offset的时间间隔 2）消费者自动提交和手动提交offset import org.apache.kafka.clients.consumer.ConsumerConfig; import org.apache.kafka.clients.consumer.ConsumerRecord; import org.apache.kafka.clients.consumer.ConsumerRecords; import org.apache.kafka.clients.consumer.KafkaConsumer; import org.apache.kafka.common.serialization.StringDeserializer; import java.time.Duration; import java.util.Collections; import java.util.Properties; public class MyConsumer2 { public static void main(String[] args) { // 1.创建消费者的配置对象 Properties properties = new Properties(); // 2.给消费者配置对象添加参数 必须设置 properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "kb129:9092"); // 配置反序列化 必须设置 properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class); properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class); /* * earliest:当各分区下有已提交的offset时，从提交的offset开始消费（第二次消费）；无提交的offset时（等于第一次消费），从头开始消费 * latest: 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，仅消费新消息 * none: 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，抛出异常 */ properties.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG,"earliest"); //设置是否自动提交，获取数据的状态，false为手动提交 properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG,"false"); //设置提交的时间间隔，1000ms提交一次 properties.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG,"1000"); // 配置消费者组 必须设置 properties.put(ConsumerConfig.GROUP_ID_CONFIG, "threadGroup1"); for (int i = 0; i < 3; i++) { new Thread(new Runnable() { @Override public void run() { // 创建消费者对象 KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<String, String>(properties); // 连接topic主题 kafkaConsumer.subscribe(Collections.singleton("xxww")); // 拉取数据打印 while (true) { ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofMillis(100)); for (ConsumerRecord<String, String> record : consumerRecords) { System.out.println(Thread.currentThread().getName() +" topic: " + record.topic() + " partition: "+ record.partition() +" offset:"+record.offset() +" value:"+record.value()+" timestamp:"+record.timestamp()); } //手动提交offset代码 //kafkaConsumer.commitAsync(); } } }).start(); } } } 3.3.3 重置Offset auto.offset.reset = earliest | latest | none | 当Kafka中没有初始偏移量（消费者组第一次消费）或服务器上不再存在当前偏移量时（例如该数据已被删除），该怎么办： （1）earliest：自动将偏移量重置为最早的偏移量 （2）latest(默认值)：自动将偏移量重置为最新偏移量 （3）none：如果未找到消费者组的先前偏移量，则向消费者抛出异常 数据漏消费和重复消费分析 我们知道消息的拉取是根据poll（）方法中的逻辑来处理的，这个poll（）方法中的逻辑对于普通的开发人员而言是一个黑盒，无法精确地掌控其消费的起始位置。提供的auto.offset.reset 参数也只能在找不到消费位移或位移越界的情况下粗粒度地从开头或末尾开始消费。无论怎么设置auto.offset.reset都有可能会造成数据的漏消费或者重复消费。先提交offset后消费，有可能造成数据的漏消费；而先消费后提交offset，有可能会造成数据的重复消费。 使用seek，记录上次消费offset，即可精准消费，这种指定方式的特点：可以立刻从offset消费，即使上次已经消费到末尾，也能马上回到特定的offset import org.apache.kafka.clients.consumer.ConsumerConfig; import org.apache.kafka.clients.consumer.ConsumerRecord; import org.apache.kafka.clients.consumer.ConsumerRecords; import org.apache.kafka.clients.consumer.KafkaConsumer; import org.apache.kafka.common.TopicPartition; import org.apache.kafka.common.serialization.StringDeserializer; import java.time.Duration; import java.util.Collections; import java.util.HashSet; import java.util.Properties; import java.util.Set; public class MyConsumerSeek { public static void main(String[] args) { // 1.创建消费者的配置对象 Properties properties = new Properties(); // 2.给消费者配置对象添加参数 必须设置 properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "kb129:9092"); // 配置反序列化 必须设置 properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class); properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class); /* * earliest:当各分区下有已提交的offset时，从提交的offset开始消费（第二次消费）；无提交的offset时（第一次消费），从头开始消费 * latest: 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，消费新消息 * none: 当各分区下有已提交的offset时，从提交的offset开始消费；无提交的offset时，抛出异常 */ properties.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG,"earliest"); //设置是否自动提交，获取数据的状态，false为手动提交 properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG,"false"); //设置提交的时间间隔，1000ms提交一次 properties.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG,"1000"); // 配置消费者组 必须设置 properties.put(ConsumerConfig.GROUP_ID_CONFIG, "groupA3"); // 创建消费者对象 KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<String, String>(properties); // 连接主题 kafkaConsumer.subscribe(Collections.singleton("kb23")); Set<TopicPartition> assignment = new HashSet<TopicPartition>(); while (assignment.size() == 0){ kafkaConsumer.poll(Duration.ofMillis(1000)); assignment = kafkaConsumer.assignment(); } for (TopicPartition topicPartition : assignment) { System.out.println("topic: " + topicPartition.topic() + " partition: "+ topicPartition.partition()); // 精准从某某分区，某某offset开始消费，partition0:offset1 1:2 2:0 if (topicPartition.partition() == 0){ kafkaConsumer.seek(topicPartition, 1); } else if (topicPartition.partition() == 1) { kafkaConsumer.seek(topicPartition, 2); } else if (topicPartition.partition() == 2) { kafkaConsumer.seek(topicPartition, 0); } } // 拉取数据打印 while (true) { ConsumerRecords<String, String> records = kafkaConsumer.poll(Duration.ofMillis(100)); for (ConsumerRecord<String, String> record : records) { System.out.println("topic: " + record.topic() + " partition: "+ record.partition() +" offset:"+record.offset()+" value:"+record.value()+" timestamp:"+record.timestamp()); } /*//手动提交代码 kafkaConsumer.commitAsync();*/ } } } 3.3.4 offset的维护 由于consumer在消费过程中可能会出现断电宕机等故障，consumer恢复后，需要从故障前的位置的继续消费，所以consumer需要实时记录自己消费到了哪个offset，以便故障恢复后继续消费。 Kafka 0.9版本之前，consumer默认将offset保存在Zookeeper中，从0.9版本开始，consumer默认将offset保存在Kafka一个内置的topic中，该topic为__consumer_offsets。 3.3.5 分区分配策略 一个consumer group中有多个consumer，一个 topic有多个partition，所以必然会涉及到partition的分配问题，即确定那个partition由哪个consumer来消费。 Kafka有两种分配策略，RoundRobin，Range。 1）RoundRobin 2）Range 修改主题first为7个分区 [atguigu@hadoop102 ~]$ kafka-topics.sh --bootstrap-server hadoop102:9092 --alter --topic first --partitions 7  复制基础消费者一个三个，消费者组都是“test”，同时启动3个消费者。  启动生产者，发送500条消息，随机发送到不同的分区： // 4. 调用send方法发送消息         for (int i = 0; i < 500; i++) {             kafkaProducer.send(new ProducerRecord<>("first","atguigu" + i));             // 避免发送到同一个分区             Thread.sleep(2);         }   观看3个消费者分别消费哪些分区的数据 默认使用Range的分区分配策略，可以通过参数"partition.assignment.strategy"的值进行修改，可以使用多个分区分配策略。 注意：3个消费者都应该修改分区分配策略，避免出现错误，如果重启失败，则全部停止消费者等一会再启动即可 // 修改分区分配策略         properties.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG, "org.apache.kafka.clients.consumer.RoundRobinAssignor");   重启3个消费者，重复发送消息的步骤，观看分区结果 3）Sticky 特殊的分配策略StickyAssignor，Kafka从0.11.x版本开始引入这种分配策略，在出现同一消费者组内消费者出现问题的时候，会进行使用。 在上个演示基础上，停止2号消费者，重新发送500条消息 可以看到分区重新进行了划分，此时没有使用粘性分区器。 修改分区分配策略 注意：3个消费者都应该注释掉，之后重启3个消费者，如果出现报错，全部停止等会再重启，或者修改为全新的消费者组 // 修改分区分配策略         ArrayList<String> strings = new ArrayList<>();         strings.add("org.apache.kafka.clients.consumer.RoundRobinAssignor");         strings.add("org.apache.kafka.clients.consumer.StickyAssignor");         properties.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG, strings);        使用同样的生产者发送500条消息 可以看到按照roundRobin规则划分分区   停止掉0号消费者，重新发送消息观看结果 保留了上一次分配中对于消费者1号和2号的所有分配结果，只分配0号原先消费的分区，1号消费2 、5 、3号分区，2号消费1、 4 、 6 、0号分区。

3.4 Kafka 高效读写数据 1，分区 1）顺序写磁盘 Kafka的producer生产数据，要写入到log文件中，写的过程是一直追加到文件末端，为顺序写。官网有数据表明，同样的磁盘，顺序写能到600M/s，而随机写只有100K/s。这与磁盘的机械机构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。 2）应用 Pagecache Kafka数据持久化是直接持久化到Pagecache中，这样会产生以下几个好处： I/O Scheduler 会将连续的小块写组装成大块的物理写从而提高性能 I/O Scheduler 会尝试将一些写操作重新按顺序排好，从而减少磁盘头的移动时间 充分利用所有空闲内存（非 JVM 内存）。如果使用应用层 Cache（即 JVM 堆内存），会增加 GC 负担 读操作可直接在 Page Cache 内进行。如果消费和生产速度相当，甚至不需要通过物理磁盘（直接通过 Page Cache）交换数据 如果进程重启，JVM 内的 Cache 会失效，但 Page Cache 仍然可用 尽管持久化到Pagecache上可能会造成宕机丢失数据的情况，但这可以被Kafka的Replication机制解决。如果为了保证这种情况下数据不丢失而强制将 Page Cache 中的数据 Flush 到磁盘，反而会降低性能。 3）零复制技术

kafka数据可靠性深度解读：kafka数据可靠性深度解读_朱小厮的博客-CSDN博客

4. Kafka-eagle（kafka监控）

解压至当前目录 [root@node1 install]# tar -zxf ./kafka-eagle-bin-3.0.1.tar.gz 进入目录再次解压至soft目录下 [root@node1 install]# cd ./kafka-eagle-bin-3.0.1 [root@node1 kafka-eagle-bin-3.0.1]# tar -xvf ./efak-web-3.0.1-bin.tar.gz -C /opt/soft/ [root@node1 soft]# mv ./efak-web-3.0.1/ efak

配置环境变量并source # kafkaEagle export KE_HOME=/opt/soft/efak export PATH=$KE_HOME/bin:$PATH

更改kafka启动命令脚本 [root@node1 ~]# vim /opt/soft/kafka212/bin/kafka-server-start.sh 28 if [ "x$KAFKA_HEAP_OPTS" = "x" ]; then 29     #export KAFKA_HEAP_OPTS="-Xmx1G -Xms1G" 30     export KAFKA_HEAP_OPTS="-server -Xms2G -Xmx2G -XX:PermSize=128m -XX:+UseG1GC -X    X:MaxGCPauseMillis=200 -XX:ParallelGCThreads=8 -XX:ConcGCThreads=5 -XX:InitiatingHe    apOccupancyPercent=70" 31     export JMX_PORT="9999" 32 fi 更改完成后分发至其他节点 [root@node1 ~]# scp /opt/soft/kafka212/bin/kafka-server-start.sh root@node2:/opt/soft/kafka212/bin/ [root@node1 ~]# scp /opt/soft/kafka212/bin/kafka-server-start.sh root@node3:/opt/soft/kafka212/bin/

更改efak内部配置文件 [root@node1 install]# vim /opt/soft/efak/conf/system-config.properties 5 efak.zk.cluster.alias=cluster1 6 cluster1.zk.list=node1:2181,node2:2181,node3:2181 52 cluster1.efak.offset.storage=kafka #删除53行多余的集群 122 efak.driver=com.mysql.cj.jdbc.Driver 123 efak.url=jdbc:mysql://192.168.142.129:3306/ke?useUnicode=true&characterEncoding=UTF    -8&zeroDateTimeBehavior=convertToNull 124 efak.username=root 125 efak.password=123456

启动zookeeper集群 启动kafka集群 在node1上启动efak [root@node1 ~]# ke.sh start 进入网页，输入用户名密码可查看kafka集群实时状态

结合API模拟生产者和消费者，生产数据和消费数据 （1）页面生产消息至指定topic，可在控制台实时查看消费情况 （2）可通过ksql查看分区内offset数据 （3）查看消费者实时消费情况