本篇文章为你整理了Kafka详解（kafka基础知识）的详细内容，包含有kafka简单介绍 kafka基础知识 kafka the definitive guide 图解kafka之实战指南 Kafka详解，希望能帮助你了解 Kafka详解。
Kafka介绍
Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的（replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、Storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编写，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。
实际上算作是分布式的流处理平台，具备消息中间间的功能，在大数据领域作为流计算的平台，也会做消息分发。
Kafka常见的使用场景
【1】日志收集：一个公司可以用Kafka收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。
【2】消息系统：解耦和生产者和消费者、缓存消息等。
【3】用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。
【4】运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。
Kafka基本概念
【1】kafka是一个分布式的，分区的消息(官方称之为commit log)服务。它提供一个消息系统应该具备的功能，但是确有着独特的设计。可以这样来说，Kafka借鉴了JMS规范的思想，但是确并没有完全遵循JMS规范。
【2】基础的消息(Message)相关术语：
消息中间件处理节点，一个Kafka节点就是一个broker，一个或者多个Broker可以组成一个Kafka集群
每个Consumer属于一个特定的Consumer Group，一条消息可以被多个不同的Consumer Group消费，但是一个Consumer Group中只能有一个Consumer能够消费该消息
【3】从宏观层面上看，producer通过网络发送消息到Kafka集群，然后consumer来进行消费，如下图：
【4】服务端(brokers)和客户端(producer、consumer)之间通信通过TCP协议来完成。
kafka基本使用（原生API）
创建主题
【1】创建一个名字为“test”的Topic，这个topic只有一个partition，并且备份因子也设置为1：
bin/kafka-topics.sh --create --zookeeper 192.168.65.60:2181 --replication-factor 1 --partitions 1 --topic test
【2】通过以下命令来查看kafka中目前存在的topic
bin/kafka-topics.sh --list --zookeeper 192.168.65.60:2181
【3】除了通过手工的方式创建Topic，当producer发布一个消息到某个指定的Topic，这个Topic如果不存在，就自动创建。
【4】删除主题
bin/kafka-topics.sh --delete --topic test --zookeeper 192.168.65.60:2181
【1】kafka自带了一个producer命令客户端，可以从本地文件中读取内容，或者我们也可以以命令行中直接输入内容，并将这些内容以消息的形式发送到kafka集群中。在默认情况下，每一个行会被当做成一个独立的消息。
【2】运行发布消息的脚本，然后在命令中输入要发送的消息的内容：
//指定往哪个broker（也就是服务器）上发消息 bin/kafka-console-producer.sh --broker-list 192.168.65.60:9092 --topic test
this is a msg
this is a another msg
【1】对于consumer，kafka同样也携带了一个命令行客户端，会将获取到内容在命令中进行输出，默认是消费最新的消息：
bin/kafka-console-consumer.sh --bootstrap-server 192.168.65.60:9092 --topic test
【2】想要消费之前的消息可以通过--from-beginning参数指定，如下命令：
//这里便凸显了与传统消息中间件的不同，消费完，消息依旧保留（默认保留在磁盘一周） bin/kafka-console-consumer.sh --bootstrap-server 192.168.65.60:9092 --from-beginning --topic test
【3】通过不同的终端窗口来运行以上的命令，你将会看到在producer终端输入的内容，很快就会在consumer的终端窗口上显示出来。
【4】所有的命令都有一些附加的选项；当我们不携带任何参数运行命令的时候，将会显示出这个命令的详细用法
执行bin/kafka-console-consumer.sh 命令显示所有的可选参数
消费消息类型分析
消费多主题
bin/kafka-console-consumer.sh --bootstrap-server 192.168.65.60:9092 --whitelist "testtest-2"
【1】一条消息只能被某一个消费者消费的模式，类似queue模式，只需让所有消费者在同一个消费组里即可
【2】分别在两个客户端执行如下消费命令，然后往主题里发送消息，结果只有一个客户端能收到消息
bin/kafka-console-consumer.sh --bootstrap-server 192.168.65.60:9092 --consumer-property group.id=testGroup --topic test
【1】一条消息能被多个消费者消费的模式，类似publish-subscribe模式费，针对Kafka同一条消息只能被同一个消费组下的某一个消费者消费的特性，要实现多播只要保证这些消费者属于不同的消费组即可。我们再增加一个消费者，该消费者属于testGroup-2消费组，结果两个客户端都能收到消息
bin/kafka-console-consumer.sh --bootstrap-server 192.168.65.60:9092 --consumer-property group.id=testGroup-2 --topic test
查看消费组名
bin/kafka-consumer-groups.sh --bootstrap-server 192.168.65.60:9092 --list
查看消费组的消费偏移量
bin/kafka-consumer-groups.sh --bootstrap-server 192.168.65.60:9092 --describe --group testGroup
//current-offset：当前消费组的已消费偏移量
//log-end-offset：主题对应分区消息的结束偏移量(HW)
//lag：当前消费组未消费的消息数
主题Topic和消息日志Log详解
【1】可以理解Topic是一个类别的名称，同类消息发送到同一个Topic下面。对于每一个Topic，下面可以有多个分区(Partition)日志文件:【分布式存储的思想】
【2】Partition是一个有序的message序列，这些message按顺序添加到一个叫做commit log的文件中。每个partition中的消息都有一个唯一的编号，称之为offset，用来唯一标示某个分区中的message。
【3】每个partition，都对应一个commit log文件。一个partition中的message的offset都是唯一的，但是不同的partition中的message的offset可能是相同的。
【4】kafka一般不会删除消息，不管这些消息有没有被消费。只会根据配置的日志保留时间(log.retention.hours)确认消息多久被删除，默认保留最近一周的日志消息。kafka的性能与保留的消息数据量大小没有关系，因此保存大量的数据消息日志信息不会有什么影响。
【5】每个consumer是基于自己在commit log中的消费进度(offset)来进行工作的。在kafka中，消费offset由consumer自己来维护；一般情况下我们按照顺序逐条消费commit log中的消息，当然我可以通过指定offset来重复消费某些消息，或者跳过某些消息。
【6】这意味kafka中的consumer对集群的影响是非常小的，添加一个或者减少一个consumer，对于集群或者其他consumer来说，都是没有影响的，因为每个consumer维护各自的消费offset。
创建多个分区的主题：
bin/kafka-topics.sh --create --zookeeper 192.168.65.60:2181 --replication-factor 1 --partitions 2 --topic test1
查看下topic的情况
bin/kafka-topics.sh --describe --zookeeper 192.168.65.60:2181 --topic test1
以下是输出内容的解释，第一行是所有分区的概要信息，之后的每一行表示每一个partition的信息。
leader节点负责给定partition的所有读写请求。
replicas 表示某个partition在哪几个broker上存在备份。不管这个几点是不是”leader“，甚至这个节点挂了，也会列出。
isr 是replicas的一个子集，它只列出当前还存活着的，并且已同步备份了该partition的节点。
我们可以运行相同的命令查看之前创建的名称为”test“的topic
bin/kafka-topics.sh --describe --zookeeper 192.168.65.60:2181 --topic test
之前设置了topic的partition数量为1，备份因子为1，因此显示就如上所示了。
可以进入kafka的数据文件存储目录查看test和test1主题的消息日志文件：
消息日志文件主要存放在分区文件夹里的以log结尾的日志文件里，如下是test1主题对应的分区0的消息日志：
当然我们也可以通过如下命令增加topic的分区数量(目前kafka不支持减少分区)：
bin/kafka-topics.sh -alter --partitions 3 --zookeeper 192.168.65.60:2181 --topic test
理解Topic，Partition和Broker：
【1】一个topic，代表逻辑上的一个业务数据集，比如按数据库里不同表的数据操作消息区分放入不同topic，订单相关操作消息放入订单topic，用户相关操作消息放入用户topic，对于大型网站来说，后端数据都是海量的，订单消息很可能是非常巨量的，比如有几百个G甚至达到TB级别，如果把这么多数据都放在一台机器上可定会有容量限制问题，那么就可以在topic内部划分多个partition来分片存储数据，不同的partition可以位于不同的机器上，每台机器上都运行一个Kafka的进程Broker。
为什么要对Topic下数据进行分区存储？
【1】commit log文件会受到所在机器的文件系统大小的限制，分区之后可以将不同的分区放在不同的机器上，相当于对数据做了分布式存储，理论上一个topic可以处理任意数量的数据。
【2】为了提高并行度。
【1】log的partitions分布在kafka集群中不同的broker上，每个broker可以请求备份其他broker上partition上的数据。kafka集群支持配置一个partition备份的数量。
【2】针对每个partition，都有一个broker起到“leader”的作用，0个或多个其他的broker作为“follwers”的作用。leader处理所有的针对这个partition的读写请求，而followers被动复制leader的结果，不提供读写(主要是为了保证多副本数据与消费的一致性)。如果这个leader失效了，其中的一个follower将会自动的变成新的leader。
Producers
【1】生产者将消息发送到topic中去，同时负责选择将message发送到topic的哪一个partition中。通过round-robin做简单的负载均衡。也可以根据消息中的某一个关键字来进行区分。通常第二种方式使用的更多。
Consumers
【1】传统的消息传递模式有2种：队列( queue) 和（publish-subscribe）
queue模式：多个consumer从服务器中读取数据，消息只会到达一个consumer。
publish-subscribe模式：消息会被广播给所有的consumer。
【2】Kafka基于这2种模式提供了一种consumer的抽象概念：consumer group。
queue模式：所有的consumer都位于同一个consumer group 下。
publish-subscribe模式：所有的consumer都有着自己唯一的consumer group。
上图说明：由2个broker组成的kafka集群，某个主题总共有4个partition(P0-P3)，分别位于不同的broker上。这个集群由2个Consumer Group消费， A有2个consumer instances ，B有4个。
通常一个topic会有几个consumer group，每个consumer group都是一个逻辑上的订阅者（ logical subscriber ）。每个consumer group由多个consumer instance组成，从而达到可扩展和容灾的功能。
【1】一个partition同一个时刻在一个consumer group中只能有一个consumer instance在消费，从而保证消费顺序。
【2】consumer group中的consumer instance的数量不能比一个Topic中的partition的数量多，否则，多出来的consumer消费不到消息。
【3】Kafka只在partition的范围内保证消息消费的局部顺序性，不能在同一个topic中的多个partition中保证总的消费顺序性。
【4】如果有在总体上保证消费顺序的需求，那么我们可以通过将topic的partition数量设置为1，将consumer group中的consumer instance数量也设置为1，但是这样会影响性能，所以kafka的顺序消费很少用。
Java客户端访问Kafka
引入maven依赖
dependency
groupId org.apache.kafka /groupId
artifactId kafka-clients /artifactId
version 2.4.1 /version
/dependency
消息发送端代码
public class MsgProducer {
private final static String TOPIC_NAME = "my-replicated-topic";
public static void main(String[] args) throws InterruptedException, ExecutionException {
/* *********************************配置部分******************************************************/
Properties props = new Properties();
//集群架构访问集群，防止单节点故障发不出去
props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "192.168.65.60:9092,192.168.65.60:9093,192.168.65.60:9094");
发出消息持久化机制参数
（1）acks=0： 表示producer不需要等待任何broker确认收到消息的回复，就可以继续发送下一条消息。性能最高，但是最容易丢消息。（海量数据日志的话推荐这个，丢些消息其实并不影响）
（2）acks=1： 至少要等待leader已经成功将数据写入本地log，但是不需要等待所有follower是否成功写入。就可以继续发送下一条消息。这种情况下，如果follower没有成功备份数据，而此时leader又挂掉，则消息会丢失。
（一般场景都可以用在这个，适中，也是默认值）
（3）acks=-1或all： 需要等待 min.insync.replicas(默认为1，推荐配置大于等于2，即多少个节点写入成功即可) 这个参数配置的副本个数都成功写入日志，这种策略
会保证只要有一个备份存活就不会丢失数据。这是最强的数据保证。一般除非是金融级别，或跟钱打交道的场景才会使用这种配置。（金融场景，对消息十分敏感，不允许丢消息）
props.put(ProducerConfig.ACKS_CONFIG, "1");
发送失败会重试，重试次数设置，默认重试间隔100ms，重试能保证消息发送的可靠性，但是也可能造成消息重复发送，比如网络抖动，所以需要在接收者那边做好消息接收的幂等性处理。
props.put(ProducerConfig.RETRIES_CONFIG, 3);
//重试间隔设置
props.put(ProducerConfig.RETRY_BACKOFF_MS_CONFIG, 300);
//因为kafka并不是采取，你写一条，我就发一条的操作，而是在本机申请了，一块缓冲内存。你写入一条，优先是写到了本地缓冲内存中
//然后客户端还会有一个线程不断的从这个本地缓冲内存中拿数据放入，发送缓冲区（batch缓冲区【16KB】），拉满就会发送。（这也是性能为什么会高的原因之一，还会压缩数据）
//设置发送消息的本地缓冲区，如果设置了该缓冲区，消息会先发送到本地缓冲区，可以提高消息发送性能，默认值是33554432，即32MB
props.put(ProducerConfig.BUFFER_MEMORY_CONFIG, 33554432);
kafka本地线程会从缓冲区取数据，批量发送到broker，
设置批量发送消息的大小，默认值是16384，即16kb，就是说一个batch满了16kb就发送出去
props.put(ProducerConfig.BATCH_SIZE_CONFIG, 16384);
默认值是0，意思就是消息必须立即被发送，但这样会影响性能
一般设置10毫秒左右，就是说这个消息发送完后会进入本地的一个batch，如果10毫秒内，这个batch满了16kb就会随batch一起被发送出去
如果10毫秒内，batch没满，那么也必须把消息发送出去，不能让消息的发送延迟时间太长
props.put(ProducerConfig.LINGER_MS_CONFIG, 10);
//把发送的key从字符串序列化为字节数组
props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
//把发送消息value从字符串序列化为字节数组
props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class.getName());
Producer String, String producer = new KafkaProducer String, String (props);
/* *********************************使用部分******************************************************/
int msgNum = 5;
final CountDownLatch countDownLatch = new CountDownLatch(msgNum); //用于异步的展示
for (int i = 1; i = msgNum; i++) {
Order order = new Order(i, 100 + i, 1, 1000.00);
/* *********************************指定分区与不指定分区*****************************************/
//指定发送分区
/*ProducerRecord String, String producerRecord = new ProducerRecord String, String (TOPIC_NAME
, 0, order.getOrderId().toString(), JSON.toJSONString(order));*/
//未指定发送分区，具体发送的分区计算公式：hash(key)%partitionNum
ProducerRecord String, String producerRecord = new ProducerRecord String, String (TOPIC_NAME
, order.getOrderId().toString(), JSON.toJSONString(order));
/* *********************************同步发送与异步发送（发送完后面还有逻辑优先异步）*****************************************/
//等待消息发送成功的同步阻塞方法
RecordMetadata metadata = producer.send(producerRecord).get();
System.out.println("同步方式发送消息结果：" + "topic-" + metadata.topic() + "partition-"
+ metadata.partition() + "offset-" + metadata.offset());
//异步回调方式发送消息
/*producer.send(producerRecord, new Callback() {
public void onCompletion(RecordMetadata metadata, Exception exception) {
if (exception != null) {
System.err.println("发送消息失败：" + exception.getStackTrace());
if (metadata != null) {
System.out.println("异步方式发送消息结果：" + "topic-" + metadata.topic() + "partition-"
+ metadata.partition() + "offset-" + metadata.offset());
countDownLatch.countDown();
});*/
//业务...
countDownLatch.await(5, TimeUnit.SECONDS);
producer.close();
@Data
public class Order {
private Integer orderId;
private Integer productId;
private Integer productNum;
private Double orderAmount;
public Order(Integer orderId, Integer productId, Integer productNum, Double orderAmount) {
super();
this.orderId = orderId;
this.productId = productId;
this.productNum = productNum;
this.orderAmount = orderAmount;
}
部分说明：
【1】如果不指定分区：
【2】如果配置了重试参数，kafka2.4.1版本如何保证幂等机制：
消息接收端代码
public class MsgConsumer {
private final static String TOPIC_NAME = "my-replicated-topic";
private final static String CONSUMER_GROUP_NAME = "testGroup";
public static void main(String[] args) throws Exception {
Properties props = new Properties();
props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "192.168.65.60:9092,192.168.65.60:9093,192.168.65.60:9094");
// 消费分组名
props.put(ConsumerConfig.GROUP_ID_CONFIG, CONSUMER_GROUP_NAME);
// 是否自动提交offset，默认就是true
/*props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true");
// 自动提交offset的间隔时间
props.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000");*/
props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "false");
当消费主题的是一个新的消费组，或者指定offset的消费方式，offset不存在，那么应该如何消费
latest(默认) ：只消费自己启动之后发送到主题的消息
earliest：第一次从头开始消费，以后按照消费offset记录继续消费，这个需要区别于consumer.seekToBeginning(每次都从头开始消费)
//props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest");
consumer给broker发送心跳的间隔时间，broker接收到心跳如果此时有rebalance发生会通过心跳响应将
rebalance方案下发给consumer，这个时间可以稍微短一点，默认3s
props.put(ConsumerConfig.HEARTBEAT_INTERVAL_MS_CONFIG, 1000);
服务端broker多久感知不到一个consumer心跳就认为他故障了，会将其踢出消费组，对应的Partition也会被重新分配给其他consumer，默认是10秒
props.put(ConsumerConfig.SESSION_TIMEOUT_MS_CONFIG, 10 * 1000);
//一次poll最大拉取消息的条数，如果消费者处理速度很快，可以设置大点，如果处理速度一般，可以设置小点，默认500
props.put(ConsumerConfig.MAX_POLL_RECORDS_CONFIG, 50);
如果两次poll操作间隔超过了这个时间，broker就会认为这个consumer处理能力太弱，会将其踢出消费组，将分区分配给别的consumer消费
有种适者生存的感觉，把处理能力弱的(如2核4G比4核8G弱，而且没在限定时间内来拿任务)驱逐。【要么检查处理过程是否能够优化缩短时间，要么调整一次性获取的条数，要么增大间隔时间（间隔时间默认的一般不建议调整）】
props.put(ConsumerConfig.MAX_POLL_INTERVAL_MS_CONFIG, 30 * 1000);
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(Arrays.asList(TOPIC_NAME));
// 消费指定分区
//consumer.assign(Arrays.asList(new TopicPartition(TOPIC_NAME, 0)));
//消息回溯消费
/*consumer.assign(Arrays.asList(new TopicPartition(TOPIC_NAME, 0)));
consumer.seekToBeginning(Arrays.asList(new TopicPartition(TOPIC_NAME, 0)));*/
//指定offset消费
/*consumer.assign(Arrays.asList(new TopicPartition(TOPIC_NAME, 0)));
//指定从TOPIC_NAME的第10条开始消费
consumer.seek(new TopicPartition(TOPIC_NAME, 0), 10);*/
//从指定时间点开始消费
/*List PartitionInfo topicPartitions = consumer.partitionsFor(TOPIC_NAME);
//从1小时前开始消费
long fetchDataTime = new Date().getTime() - 1000 * 60 * 60;
Map TopicPartition, Long map = new HashMap ();
//将topic的所有partition拿出来
for (PartitionInfo par : topicPartitions) {
map.put(new TopicPartition(TOPIC_NAME, par.partition()), fetchDataTime);
}
//寻找每个partition的符合时间节点的offset
Map TopicPartition, OffsetAndTimestamp parMap = consumer.offsetsForTimes(map);
//针对每个partition进行消费
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);
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());
if (records.count() 0) {
// 手动同步提交offset，当前线程会阻塞直到offset提交成功
// 一般使用同步提交，因为提交之后一般也没有什么逻辑代码了
//consumer.commitSync();
// 手动异步提交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());
});*/
}
部分说明：
【1】如果设置为 props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true"); 自动提交：
一般需要配置提交时间 props.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000"); 【如1秒后提交】，但是由于不可预测到业务完成需要多久时间（假设5s），那么在处理过程中会出现服务器宕机的情况，导致消息丢失。如果出现业务执行很快，在0.5s的时候就已经执行业务完成，但是在0.8s的时候服务器宕机，会造成消息已经消费了，但是中间件不知道（又会发给第二个消费者消费），导致消息重复消费。【所以自动提交不太可取】
【2】如果设置为props.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "false"); 手动提交：
那么会有两个选择：同步提交与异步提交。
【3】消息回溯消费的机制是怎么实现的：
因为kafka的消息存储在log文件里面，而且对应的还会有index与timeindex（可以加快对于消息的检索），根据设置给予的offset可以快速定位到是哪个log文件，因为文件名就是offset偏移值。快速拿出数据就可以进行消费了。此外根据时间回溯也是一样不过量会更大一点。
【4】针对已经存在的tipoc,如果有新的消费组加入，默认是将当前tipoc的最后offset传给消费组，作为其已消费的记录。故，如果是要它来帮忙处理消息的，要设置为props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest"); ，这个消费组如果是已经存在的，那么这个参数其实不会变动已有的offset。默认处理大数据量的应该采用latest。业务场景则用earliest。
Spring Boot整合Kafka
引入spring boot kafka依赖
dependency
groupId org.springframework.kafka /groupId
artifactId spring-kafka /artifactId
/dependency
application.yml配置如下：
spring:
kafka:
bootstrap-servers: 192.168.65.60:9092,192.168.65.60:9093,192.168.65.60:9094
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
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
发送者代码：
@RestController
public class KafkaController {
private final static String TOPIC_NAME = "my-replicated-topic";
@Autowired
private KafkaTemplate String, String kafkaTemplate;
@RequestMapping("/send")
public void send() {
kafkaTemplate.send(TOPIC_NAME, 0, "key", "this is a msg");
}
消费者代码：
@Component
public class MyConsumer {
* @KafkaListener(groupId = "testGroup", topicPartitions = {
* @TopicPartition(topic = "topic1", partitions = {"0", "1"}),
* @TopicPartition(topic = "topic2", partitions = "0",
* partitionOffsets = @PartitionOffset(partition = "1", initialOffset = "100"))
* },concurrency = "6")
* //concurrency就是同组下的消费者个数，就是并发消费数，必须小于等于分区总数
* @param record
@KafkaListener(topics = "my-replicated-topic",groupId = "zGroup")
public void listenZGroup(ConsumerRecord String, String record, Acknowledgment ack) {
String value = record.value();
System.out.println(value);
System.out.println(record);
//手动提交offset
//ack.acknowledge();
//配置多个消费组
/*@KafkaListener(topics = "my-replicated-topic",groupId = "tuGroup")
public void listenTuGroup(ConsumerRecord String, String record, Acknowledgment ack) {
String value = record.value();
System.out.println(value);
System.out.println(record);
ack.acknowledge();
}
Kafka设计原理详解
Kafka核心总控制器Controller
在Kafka集群中会有一个或者多个broker，其中有一个broker会被选举为控制器（Kafka Controller），它负责管理整个集群中所有分区和副本的状态。
当某个分区的leader副本出现故障时，由控制器负责为该分区选举新的leader副本。
当检测到某个分区的ISR集合发生变化时，由控制器负责通知所有broker更新其元数据信息。
当使用kafka-topics.sh脚本为某个topic增加分区数量时，同样还是由控制器负责让新分区被其他节点感知到。
Controller选举机制
【1】在kafka集群启动的时候，会自动选举一台broker作为controller来管理整个集群，选举的过程是集群中每个broker都会尝试在zookeeper上创建一个 /controller 临时节点，zookeeper会保证有且仅有一个broker能创建成功，这个broker就会成为集群的总控器controller。
【2】当这个controller角色的broker宕机了，此时zookeeper临时节点会消失，集群里其他broker会一直监听这个临时节点，发现临时节点消失了，就竞争再次创建临时节点，就是我们上面说的选举机制，zookeeper又会保证有一个broker成为新的controller。
【3】具备控制器身份的broker需要比其他普通的broker多一份职责，具体细节如下：
1.监听broker相关的变化。为Zookeeper中的/brokers/ids/节点添加BrokerChangeListener，用来处理broker增减的变化。
2.监听topic相关的变化。为Zookeeper中的/brokers/topics节点添加TopicChangeListener，用来处理topic增减的变化；为Zookeeper中的/admin/delete_topics节点添加TopicDeletionListener，用来处理删除topic的动作。
3.从Zookeeper中读取获取当前所有与topic、partition以及broker有关的信息并进行相应的管理。对于所有topic所对应的Zookeeper中的/brokers/topics/[topic]节点添加PartitionModificationsListener，用来监听topic中的分区分配变化。
4.更新集群的元数据信息，同步到其他普通的broker节点中。
Partition副本选举Leader机制
【1】controller感知到分区leader所在的broker挂了(controller监听了很多zk节点可以感知到broker存活)，controller会从ISR列表(参数unclean.leader.election.enable=false的前提下)里挑第一个broker作为leader(第一个broker最先放进ISR列表，可能是同步数据最多的副本)【这种会阻塞直到ISR列表有数据】，如果参数unclean.leader.election.enable为true，代表在ISR列表里所有副本都挂了的时候可以在ISR列表以外的副本中选leader，这种设置，可以提高可用性，但是选出的新leader有可能数据少很多。【其实就是知道/broker/ids/下面的数据没了】
【2】副本进入ISR列表有两个条件：
1.副本节点不能产生分区，必须能与zookeeper保持会话以及跟leader副本网络连通
2.副本能复制leader上的所有写操作，并且不能落后太多。(与leader副本同步滞后的副本，是由 replica.lag.time.max.ms 配置决定的，超过这个时间都没有跟leader同步过的一次的副本会被移出ISR列表)
消费者消费消息的offset记录机制
【1】每个consumer会定期将自己消费分区的offset提交给kafka内部topic：__consumer_offsets，提交过去的时候，key是consumerGroupId+topic+分区号，value就是当前offset的值，kafka会定期清理topic里的消息，最后就保留最新的那条数据。【相当于记录了这个消费组在这个topic的某分区上消费到了哪】
【2】因为__consumer_offsets可能会接收高并发的请求，kafka默认给其分配50个分区(可以通过offsets.topic.num.partitions设置)，这样可以通过加机器的方式抗大并发。
【3】通过如下公式可以选出consumer消费的offset要提交到__consumer_offsets的哪个分区
公式：hash(consumerGroupId) % __consumer_offsets主题的分区数
【4】早期这个就是记录在zookeeper中，但是并发度不高，所以才转到了broker中。
消费者Rebalance机制（再平衡机制）
【1】rebalance就是说如果消费组里的消费者数量有变化或消费的分区数有变化，kafka会重新分配消费者消费分区的关系。比如consumer group中某个消费者挂了，此时会自动把分配给他的分区交给其他的消费者，如果他又重启了，那么又会把一些分区重新交还给他。
【2】注意：rebalance只针对subscribe这种不指定分区消费的情况，如果通过assign这种消费方式指定了分区，kafka不会进行rebanlance。
【3】如下情况可能会触发消费者rebalance
1.消费组里的consumer增加或减少了
2.动态给topic增加了分区
3.消费组订阅了更多的topic
【4】rebalance过程中，消费者无法从kafka消费消息，这对kafka的TPS会有影响，如果kafka集群内节点较多，比如数百个，那重平衡可能会耗时极多，所以应尽量避免在系统高峰期的重平衡发生。
消费者Rebalance分区分配策略：
【1】主要有三种rebalance的策略：range、round-robin、sticky。
【2】Kafka 提供了消费者客户端参数partition.assignment.strategy 来设置消费者与订阅主题之间的分区分配策略。默认情况为range分配策略。
【3】假设一个主题有10个分区(0-9)，现在有三个consumer消费：
1）range策略就是按照分区序号排序，假设 n＝分区数／消费者数量 = 3， m＝分区数%消费者数量 = 1，那么前 m 个消费者每个分配 n+1 个分区，后面的（消费者数量－m ）个消费者每个分配 n 个分区。比如分区0~3给一个consumer，分区4~6给一个consumer，分区7~9给一个consumer。
2）round-robin策略就是轮询分配，比如分区0、3、6、9给一个consumer，分区1、4、7给一个consumer，分区2、5、8给一个consumer。
3）sticky策略初始时分配策略与round-robin类似，但是在rebalance的时候，需要保证如下两个原则。
1）分区的分配要尽可能均匀 。
2）分区的分配尽可能与上次分配的保持相同。
当两者发生冲突时，第一个目标优先于第二个目标 。这样可以最大程度维持原来的分区分配的策略。比如对于第一种range情况的分配，如果第三个consumer挂了，那么重新用sticky策略分配的结果如下：
consumer1除了原有的0~3，会再分配一个7
consumer2除了原有的4~6，会再分配8和9
Rebalance过程
【1】当有消费者加入消费组时，消费者、消费组及组协调器之间会经历以下几个阶段。图示过程：
【2】第一阶段：选择组协调器
组协调器GroupCoordinator：每个consumer group都会选择一个broker作为自己的组协调器coordinator，负责监控这个消费组里的所有消费者的心跳，以及判断是否宕机，然后开启消费者rebalance。
consumer group中的每个consumer启动时会向kafka集群中的某个节点发送 FindCoordinatorRequest 请求来查找对应的组协调器GroupCoordinator，并跟其建立网络连接。
组协调器选择方式：
consumer消费的offset要提交到__consumer_offsets的哪个分区，这个分区leader对应的broker就是这个consumer group的coordinator
【3】第二阶段：加入消费组JOIN GROUP
在成功找到消费组所对应的 GroupCoordinator 之后就进入加入消费组的阶段，在此阶段的消费者会向 GroupCoordinator 发送 JoinGroupRequest 请求，并处理响应。然后GroupCoordinator 从一个consumer group中选择第一个加入group的consumer作为leader(消费组协调器)，把consumer group情况发送给这个leader，接着这个leader会负责制定分区方案。
【4】第三阶段（ SYNC GROUP)
consumer leader通过给GroupCoordinator发送SyncGroupRequest，接着GroupCoordinator就把分区方案下发给各个consumer【心跳的时候】，他们会根据指定分区的leader broker进行网络连接以及消息消费。
producer发布消息机制剖析
【1】写入方式
producer 采用 push 模式将消息发布到 broker，每条消息都被 append 到 patition 中，属于顺序写磁盘（顺序写磁盘效率比随机写内存要高，保障 kafka 吞吐率）。
【2】消息路由
producer 发送消息到 broker 时，会根据分区算法选择将其存储到哪一个 partition。其路由机制为：
1. 指定了 patition，则直接使用；
2. 未指定 patition 但指定 key，通过对 key 的 value 进行hash 选出一个 patition
3. patition 和 key 都未指定，使用轮询选出一个 patition。
【3】写入流程
如图：
说明：
1. producer 先从 zookeeper 的 "/brokers/.../state" 节点找到该 partition 的 leader
2. producer 将消息发送给该 leader
3. leader 将消息写入本地 log
4. followers 从 leader pull 消息，写入本地 log 后 向leader 发送 ACK
5. leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 发送 ACK
HW与LEO详解
【1】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中获取。对于来自内部broker的读取请求，没有HW的限制。
【2】如图详细的说明了当producer生产消息至broker后，ISR以及HW和LEO的流转过程：
【3】故，Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。事实上，同步复制要求所有能工作的follower都复制完，这条消息才会被commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，follower异步的从leader复制数据，数据只要被leader写入log就被认为已经commit，这种情况下如果follower都还没有复制完，落后于leader时，突然leader宕机，则会丢失数据。而Kafka的这种使用ISR的方式则很好的均衡了确保数据不丢失以及吞吐率。再回顾下消息发送端对发出消息持久化机制参数acks的设置，我们结合HW和LEO来看下acks=1的情况。
【4】结合HW和LEO看下 acks=1的情况：
ISR机制
【1】概念：
AR（Assigned Repllicas）一个partition的所有副本（就是replica，不区分leader或follower）
ISR（In-Sync Replicas）能够和 leader 保持同步的 follower + leader本身 组成的集合。
OSR（Out-Sync Relipcas）不能和 leader 保持同步的 follower 集合
公式：AR = ISR + OSR
【2】副本数据同步机制
【3】Kafka 选择了第二种方案，原因如下：
同样为了容忍 n 台节点的故障，第一种方案需要 2n+1 个副本，而第二种方案只需要 n+1 个副本，而 Kafka 的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。
虽然第二种方案的网络延迟会比较高，但网络延迟对 Kafka 的影响较小。
【4】ISR踢出replica
# 默认10000 即 10秒
replica.lag.time.max.ms
# 允许 follower 副本落后 leader 副本的消息数量，超过这个数量后，follower 会被踢出 ISR
replica.lag.max.messages
【5】总结：leader会维持一个与其保持同步的replica集合，该集合就是ISR，每一个leader partition都有一个ISR，leader动态维护, 要保证kafka不丢失message，就要保证ISR这组集合存活(至少有一个存活)，并且消息commit成功,Partition leader 保持同步的 Partition Follower 集合, 当 ISR 中的Partition Follower ,完成数据的同步之后，就会给 leader 发送 ack 如果Partition follower长时间(replica.lag.time.max.ms) 未向leader同步数据，则该Partition Follower将被踢出ISR,Partition Leader 发生故障之后，就会从 ISR 中选举新的 Partition Leader。当replica重新追上了leader，OSR中的replica就会重新加入ISR中。
【6】问题点：Kafka对外依然可以声称是完全同步，但是承诺是对AR中的所有replica完全同步了吗？并没有。Kafka只保证对ISR集合中的所有副本保证完全同步。至于，ISR到底有多少个follower，那不知道！Kafka是一定会保证leader接收到的消息完全同步给ISR中的所有副本。而最坏的情况下，ISR中只剩leader自己。故，才会有副本选举Leader机制中的两种不同的方式。
日志分段存储
【1】Kafka 一个分区的消息数据对应存储在一个文件夹下，以topic名称+分区号命名，消息在分区内是分段(segment)存储，每个段的消息都存储在不一样的log文件里，这种特性方便old segment file快速被删除，kafka规定了一个段位的 log 文件最大为 1G，做这个限制目的是为了方便把 log 文件加载到内存去操作：
# 部分消息的offset索引文件，kafka每次往分区发4K(可配置)消息就会记录一条当前消息的offset到index文件，（有点类似于MYSQL的索引，B+树的快速定位）
# 如果要定位消息的offset会先在这个文件里快速定位，再去log文件里找具体消息
00000000000000000000.index
# 消息存储文件，主要存offset和消息体
00000000000000000000.log
# 消息的发送时间索引文件，kafka每次往分区发4K(可配置)消息就会记录一条当前消息的发送时间戳与对应的offset到timeindex文件，
# 如果需要按照时间来定位消息的offset，会先在这个文件里查找
00000000000000000000.timeindex
//另一份日志段文件
00000000000005367851.index
00000000000005367851.log
00000000000005367851.timeindex
//又是一份日志段文件
00000000000009936472.index
00000000000009936472.log
00000000000009936472.timeindex
【2】这个 9936472 之类的数字，就是代表了这个日志段文件里包含的起始 Offset，也就说明这个分区里至少都写入了接近 1000 万条数据了。
【3】Kafka Broker 有一个参数，log.segment.bytes，限定了每个日志段文件的大小，最大就是 1GB。
【4】一个日志段文件满了，就自动开一个新的日志段文件来写入，避免单个文件过大，影响文件的读写性能，这个过程叫做 log rolling，正在被写入的那个日志段文。
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。