springboot整合kafka

一、概述

在深入理解Kafka之前，先介绍一下Kafka中的术语。下图展示了Kafka的相关术语以及之间的关系：

上图中一个topic配置了3个partition。Partition1有两个offset：0和1。Partition2有4个offset。Partition3有1个offset。副本的id和副本所在的机器的id恰好相同。

如果一个topic的副本数为3，那么Kafka将在集群中为每个partition创建3个相同的副本。集群中的每个broker存储一个或多个partition。多个producer和consumer可同时生产和消费数据。

1、broker

Kafka 集群包含一个或多个服务器，服务器节点称为broker。

broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。

如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。

如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。

2、Topic

每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）

类似于数据库的表名

3、Partition

topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。

4、Producer

生产者即数据的发布者，该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。

5、Consumer

消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。

6、Consumer Group

每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。

如果分区数大于或者等于组中的消费者实例数，那自然没有什么问题，无非一个消费者会负责多个分区，（PS：当然，最理想的情况是二者数量相等，这样就相当于一个消费者负责一个分区）；但是，如果消费者实例的数量大于分区数，那么按照默认的策略（PS：之所以强调默认策略是因为你也可以自定义策略），有一些消费者是多余的，一直接不到消息而处于空闲状态。

Kafka分区分配策略

在 Kafka 内部存在两种默认的分区分配策略：Range 和 RoundRobin。当以下事件发生时，Kafka 将会进行一次分区分配：

6.1RoundRobin（轮循分配）：

这个分区分配策略简单来说就是列出所有的分区，然后和消费线程之间进行循环的分配即可。

如果你需要使用该分配策略，你需要满足所有的消费线程都是消费相同的topic，且每个消费者之间的消费线程数是一样的。

6.2Range（范围策略）

上述简单来说就是分区总数/消费线程数，如果有余，则表明有的消费线程之间分配的分区不均匀，那么这个多出来的分区会给前几个消费线程处理。

比如上述5个分区，2个comsumer,4个消费线程，则5/4=1，这个表明如果4个消费线程均分5个分区还会多出一个分区，

那么这个多出的额外分区就会给前面的消费线程处理，所以它会把第一个分区先给到c1-0消费线程消费。

也可以这样的认为分配：

5/4余1，则分配规则为2,1,1,1，对应的消费线程为C1-0,C1-1,C2-0,C2-1

如果是6个分区的话：

6/4余2，则分配规则为2,2,1,1，对应的消费线程为C1-0,C1-1,C2-0,C2-1

7、Leader

每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。

8、Follower

Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。

二、kafka与RabbitMq的区别

1、异同点

1.1架构模型

RabbitMQ遵循AMQP协议，RabbitMQ的broker由Exchange,Binding,queue组成，其中exchange和binding组成了消息的路由键；客户端Producer通过连接channel和server进行通信，Consumer从queue获取消息进行消费（长连接，queue有消息会推送到consumer端，consumer循环从输入流读取数据）。rabbitMQ以broker为中心。

Kafka遵从一般的MQ结构，producer，broker，consumer，以consumer为中心，消息的消费信息保存的客户端consumer上，consumer根据消费的点，从broker上批量pull数据。
 

1.2消息确认机制

RabbitMQ具有生产者confirm机制以及消费者的消息应答机制ack。

Kafka不具有应答机制。

1.3消息的顺序

RabbitMQ中，在一个队列里面，rabbitmq的消息是严格顺序的，按照先进先出。

Kafka中，在同一个partition中消息是有序的，但是生产者put到Kafka中数据会分布在不同的partition中，所有总体是无序的。

1.4吞吐量

根据测试，RabbitMQ在不使用ACK机制的，Msg大小为1K的情况下，QPS可达6W＋。再双方ACK机制，Msg大小为1K的情况下，QPS瞬间降到了1W＋。

Kafka具有巨大的吞吐量，数据的存储以及获取是本地磁盘的批量处理，可以达到百万/s。

1.5可靠性

RabbitMQ使用了MirrorQueue的机制，也可以做到多个机器进行热备。

Kafka的broker支持主备模式。

1.6持久化

RabbitMQ支持持久化。

Kafka 是一个持久性消息存储。

2、使用场景

1.RabbitMQ的消息应当尽可能的小，并且只用来处理实时且要高可靠性的消息。 2.消费者和生产者的能力尽量对等，否则消息堆积会严重影响RabbitMQ的性能。 3.集群部署，使用热备，保证消息的可靠性。

1.应当有一个非常好的运维监控系统，不单单要监控Kafka本身，还要监控Zookeeper。(kafka强烈的依赖于zookeeper,如果zookeeper挂掉了，那么Kafka也不行了)
 
2.对消息顺序不依赖，且不是那么实时的系统。
 
3.对消息丢失并不那么敏感的系统。
 
4.从 A 到 B 的流传输，无需复杂的路由，最大吞吐量可达每秒 100k 以上。

三、Spring Boot整合Kafaka

1、Maven准备

       <dependency>
            <groupId>org.springframework.kafka</groupId>
            <artifactId>spring-kafka</artifactId>
            <version>1.0.0.RELEASE</version>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>

2、配置文件

#============== kafka ===================
# 指定kafka 代理地址，可以多个
spring.kafka.bootstrap-servers=192.168.71.129:9092

#=============== provider  =======================

spring.kafka.producer.retries=0
# 每次批量发送消息的数量
spring.kafka.producer.batch-size=16384
spring.kafka.producer.buffer-memory=33554432

# 指定消息key和消息体的编解码方式
spring.kafka.producer.key-serializer=org.apache.kafka.common.serialization.StringSerializer
spring.kafka.producer.value-serializer=org.apache.kafka.common.serialization.StringSerializer

#=============== consumer  =======================
# 指定默认消费者group id
spring.kafka.consumer.group-id=test-consumer-group

spring.kafka.consumer.auto-offset-reset=earliest
spring.kafka.consumer.enable-auto-commit=true
spring.kafka.consumer.auto-commit-interval=100

# 指定消息key和消息体的编解码方式
spring.kafka.consumer.key-deserializer=org.apache.kafka.common.serialization.StringDeserializer
spring.kafka.consumer.value-deserializer=org.apache.kafka.common.serialization.StringDeserializer

3、发送者

        @Resource
       private KafkaTemplate<String, String> kafkaTemplate;

        Message message = new Message();
        message.setId( System.currentTimeMillis() );
        message.setMsg( respStr );
        message.setSendTime( new Date() );
        kafkaTemplate.send( "producersToConsumers_logs", gson.toJson( message ) );

4、接受者

    @KafkaListener(topics = {"producersToConsumers_logs"})
    public void listen(ConsumerRecord<?, ?> record) {
        Optional<?> optional = Optional.ofNullable( record.value() );

        if (optional.isPresent()) {
            Object msg = optional.get();
            log.info( "record:{}", record );
            log.info( "message:{}", msg );
        }
    }

5、消息类

@Data
public class Message {

    private long id;

    private String msg;

    private Date SendTime;


}

6、在虚拟机中，查看接受者是否接受成功

######启动zookeeper
bin/zookeeper-server-start.sh -daemon  config/zookeeper.properties
#####启动kafka服务
bin/kafka-server-start.sh config/server.properties
#####查看集合
bin/kafka-topics.sh --list --zookeeper  localhost:2181
#####消费者查看信息
bin/kafka-console-consumer.sh --zookeeper localhost:2181 --topic producersToConsumers_logs --from-beginning

注意：

ACK有三种

0 

意味着producer不等待broker同步完成的确认，继续发送下一条(批)信息

提供了最低的延迟。但是最弱的持久性，当服务器发生故障时，就很可能发生数据丢失。例如leader已经死亡，producer不知情，还会继续发送消息broker接收不到数据就会数据丢失

1

意味着producer要等待leader成功收到数据并得到确认，才发送下一条message。此选项提供了较好的持久性较低的延迟性。

Partition的Leader死亡，follwer尚未复制，数据就会丢失

-1

意味着producer得到follwer确认，才发送下一条数据