Kafka入门基础知识

什么是Kafka

Kafka是一款分布式消息发布和订阅系统，它的特点是高性能、高吞吐量。 最早设计的目的是作为LinkedIn的活动流和运营数据的处理管道。这些数据主要是用来对用户做用户画像分析以及服务器性能数据的一些监控所以kafka一开始设计的目标就是作为一个分布式、高吞吐量的消息系统，所以适合运用在大数据传输 场景。

Kafka的应用场景

由于kafka具有更好的吞吐量、内置分区、冗余及容错性的优点(kafka每秒可以处理几十万消息)，让 kafka成为了一个很好的大规模消息处理应用的解决方案。所以在企业级应用长，主要会应用于如下几 个方面：

行为跟踪:kafka可以用于跟踪用户浏览页面、搜索及其他行为。通过发布-订阅模式实时记录到对应的 topic中，通过后端大数据平台接入处理分析，并做更进一步的实时处理和监控

日志收集:日志收集方面，有很多比较优秀的产品，比如Apache Flume，很多公司使用kafka代理日志 聚合。日志聚合表示从服务器上收集日志文件，然后放到一个集中的平台(文件服务器)进行处理。在 实际应用开发中，我们应用程序的log都会输出到本地的磁盘上，排查问题的话通过linux命令来搞定， 如果应用程序组成了负载均衡集群，并且集群的机器有几十台以上，那么想通过日志快速定位到问题， 就是很麻烦的事情了。所以一般都会做一个日志统一收集平台管理log日志用来快速查询重要应用的问 题。所以很多公司的套路都是把应用日志集中到kafka上，然后分别导入到es和hdfs上，用来做实时检 索分析和离线统计数据备份等。而另一方面，kafka本身又提供了很好的api来集成日志并且做日志收集类似下图：

Kafka本身的架构

一个典型的kafka集群包含若干Producer(可以是应用节点产生的消息，也可以是通过Flume收集日志 产生的事件)，若干个Broker(kafka支持水平扩展)、若干个Consumer Group，以及一个 zookeeper集群。kafka通过zookeeper管理集群配置及服务协同。Producer使用push模式将消息发布 到broker，consumer通过监听使用pull模式从broker订阅并消费消息。

多个broker协同工作，producer和consumer部署在各个业务逻辑中。三者通过zookeeper管理协调请 求和转发。这样就组成了一个高性能的分布式消息发布和订阅系统。

图上有一个细节是和其他mq中间件不同的点，producer 发送消息到broker的过程是push，而 consumer从broker消费消息的过程是pull，主动去拉数据。而不是broker把数据主动发送给consumer

名词解释：

1)Broker

Kafka集群包含一个或多个服务器，这种服务器被称为broker。broker端不维护数据的消费状态，提升 了性能。直接使用磁盘进行存储，线性读写，速度快:避免了数据在JVM内存和系统内存之间的复制， 减少耗性能的创建对象和垃圾回收。

2)Producer
负责发布消息到Kafka broker

3)Consumer
消息消费者，向Kafka broker读取消息的客户端，consumer从broker拉取(pull)数据并进行处理。

4)Topic

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

5)Partition

Parition是物理上的概念，每个Topic包含一个或多个Partition.

6)Consumer Group

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

7)Topic & Partition

Topic在逻辑上可以被认为是一个queue，每条消费都必须指定它的Topic，可以简单理解为必须指明把 这条消息放进哪个queue里。为了使得Kafka的吞吐率可以线性提高，物理上把Topic分成一个或多个 Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文 件。若创建topic1和topic2两个topic，且分别有3个和2个分区，则整个集群上会相应会生成共5个 文件夹。

Kafka的安装部署：

下载kafka：https://archive.apache.org/dist/kafka/2.0.0/kafka_2.11-2.0.0.tgz

或者：

wget http://mirrors.tuna.tsinghua.edu.cn/apache/kafka/2.3.0/kafka_2.12-2.3.0.tgz

安装过程

tar -zxvf kafka_2.12-2.3.0.tgz 解压

配置zookeeper

因为kafka依赖于zookeeper来做master选举一起其他数据的维护，所以需要先启动zookeeper节点(cd bin/先进入bin目录)

kafka内置了zookeeper的服务，所以在bin目录下提供了这些脚本

zookeeper-server-start.sh

zookeeper-server-stop.sh

在config目录下，存在一些配置文件

zookeeper.properties

server.properties

所以我们可以通过下面的脚本来启动zk服务，当然，也可以自己搭建zk的集群来实现(-daemon:后台服务的方式)

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

启动和停止kafka

修改server.properties, 增加zookeeper的配置： zookeeper.connect=localhost:2181

启动kafka： sh kafka-server-start.sh -damoen config/server.properties

停止kafka：sh kafka-server-stop.sh -daemon config/server.properties

kafka的基本操作

创建topic

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

Replication-factor 表示该topic需要在不同的broker中保存几份，这里设置成1，表示在两个broker中 保存两份

Partitions 分区数

查看topic

sh kafka-topics.sh --list --zookeeper localhost:2181

查看topic属性

sh kafka-topics.sh --describe --zookeeper localhost:2181 --topic first_topic

消费消息

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

发送消息

sh kafka-console-producer.sh --broker-list 192.168.244.128:9092 --topic first_topic

查看kafka的日志相关

cd logs/

tail -f kafkaServer.out

kafak的一些属性设置：

batch.size

生产者发送多个消息到broker上的同一个分区时，为了减少网络请求带来的性能开销，通过批量的方式 来提交消息，可以通过这个参数来控制批量提交的字节数大小，默认大小是16384byte,也就是16kb， 意味着当一批消息大小达到指定的batch.size的时候会统一发送

linger.ms

Producer默认会把两次发送时间间隔内收集到的所有Requests进行一次聚合然后再发送，以此提高吞 吐量，而linger.ms就是为每次发送到broker的请求增加一些delay，以此来聚合更多的Message请求。 这个有点想TCP里面的Nagle算法，在TCP协议的传输中，为了减少大量小数据包的发送，采用了Nagle 算法，也就是基于小包的等-停协议。

batch.size和linger.ms这两个参数是kafka性能优化的关键参数，很多同学会发现batch.size和 linger.ms这两者的作用是一样的，如果两个都配置了，那么怎么工作的呢?实际上，当二者都配 置的时候，只要满足其中一个要求，就会发送请求到broker上

group.id

consumer group是kafka提供的可扩展且具有容错性的消费者机制。既然是一个组，那么组内必然可以 有多个消费者或消费者实例(consumer instance)，它们共享一个公共的ID，即group ID。组内的所有 消费者协调在一起来消费订阅主题(subscribed topics)的所有分区(partition)。当然，每个分区只能由 同一个消费组内的一个consumer来消费.如下图所示，分别有三个消费者，属于两个不同的group，那 么对于firstTopic这个topic来说，这两个组的消费者都能同时消费这个topic中的消息，对于此事的架构 来说，这个firstTopic就类似于ActiveMQ中的topic概念。如下图所示，如果3个消费者都属于同一个 group，那么此事firstTopic就是一个Queue的概念

enable.auto.commit

消费者消费消息以后自动提交，只有当消息提交以后，该消息才不会被再次接收到，还可以配合 auto.commit.interval.ms控制自动提交的频率。

当然，我们也可以通过consumer.commitSync()的方式实现手动提交

auto.offset.reset

这个参数是针对新的groupid中的消费者而言的，当有新groupid的消费者来消费指定的topic时，对于 该参数的配置，会有不同的语义

auto.offset.reset=latest情况下，新的消费者将会从其他消费者最后消费的offset处开始消费Topic下的 消息

auto.offset.reset= earliest情况下，新的消费者会从该topic最早的消息开始消费 auto.offset.reset=none情况下，新的消费者加入以后，由于之前不存在offset，则会直接抛出异常。

max.poll.records

此设置限制每次调用poll返回的消息数，这样可以更容易的预测每次poll间隔要处理的最大值。通过调 整此值，可以减少poll

 

Springboot+kafka

jar包

<dependency> <groupId>org.springframework.kafka</groupId>
    <artifactId>spring-kafka</artifactId>
    <version>2.2.0.RELEASE</version>
</dependency>

Kafka的配置：

spring.kafka.producer.value-serializer=org.apache.kafka.common.serialization.StringSerializer
spring.kafka.producer.key-serializer=org.apache.kafka.common.serialization.StringSerializer

spring.kafka.bootstrap-servers=10.206.0.14:9092

spring.kafka.consumer.group-id=springboot-groupid
spring.kafka.consumer.auto-offset-reset=earliest
spring.kafka.consumer.enable-auto-commit=true

spring.kafka.consumer.key-deserializer=org.apache.kafka.common.serialization.StringSerializer
spring.kafka.consumer.value-deserializer=org.apache.kafka.common.serialization.StringDeserializer

KafkaProducer

@Component
public class KafkaProduct {

    @Autowired
    private KafkaTemplate<String, String> kafkaTemplate;

    public void send() {
        System.out.println("---------");
        kafkaTemplate.send("test","msgkey", "msgData");
    }
}

@Component
public class KafakConsumer {

    @KafkaListener(topics = {"test"})
    public void listener(ConsumerRecord record) {

        Optional<Object> value = Optional.ofNullable(record.value());
        if (value.isPresent()) {
            System.out.println(value.get());
        }
    }
}

想要深入了解Kafka的内部实现机制吗？希望您能看下我的Kafka的实现原理深度剖析