kafka使用

Kafka

一、基础概念

1. MQ(消息队列)

Message Queue（MQ），消息队列中间件。很多人都说：MQ 通过将消息的发送和接收分离来实现应用程序的异步和解偶，这个给人的直觉是——MQ 是异步的，用来解耦的，但是这个只是 MQ 的效果而不是目的。MQ 真正的目的是为了通讯，屏蔽底层复杂的通讯协议，定义了一套应用层的、更加简单的通讯协议。一个分布式系统中两个模块之间通讯要么是HTTP，要么是自己开发的（rpc） TCP，但是这两种协议其实都是原始的协议。HTTP 协议很难实现两端通讯——模块 A 可以调用 B，B 也可以主动调用 A，如果要做到这个两端都要背上WebServer，而且还不支持⻓连接（HTTP 2.0 的库根本找不到）。TCP 就更加原始了，粘包、心跳、私有的协议，想一想头皮就发麻。MQ 所要做的就是在这些协议之上构建一个简单的“协议”——生产者/消费者模型。MQ 带给我的“协议”不是具体的通讯协议，而是更高层次通讯模型。它定义了两个对象——发送数据的叫生产者；接收数据的叫消费者， 提供一个SDK 让我们可以定义自己的生产者和消费者实现消息通讯而无视底层通讯协议

消息队列的中间件选型：

1. rabbitMQ：较简单，但内部功能性强
2. rocketMQ：阿里根据kafka创建的消息队列，性能与kafka比肩，封装了更多的功能
3. kafka：全球消息处理性能最快的一款MQ
4. zeroMQ

1.1 有Broker的MQ

这个流派通常有一台服务器作为 Broker，所有的消息都通过它中转。生产者把消息发送给它就结束自己的任务了，Broker 则把消息主动推送给消费者（或者消费者主动轮询）

(1) 重Topic

kafka、JMS（ActiveMQ）就属于这个流派，生产者会发送 key 和数据到 Broker，由 Broker比较 key 之后决定给哪个消费者。这种模式是我们最常见的模式，是我们对 MQ 最多的印象。在这种模式下一个 topic 往往是一个比较大的概念，甚至一个系统中就可能只有一个topic，topic 某种意义上就是 queue，生产者发送 key 相当于说：“hi，把数据放到 key 的队列中”

虽然架构一样但是 kafka 的性能要比 jms 的性能不知道高到多少倍，所以基本这种类型的MQ 只有 kafka 一种备选方案。如果你需要一条暴力的数据流（在乎性能而非灵活性）那么kafka 是最好的选择

(2) 轻Topic

这种的代表是 RabbitMQ（或者说是 AMQP）。生产者发送 key 和数据，消费者定义订阅的队列，Broker 收到数据之后会通过一定的逻辑计算出 key 对应的队列，然后把数据交给队列

这种模式下解耦了 key 和 queue，在这种架构中 queue 是非常轻量级的（在 RabbitMQ 中它的上限取决于你的内存），消费者关心的只是自己的 queue；生产者不必关心数据最终给谁只要指定 key 就行了，中间的那层映射在 AMQP 中叫 exchange（交换机）

AMQP 中有四种 exchange

• Direct exchange：key 就等于 queue
• Fanout exchange：无视 key，给所有的 queue 都来一份
• Topic exchange：key 可以用“宽字符”模糊匹配 queue
• Headers exchange：无视 key，通过查看消息的头部元数据来决定发给那个
• queue（AMQP 头部元数据非常丰富而且可以自定义）

这种结构的架构给通讯带来了很大的灵活性，我们能想到的通讯方式都可以用这四种exchange 表达出来。如果你需要一个企业数据总线（在乎灵活性）那么 RabbitMQ 绝对的值得一用

1.2 无Broker 的MQ

无 Broker 的 MQ 的代表是 ZeroMQ。该作者非常睿智，他非常敏锐的意识到——MQ 是更高级的 Socket，它是解决通讯问题的。所以 ZeroMQ 被设计成了一个“库”而不是一个中间件，这种实现也可以达到——没有 Broker 的目的

节点之间通讯的消息都是发送到彼此的队列中，每个节点都既是生产者又是消费者。ZeroMQ做的事情就是封装出一套类似于 Socket 的 API 可以完成发送数据，读取数据

ZeroMQ 其实就是一个跨语言的、重量级的 Actor 模型邮箱库。你可以把自己的程序想象成一个 Actor，ZeroMQ 就是提供邮箱功能的库；ZeroMQ 可以实现同一台机器的 RPC 通讯也可以实现不同机器的 TCP、UDP 通讯，如果你需要一个强大的、灵活、野蛮的通讯能力，别犹豫 ZeroMQ

2. Kafka介绍

Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的 （replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理 大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、 Storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编 写，Linkedin于 2010 年贡献给了Apache基金会并成为顶级开源 项目。

基本概念

名称	解释
Broker	消息中间件处理节点，⼀个Kafka节点就是⼀个broker，⼀个或者多个Broker可以组成⼀个Kafka集群
Topic	Kafka根据topic对消息进⾏归类，发布到Kafka集群的每条消息都需要指定⼀个topic
Producer	消息⽣产者，向Broker发送消息的客户端
Consumer	消息消费者，从Broker读取消息的客户端
ConsumerGroup	每个Consumer属于⼀个特定的Consumer Group，⼀条消息可以被多个不同的Consumer Group消费，但是⼀个Consumer Group中只能有⼀个Consumer能够消费该消息
Partition	物理上的概念，⼀个topic可以分为多个partition，每个partition内部消息是有序的

二、Kafka基本使用

1. 环境准备

• 安装 jdk

• 安装 zookeeper

  • 创建目录mkdir /usr/local/zookeeper

  • 将压缩包解压到此目录tar -zxvf xxxxx.gz

  • 将conf目录下的zoo_sample.cfg重命名为zoo.cfg，并修改内容

    • cp conf/zoo_sample.cfg conf/zoo.cfg

    • # zookeeper时间配置中的基本单位 (毫秒)
      tickTime=2000
      # 允许follower初始化连接到leader最⼤时⻓，它表示tickTime时间倍数
      即:initLimit*tickTime
      initLimit=10
      # 允许follower与leader数据同步最⼤时⻓,它表示tickTime时间倍数
      syncLimit=5
      #zookeper 数据存储⽬录及⽇志保存⽬录（如果没有指明dataLogDir，则⽇>志也保存在这个
      ⽂件中）
      dataDir=/tmp/zookeeper
      #对客户端提供的端⼝号
      clientPort=2181
      #单个客户端与zookeeper最⼤并发连接数
      maxClientCnxns=60
      # 保存的数据快照数量，之外的将会被清除
      autopurge.snapRetainCount=3
      #⾃动触发清除任务时间间隔，⼩时为单位。默认为0，表示不⾃动清除。
      autopurge.purgeInterval=1
      "conf/zoo.cfg" 18L, 748C
      

  • 启动，切换到bin目录中

    • ./zkServer.sh start

  • 检查是否启动成功，用zookeeper客户端连接服务器

    • ./zkCli.sh

  • 开启防火墙端口

    • # 开放2181端口
      firewall-cmd --zone-public --add-port=2181/tcp --permanent
      # 重启防火墙
      firewall-cmd --reload
      # 查看已开启的端口
      firewall-cmd --zone-public --list-ports
      

• 安装 kafka[当前使用的是2.4.1] ，官网下载：https://kafka.apache.org/downloads

  • 创建目录mkdir /usr/local/kafka

  • 将压缩包解压至此目录tar -zxvf xxxxx.gz

  • 修改配置文件：/usr/local/kafka/kafka2.11-2.4/config/server.properties

    • #找到并修改如下配置
      #broker.id属性在kafka集群中必须要是唯一
      broker.id= 0
      #kafka部署的机器ip和提供服务的端口号
      listeners=PLAINTEXT://192.168.40.132:9092
      #kafka的消息存储文件
      log.dir=/usr/local/data/kafka-logs
      #kafka连接zookeeper的地址
      zookeeper.connect=192.168.40.131:2181
      

2. 启动kafka服务器

条件：在另一台机器先启动zookeeper并开放其端口；本机器有jdk环境

切换到kafka的bin目录，启动命令

./kafka-server-start.sh -daemon ../config/server.properties

验证是否启动成功：进入到zk中的结点查看id为0的broker是否存在

ls /brokers/ids/

或者直接查看进程

ps -aux | grep server.properties
# 出现一堆信息的一个kafka进程即是成功

server.properties核心配置

Property	Default	Description
broker.id	0	每个broker都可以⽤⼀个唯⼀的⾮负整数id进⾏标识；这个id可以作为broker的“名字”，你可以选择任意你喜欢的数字作为id，只要id是唯⼀的即可。
log.dirs	/tmp/kafka-logs	kafka存放数据的路径。这个路径并不是唯⼀的，可以是多个，路径之间只需要使⽤逗号分隔即可；每当创建新partition时，都会选择在包含最少partitions的路径下进⾏。
listeners	PLAINTEXT://192.168.65.60:9092	server接受客户端连接的端⼝，ip配置kafka本机ip即可
zookeeper.connect	localhost:2181	zooKeeper连接字符串的格式为：hostname:port，此处hostname和port分别是ZooKeeper集群中某个节点的host和port；zookeeper如果是集群，连接⽅式为hostname1:port1, hostname2:port2,hostname3:port3
log.retention.hours	168	每个⽇志⽂件删除之前保存的时间。默认数据保存时间对所有topic都⼀样。
num.partitions	1	创建topic的默认分区数
default.replication.factor	1	⾃动创建topic的默认副本数量，建议设置为⼤于等于2
min.insync.replicas	1	当producer设置acks为-1时，min.insync.replicas指定replicas的最⼩数⽬（必须确认每⼀个repica的写数据都是成功的），如果这个数⽬没有达到，producer发送消息会产⽣异常
delete.topic.enable	false	是否允许删除主题

3 创建主题Topic

执行以下命令创建名为“test”的topic，这个topic只有一个partition，并且备份因子也设置为1

./kafka-topics.sh --create --zookeeper 192.168.40.131:2181 --replication-factor 1 --partitions 1 --topic test

查看当前kafka内有哪些topic

./kafka-topics.sh --list --zookeeper 192.168.40.131:2181

4 发送消息

./kafka-console-producer.sh --broker-list 192.168.40.132:9092 --topic test

5 消费消息

1. 从最后一条消息的偏移量+1开始消费

./kafka-console-consumer.sh --bootstrap-server 192.168.40.132:9092 --topic test

2. 从头开始消费

./kafka-console-consumer.sh --bootstrap-server 192.168.40.132:9092 --from-beginning --topic test

注意：

• 消息会被存储
• 消息顺序存储
• 消息有偏移量
• 可以指定偏移量进行消费

6. 关于消息的细节

• 生产者将消息发送给broker，broker会将消息保存在本地的日志文件中
• /usr/local/kafka/data/kafka-logs/主题-分区/00000000.log
• 消息的保存是有序的，通过offset偏移量来描述消息的有序性
• 消费者消费消息时也是通过offset来描述当前要消费的那条消息的位置

7. 单播消息

同组中任意两个消费者不可同时消费同一个Topic中的消息

./kafka-console-consumer.sh --bootstrap-server 192.168.40.132:9092 --consumer-property group.id=testGroup --topic test

8. 多播消息

不同组的消费者可以同时消费同一个Topic中的消息

若要让一条消息被多个消费者消费，则可以使用多播模式

./kafka-console-consumer.sh --bootstrap-server 192.168.40.132:9092 --consumer-property group.id=testGroup1 --topic test

./kafka-console-consumer.sh --bootstrap-server 192.168.40.132:9092 --consumer-property group.id=testGroup2 --topic test

9. 查看消费组的详细信息

# 查看当前主题下有哪些消费组
./kafka-consumer-groups.sh --bootstrap-server 192.168.40.132:9092 --list
# 查看消费组中的具体信息：比如当前偏移量、最后一条消息的偏移量、堆积的消息数量
./kafka-consumer-groups.sh --bootstrap-server 192.168.40.132:9092 --describe --group testGroup

• Currennt-offset: 当前消费组的已消费偏移量
• Log-end-offset: 主题对应分区消息的结束偏移量(HW)
• Lag: 当前消费组未消费的消息数

三、Kafka中主题和分区的概念

1. 主题Topic

逻辑概念，用来将消息进行分类，是一个类别的名称

2. partition分区

若topic中的消息非常多，几T级别，因为消息是要存储到log日志中的，为了解决此问题，提出了partition分区概念

优点：

• 分区存储可以解决统一存储文件过大的问题
• 提高了读写的吞吐量：读和写可以同时在多个分区中进行

为一个主题创建多个分区

./kafka-topics.sh --create --zookeeper 192.168.40.131:2181 --partitions 2 --topic test1

查看topipc的分区信息

./kafka-topics.sh --describe --zookeeper 192.168.40.131:2181 --topic test1

3. kafka中消息日志文件中保存的内容

• 000000.log：保存消息

• 分区时test主题消息实际上是存在data/kafka-logs/test-0 和 test-1中的0000000.log文件中

• __consumer_offsets-49:

  • 消费者消费某个主题的偏移量。

  • 每个消费者定期将自己消费分区的offset提交给kafka内部topic：__consumer_offsets，提交过去的 时候，key是consumerGroupId+topic+分区号，value就是当前offset的值，kafka会定 期清理topic里的消息，最后就保留最新的那条数据 因为__consumer_offsets可能会接收高并发的请求，kafka默认给其分配 50 个分区(可以 通过offsets.topic.num.partitions设置)，这样可以通过加机器的方式抗大并发。

  • consumer消费的offset要提交到__consumer_offsets的哪个分区公式：hash(consumerGroupId) % __consumer_offsets主题的分区数

• 文件中保存的消息默认保存7天，到期自动删除

四、Kafka集群

1. 搭建kafka集群，3个broker

1.1 环境

准备3个server.properties文件

1. server.properties

   • broker.id=0
     listeners=PLAINTEXT://192.168.40.132:9092
     log.dir=/usr/local/data/kafka-logs
     

2. server1.properties

   • broker.id=1
     listeners=PLAINTEXT://192.168.40.132:9093
     log.dir=/usr/local/data/kafka-logs-1
     

3. server2.properties

   • broker.id=2
     listeners=PLAINTEXT://192.168.40.132:9094
     log.dir=/usr/local/data/kafka-logs-2
     

1.2 启动

./kafka-server-start.sh -daemon ../config/server.properties
./kafka-server-start.sh -daemon ../config/server1.properties
./kafka-server-start.sh -daemon ../config/server2.properties

1.3 验证

在zookeeper机器，使用其客户端执行命令验证

ls /brokers/ids

2 副本

副本是对分区的备份。在集群中，不同的副本会被部署在不同的broker上。下面例子：创建 1个主题， 2 个分区、 3 个副本。

./kafka-topics.sh --create --zookeeper 172.16.253.35:2181 --replication-factor 3 --partitions 2 --topic my-replicated-topic 

通过查看主题信息，其中的关键数据：

• replicas：当前副本存在的broker节点
• leader：副本里的概念
  • 每个partition都有一个broker作为leader。
  • 消息发送方要把消息发给leader所在broker，读写操作都发生在leader上
  • 接收到消息，其他follower通过poll的方式来同步数据。
• follower：leader处理所有针对这个partition的读写请求，并将数据同步到follower，如果leader所在的broker挂掉，经过主从选举，从众多follower中选举出一个新的leader。

3 broker、主题，分区，副本

• kafka集群中由多个broker组成
• 一个broker中存放一个topic的不同partition——副本

4 集群消息发送

./kafka-console-producer.sh --broker-list 172.16.253.38:9092,172.16.253.38:9093,172.16.253.38:9094 --topic my-replicated-topic

5 集群消息消费

./kafka-console-consumer.sh --bootstrap-server 172.16.253.38:9092,172.16.253.38:9093,172.16.253.38:9094 --from-beginning --topic my-replicated-topic

6 分区消费

• 一个partition可以被多个消费者消费，但任意两个消费者不能属于同一组，以此来保证消费的局部（partition内部）顺序性

• partition的数量决定了消费者的数量，同一个消费者组中的消费者舒朗不要超过partition的数量，否则多的消费者消费不到消息

• 如果消费者挂了，则会触发rebalance值，让其他消费者消费该分区

五、Kafka的Java客户端消费者

1. 引入依赖

<dependency>
    <groupId>org.apache.kafkagroupId>
    <artifactId>kafka-clientsartifactId>
    <version>2.4.1version>
dependency>

2. 生产者基本实现

public static void main(String[] args) throws ExecutionException, InterruptedException {
        String TOPIC_NAME = "test1";
        Properties properties = new Properties();
        properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "192.168.40.132:9092");
        // 把发送的key从字符串序列化转化为字节数
        properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
        // 把发送的value从字符串序列化转化为字节数组
        properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());

        //创建生产者
        Producer<String, String> producer = new KafkaProducer<String, String>(properties);
        //ProducerRecord三个参数：主题名，键（往哪个分区发送）， 消息
        //可以不指定分区，根据给定key使用hash算法计算发送分区
        // 指定分区后根据指定分区发送
        ProducerRecord<String, String> record = new ProducerRecord<String, String>(TOPIC_NAME, 0,"aaaa", "我丢");
        RecordMetadata metadata = producer.send(record).get();
        System.out.println("topic: "+metadata.topic()+", partition: "+metadata.partition()+", offset:  "+metadata.offset());
    }

3. 同步发送

生产者发送完消息后需等待broker返回ack，拿到ack后再发送下一条消息

如果生产者发送消息没有收到ack，则进入阻塞状态，阻塞3s还没有收到消息则重新发送消息，重试3次数为3次

• 发送会默认会重试 3 次，每次间隔100ms

RecordMetadata metadata = producer.send(record).get();
        System.out.println("topic: "+metadata.topic()+", partition: "+metadata.partition()+", offset:  "+metadata.offset());

生产者ack配置

同步发送消息时，ack有3中不同的选择：

1. ack=0：表示 kafka-cluster不需要任何broker收到消息就立即返回ack给生产者，效率最高，最易丢失消息
2. ack=1：默认，多副本之间的leader已经收到消息并写入到本地log中才会返回ack；性能均衡
3. ack=-1/all：有默认的配置min.insync.replicas=2（默认为1，推荐配置大于等于2），等于2时表示leader收到消息后与一个副本同步完成后才会返回ack，此时集群中有2个broker已完成数据的接收；最安全，性能最低

配置方式：

props.put(ProducerConfig.ACKS_CONFIG, "1");

4. 异步发送

生产者发送完一条消息后不管broker是否收到，都直接发送下一条消息

        // 异步发送消息
        producer.send(record, new Callback() {
            public void onCompletion(RecordMetadata metadata, Exception e) {
                if(e != null){
                    e.printStackTrace();
                }
                if(metadata!=null){
                    System.out.println("topic: "+metadata.topic()+", partition: "+metadata.partition()+", offset:  "+metadata.offset());
                }
            }
        });
		//主线程等待回调函数打印完再结束
        Thread.sleep(2000);
    }

5. 消息发送的缓冲区

• kafka默认创建爱你一个消息缓冲区，用来存放要发送的消息，缓冲区是32m

properties.put(ProducerConfig.BUFFER_MEMORY_CONFIG, 33554432);

• kafka本地线程会去缓冲区中一次拉取16k数据，发送到broker

properties.put(ProducerConfig.BATCH_SIZE_CONFIG, 16384);

• 拉取不到16k，间隔10ms也会发送出去

  properties.put(ProducerConfig.LINGER_MS_CONFIG, 10);
  

六、消费者实现

1. 消费者基本实现

public class MyConsumer {
    private final static String TOPIC_NAME = "test";
    private final static String CONSUMER_GROUP_NAME = "testGroup";

    public static void main(String[] args) {
        Properties props = new Properties();
        props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "192.168.40.132:9092");
// 消费分组名
        props.put(ConsumerConfig.GROUP_ID_CONFIG, CONSUMER_GROUP_NAME);
        props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
        props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
//创建一个消费者的客户端
        KafkaConsumer<String, String> consumer = new KafkaConsumer<String, String>(props);
// 消费者订阅主题列表
        consumer.subscribe(Collections.singletonList(TOPIC_NAME));

        while (true) {
            /*
             * poll() API 是拉取消息的⻓轮询
             */
            ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000));
            for (ConsumerRecord<String, String> record : records) {
                System.out.printf("收到消息：partition = %d,offset = %d, key =%s, value = %s%n", record.partition(), record.offset(), record.key(), record.value());
            }
        }
    }
}

2.消费者的提交方式

无论是自动提交还是手动提交都需要把所属的消费组+消费的某个主题+消费的某个分区及消费的偏移量这样的消息提交到集群的_consumer_offset主题里面

2.1 自动提交

消费者poll到消息后自动提交offset，之后再消费消息。

可能会丢消息。有可能提交后还未消费消息就挂了

// 是否自动提交offset，默认就是true
props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true");
// 自动提交offset的间隔时间
props.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000");

自动提交间隔1s

properties.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000");

2.2 手动提交

消息者在消息消费完后在手动提交offset

修改配置为false

props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "false");

2.2.1 手动同步提交

在消费完消息后调用同步提交的方法，当集群返回ack前一直阻塞，返回ack后表示提交成功，执行之后的逻辑代码

while (true) {
            /*
             * poll() API 是拉取消息的⻓轮询
             */
            ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000));
            for (ConsumerRecord<String, String> record : records) {
                System.out.printf("收到消息：partition = %d,offset = %d, key =%s, value = %s%n", record.partition(), record.offset(), record.key(), record.value());
                record.offset()
            }
            //所有的消息已消费完
            if(records.count() > 0){ // 如果还有消息
                // 手动提交offset，当前线程会阻塞到offset提交成功
                consumer.commitSync();
            }
        }

2.2.2 手动异步提交

消息消费完后提交，不需要等集群ack，直接执行后面逻辑，可以设置一个毁掉方法，供集群调用

if (records.count() > 0 ) {
// 手动异步提交offset，当前线程提交offset不会阻塞，可以继续处理后面的程序逻辑
consumer.commitAsync(new OffsetCommitCallback() {
@Override
public void onComplete(Map<TopicPartition, OffsetAndMetadata>offsets, Exception exception) {
          if (exception != null) {
              System.err.println("Commit failed for " + offsets);
              System.err.println("Commit failed exception: " +exception.getStackTrace());
          }
       }
  });
}

手动提交一般使用同步提交，因为提交完后一般也没有什么逻辑执行了

3 长轮询poll消息

默认情况下，消费者一次会poll500条消息

// 一次poll最大拉取消息的条数，可以根据消费速度的快慢来设置
properties.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, 500)

代码中设置了长轮询的时间是1000毫秒

while (true) {
    /*
     * poll() API 是拉取消息的⻓轮询
     */
    ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000));
    for (ConsumerRecord<String, String> record : records) {
        System.out.printf("收到消息：partition = %d,offset = %d, key =%s, value = %s%n", record.partition(), record.offset(), record.key(), record.value());
    }
}

• 如果一次poll到500条消息。就直接执行for循环进行消费
• 如果一次没有poll到500条消息，其时间在1秒内，那么长轮询继续poll
• 如果时间到达1s，无论是否poll到了500条消息，都直接执行for循环

如果两次poll的时间间隔超过30s，集群会认为该消费者的消费能力过弱，将其踢出消费者组，触发rebalance机制，将分区分配给其他消费者。rebalance机制会造成性能开销。可以通过设置参数让一次poll的消息条数少一点来避免rebalance机制

props.put(ConsumerConfig.MAX_POLL_INTERVAL_MS_CONFIG, 30 * 1000 );

4 消费者的健康状态检查

消费者每隔1s向kafka集群发送心跳，集群如果发现超过10s还没有发送心跳的消费者，则将其剔除消费者组，触发消费者组的rebalance机制，将该分区交给消费者组中的其他消费者进行消费

// consumer给broker发送心跳的间隔时间
properties.put(ConsumerConfig.HEARTBEAT_INTERVAL_MS_CONFIG, 1000);
//kafka如果超过10s没有收到消费者的心跳，则会把消费者剔除消费组，进行rebalance
properties.put(Consumer.SESSION_TIMOUT_MS_CONFIG, 10*1000);

5 指定分区消费

consumer.assign(Arrays.asList(new TopicPartition(TOPIC_NAME, 0 )));

6 消息回溯消费

// 从头开始消费
consumer.assign(Arrays.asList(new TopicPartition(TOPIC_NAME, 0 )));
consumer.seekToBeginning(Arrays.asList(new TopicPartition(TOPIC_NAME,0 )));

7 指定offset消费

consumer.assign(Arrays.asList(new TopicPartition(TOPIC_NAME, 0 )));
consumer.seek(new TopicPartition(TOPIC_NAME, 0 ), 10 );

8 从指定时间点消费

实际上是找到该时间点对应的offset，再根据此指定的offset进行消费

List<PartitionInfo> topicPartitions =consumer.partitionsFor(TOPIC_NAME);
//从 1 小时前开始消费
long fetchDataTime = new Date().getTime() - 1000 * 60 * 60 ;
Map<TopicPartition, Long> map = new HashMap<>();
for (PartitionInfo par : topicPartitions) {
    map.put(new TopicPartition(TOPIC_NAME, par.partition()),fetchDataTime);
}
Map<TopicPartition, OffsetAndTimestamp> parMap =consumer.offsetsForTimes(map);
for (Map.Entry<TopicPartition, OffsetAndTimestamp> entry :parMap.entrySet()) {
    TopicPartition key = entry.getKey();
    OffsetAndTimestamp value = entry.getValue();
    if (key == null || value == null) continue;
    Long offset = value.offset();
    System.out.println("partition-" + key.partition() +"|offset-" + offset);
    System.out.println();
    //根据消费里的timestamp确定offset
    if (value != null) {
        consumer.assign(Arrays.asList(key));
        consumer.seek(key, offset);
    }
}

9 新消费组的消费offset规则

新消费组中的消费者启动后，默认从当前分区最后一条消息offset+1开始消费

修改配置令新消费组的消费者第一次从头消费

• lastest：默认
• earliest：从头开始

properties.put(Consumer.AUTO_OFFSET_RESET_CONFIG, "earliest");

七、SpringBoot中使用Kafka

1. 引入依赖

<dependency>
    <groupId>org.springframework.kafkagroupId>
    <artifactId>spring-kafkaartifactId>
dependency>

2. 配置yml

server:
    port: 8080
spring:
    kafka:
        bootstrap-servers: 172.16.253.21: 9093
        producer: # 生产者
            retries: 3 # 设置大于 0 的值，则客户端会将发送失败的记录重新发送
            batch-size: 16384
            buffer-memory: 33554432
            acks: 1
            # 指定消息key和消息体的编解码方式
            key-serializer: org.apache.kafka.common.serialization.StringSerializer
            value-serializer: org.apache.kafka.common.serialization.StringSerializer
        consumer:
            group-id: default-group
            enable-auto-commit: false
            auto-offset-reset: earliest
            key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
            value-deserializer: org.apache.kafka.common.serialization.StringDeserializer
            max-poll-records: 500
        listener:
        # 当每一条记录被消费者监听器（ListenerConsumer）处理之后提交
        # RECORD
        # 当每一批poll()的数据被消费者监听器（ListenerConsumer）处理之后提交
        # BATCH
        # 当每一批poll()的数据被消费者监听器（ListenerConsumer）处理之后，距离上次提交时间大于TIME时提交
        # TIME
        # 当每一批poll()的数据被消费者监听器（ListenerConsumer）处理之后，被处理record数量大于等于COUNT时提交
        # COUNT
        # TIME | COUNT　有一个条件满足时提交
        # COUNT_TIME
        # 当每一批poll()的数据被消费者监听器（ListenerConsumer）处理之后, 手动调用Acknowledgment.acknowledge()后提交
        # MANUAL
        # 手动调用Acknowledgment.acknowledge()后立即提交，一般使用这种
        # MANUAL_IMMEDIATE
            ack-mode: MANUAL_IMMEDIATE
    redis:
        host: 172.16.253.21

3 Producer

@RestController
@RequestMapping("/msg")
public class ProducerBoot {
    private static final String TOPIC_NAME = "test";
    @Resource
    private KafkaTemplate<String, String> kafkaTemplate;
    @RequestMapping("/send")
    public void sendMsg(){
        kafkaTemplate.send(TOPIC_NAME, 0, "moyu", "我丢-boot");
    }
}

4 Consumer

@Component
public class ConsumerBoot {
    @KafkaListener(topics = "test", groupId = "testGroup")
    public void listenGroup(ConsumerRecord<String, String> record, Acknowledgment ack){
        System.out.println(record);
        System.out.println(record.value());
        System.out.println(ack);
        ack.acknowledge();  //手动发送ack
        System.out.println("===============");
    }

//    @KafkaListener(topics = "test", groupId = "testGroup")
//    public void listenGroups(ConsumerRecords records, JmsProperties.AcknowledgeMode ack){
//        records.forEach(record -> {
//            System.out.println(record);
//            System.out.println(record.value());
//            System.out.println(ack);
//        });
//        System.out.println("===============");
//    }
}

设置消费组，多个主题，指定分区，偏移量，该组消费者数量

    @KafkaListener(groupId = "testGroup", topicPartitions = {
            @TopicPartition(topic = "topic1", partitions = {"0", "1"}),
            @TopicPartition(topic = "topic2", partitions = "0",partitionOffsets = @PartitionOffset(partition = "1",initialOffset = "100"))}
            ,concurrency = "3")//concurrency就是创建同组下的消费者个数，就是并发消费数，建议小于等于分区总数
    public void listenGroup3(ConsumerRecord record,Acknowledgment ack) {
        String value = record.value();
        System.out.println(value);
        System.out.println(record);
        //手动提交offset
        ack.acknowledge();

八、Kafka集群中的Controller、Rebalance、HW

1. controller

**controller：**每个broker启动时会向zk创建一个临时序号节点，获得的序号最小的那个broker将会作为集群中的controlelr

作用：

• 当集群中有一个副本的leader挂掉，需要在集群中选举出一个新的leader，选举的规则是从isr集合中最左边获得
• 当集群中有broker新增或减少，controller会同步信息给其他broker
• 当集群中有分区新增或减少，controller会同步信息给其他broker

2. rebalance

前提：消费组中的消费者没有指明分区，若已指明分区，即分区与消费者一一绑定，则不会进行rebalance

触发条件：

消费组中的消费者与分区的关系发生变化，即消费者数量减少（挂掉）或增加（新增），或分区数量减少增加

分区分配策略：

1. range：根据公式计算得到每个消费者消费那几个分区。假设消费者数量为c，分区数为p：
   • 前 （c % p）个消费者依次消费（(c /p) + 1) 个分区
   • 之后的消费者依次消费（c/p）个分区
   • 例如：有3个消费者（序号为1-3），7个分区（序号为0-6）。则消费者1消费分区0-2；消费者2消费分区3-4；消费者3消费分区5-6
2. 轮询：分区依次循环被每个消费者消费
   • 例如：有3个消费者（序号为1-3），7个分区（序号为0-6）。则消费者1消费分区：0,3,6；消费者2消费分:1,4；消费者3消费分区：2,5
3. sticky：粘合策略，辅助策略
   • 在开启的状态下：如果需要rebalance，会在之前已分配的基础上根据之前的分配方案进行分配调整，不会改变之前的分配
   • 未开启：全部重新按照之前的分配策略分配，建议开启
   • 例如：按照range分配，有3个消费者（序号为1-3），7个分区（序号为0-6）。则消费者1消费分区0-2；消费者2消费分区3-4；消费者3消费分区5-6。当消费者3挂了后，触发rebalance机制
     • 开启了sticky：消费者1和2原有的分区对应不变，消费者3挂了则其对应的分区5-6分配为：消费者1：分区0-2和分区5；消费者2：分区3-4和分区6
     • 未开启sticky：全部重新分配：则消费者1：分区0-3；消费者2：分区4-6

3. HW和LEO

HW俗称高水位，HighWatermark的缩写，取一个partition对应的ISR中最小的LEO(log-end-offset)作为HW，consumer最多只能消费到HW所在的位置。另外每个replica都有HW,leader和follower各自负责更新自己的HW的状态。对于leader新写入的消息，consumer不能立刻消费，leader会等待该消息被所有ISR中的replicas同步后更新HW，此时消息才能被consumer消费。这样就保证了如果leader所在的broker失效，该消息仍然可以从新选举的leader中获取。

防丢失，防消息不一致

九、Kafka线上问题优化

1. 防止消息丢失

生产者：同步发送；ack设置为1或all并设置同步的分区数>=；

消费者：手动提交

2. 防止消息重复消费

幂等性：多次访问结果一样。

对于rest的请求：

​ 幂等：get、put、delete；非幂等：post

在消费者端解决，保证幂等性：

• mysql 插入业务id作为主键，主键是唯一的，所以一次只能插入一条
• 使用redis或zk的分布式锁（主流的方案），以业务id为锁

3. 顺序消费

• 生产者：保证消息按顺序发送，且消息不丢失–使用同步发送，确保发送成功在发送下一个消息；ack设置为非0
• 消费者：主题只能设置一个分区，消费组中只能有一个消费者

是一个场景不多：牺牲了性能

4. 解决消息积压

消息积压：消费速度远小于生产速度，消息积压，寻址越来越慢，性能越来越差，导致整个kafka对外提供的服务性能很差，造成其他服务性能降低

解决方案：

• 方案一：在一个消费者中启动多个线程，让多个线程同时消费。——提升一个消费者的消费能力（增加分区增加消费者）。
• 方案二：如果方案一还不够的话，这个时候可以启动多个消费者，多个消费者部署在不同的服务器上。其实多个消费者部署在同一服务器上也可以提高消费能力——充分利用服务器的cpu资源。
• 方案三：让一个消费者去把收到的消息往另外一个topic上发，另一个topic设置多个分区和多个消费者 ，进行具体的业务消费。

5. 延迟队列

延迟队列的应用场景：在订单创建成功后如果超过 30 分钟没有付款，则需要取消订单，此时可用延时队列来实现

• 创建多个topic，每个topic表示延时的间隔
  • topic_5s: 延时5s执行的队列
  • topic_1m: 延时 1 分钟执行的队列
  • topic_30m: 延时 30 分钟执行的队列
• 消息发送者发送消息到相应的topic，并带上消息的发送时间
• 消费者订阅相应的topic，消费时轮询消费整个topic中的消息
• 如果消息的发送时间，和消费的当前时间超过预设的值，比如 30 分钟（前提是未支付）
  • 已超过：数据库修改订单装填为已取消
  • 未超过：记录当前消息的offset，并不再消费后的消息。等待1分钟，继续消费该offset处的消息，判断时间是否已满足预设值

十、Kafka-eagle监控平台

1. 官网下载安装包

http://www.kafka-eagle.org/

2. 安装jdk

3. 解压后修改配置文件 system-config.properties

# 配置zk  去掉cluster2
efak.zk.cluster.alias=cluster1
cluster1.zk.list=172.16.253.35:2181
# cluster2.zk.list=xdn10:2181,xdn11:2181,xdn12:2181

# 配置mysql
kafka.eagle.driver=com.mysql.cj.jdbc.Driver
kafka.eagle.url=jdbc:mysql://172.16.253.22:3306/ke?useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull
kafka.eagle.username=root
kafka.eagle.password= 123456

4. 修改/etc/profile

export  JAVA_HOME=/usr/local/jdk/jdk1.8.0_191
CLASSPATH=.:$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/dt.jar
export KE_HOME=/home/aisys/efak-web-2.0.9
export PATH=$PATH:$KE_HOME/bin:$JAVA_HOME/bin

5. 进入bin目录，为ks.sh增加可执行权限

chomd +x ke.sh

6. 启动kafka-eagle

./k