Kafka入门

概述

关键词:

1、主题
2、分区

基本操作

##创建一个名为 tuzisir的主题
kafka-topics --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic tuzisir

#查询kafka服务器中的主题列表
kafka-topics --list --zookeeper localhost:2181

#向主题tuzisir发送消息
kafka-console-producer --broker-list localhost:9092 --topic tuzisir

#从tuzisir取出一条消息
kafka-console-consumer --bootstrap-server localhost:9092 --topic tuzisir --from-beginning

mac命令

进入kafka目录/bin：
1、查询topic，
kafka-topics --list --zookeeper localhost:2181

2、查询topic内容：
kafka-console-consumer --bootstrap-server localhost:9092 --topic topicName --from-beginning
3.查看group
kafka-consumer-groups --bootstrap-server 127.0.0.1:9092 --list
4.删除topic
kafka-topics.sh --zookeeper localhost:2181 --delete --topic {topicname}
5.计算消息堆积情况
kafka-consumer-groups --bootstrap-server localhost:9092 --describe --group test_group
6.创建topic
kafka-topics.sh --create --zookeeper localhost:2181 --replication-factor 1 --partitions 1 --topic mytest
把localhost换成其他机器ip可以直接操作其他的kafka服务器

分区

Kafka的Topic为什么要分区

biu

ACK机制

Ack的意思是Tcp首部中的确认标志，对已收到的TCP报文进行确认

Kafka的ack机制，指的是producer的消息发送确认机制，这直接影响到Kafka集群的吞吐量和消息可靠性。而吞吐量和可靠性就像硬币的两面，两者不可兼得，只能平衡。

ack有3个可选值，分别是1，0，-1。

ack=1，简单来说就是，producer只要收到一个分区副本成功写入的通知就认为推送消息成功了。这里有一个地方需要注意，这个副本必须是leader副本。只有leader副本成功写入了，producer才会认为消息发送成功。

注意，ack的默认值就是1。这个默认值其实就是吞吐量与可靠性的一个折中方案。生产上我们可以根据实际情况进行调整，比如如果你要追求高吞吐量，那么就要放弃可靠性。

ack=0，简单来说就是，producer发送一次就不再发送了，不管是否发送成功。

ack=-1，简单来说就是，producer只有收到分区内所有副本的成功写入的通知才认为推送消息成功了。

ack=1的情况下，producer只要收到分区leader成功写入的通知就会认为消息发送成功了。如果leader成功写入后，还没来得及把数据同步到follower节点就挂了，这时候消息就丢失了。

ack=-1的时候会有可能造成数据重复如图：

当生产者发送消息后，leader接收到写完消息并同步到两个follower中时，leader宕掉了；此时还没有香Producer发送ack，因此Producer认为此次发送的消息并没有被接收到所以重新发一次同样的消息 导致数据重复！！！

生产者ISR

核心问题：
生产者发送数据一般是和leader进行交互的，怎么才能保证数据不丢失呢？

副本数据同步策略

1、
正常来说生产者是给leader来发消息的，follower向leader同步数据。
那什么时候发送ack呢？

如上图 Kafka在这里选中的是第二种策略
理由：
1）同样为了容忍n台节点的故障，第一种方案需要2n+1个副本，而第二种方案只需要n+1个副本，而Kafka的每个分区都有大量的数据，第一种方案会造成大量数据的冗余。（多余的重复或啰嗦内容（包括信息、语言、代码、结构、服务、软件、硬件等等）均称为冗余。）
2）虽然第二种方案的网络延迟会比较高，但网络延迟对kafka的影响较小。

ISR是什么

Isr的目的主要是解决刚才说的问题，防止所有副本再同步的时候，这个突然坏的副本怎么处理呢。从而影响整个团队。
10个副本：1个leader和9个follower
之前说的等待所有副本都同步结束之后再发送ack不行，而应该把部分副本放到ISR里面，等ISR里面的所有副本全部同步结束之后再发送ack。
问：需要把哪几个副本放到ISR里面呢？看什么选择？
答：ISR，就是为了数据可靠性。为了保证数据不丢失。ISR核心作用就是：
leader挂掉之后，从这里面选取新的leader
你想进ISR的条件：
1、你的通信必须快，通信时间，leader刚写完，你这个副本就写完了，good。
2、数据量高的。比如leader写了10条，其他的有些同步了7条，6条。肯定选择那些同步数据量多的优先选择。
在高版本当中，我们只保留了一个。
实际上保留的是：时间的。也就是最看重的还是你的延迟时间。

高版本中保留一个的原因：

保留下来的是时间
1、生产者这里是批量发送数据的。
2、ISR这个队列维护的时候。在生产环境中，kafka是维护在内存中的。同时kafka还需要将数据写到zk中去。在kafka集群中维护了内存中的队列。

如果全部的follower的差值都大于10，那这时候全部的follower都需要从ISR中剔除。
但是之后又会拉进来，可能会频繁的操作ISR，剔除ISR，加入ISR，在内存中操作，因为数据还存放在zk中，所以你还要频繁的去操作zk。

数据一致性

举例：

如果此时leader宕机 有15个数据的follower被选举为leader；然后19条数据的leader又复活了 则会出现 数据不一致的问题！！！

Log文件中的 HW 和 LEO：
只有HW之前的数据才会对Corsumer可见
这样可以保证消费者在消费的时候 保持数据一致性

Kafka 三种语义

在分布式系统中，构成系统的任何节点都是被定义为可以彼此独立失败的。比如在 Kafka 中，broker 可能会 crash，在 producer 推送数据至 topic 的过程中也可能会遇到网络问题。根据 producer 处理此类故障所采取的提交策略类型，有如下三种：

at-least-once：

如果 producer 收到来自 Kafka broker 的确认（ack）或者 acks = all，则表示该消息已经写入到 Kafka。但如果 producer ack 超时或收到错误，则可能会重试发送消息，客户端会认为该消息未写入 Kafka。如果 broker 在发送 Ack 之前失败，但在消息成功写入 Kafka 之后，此重试将导致该消息被写入两次，因此消息会被不止一次地传递给最终 consumer，这种策略可能导致重复的工作和不正确的结果。

at-most-once：

如果在 ack 超时或返回错误时 producer 不重试，则该消息可能最终不会写入 Kafka，因此不会传递给 consumer。在大多数情况下，这样做是为了避免重复的可能性，业务上必须接收数据传递可能的丢失。

exactly-once：

即使 producer 重试发送消息，消息也会保证最多一次地传递给最终consumer。该语义是最理想的，但也难以实现，因为它需要消息系统本身与生产和消费消息的应用程序进行协作。注意：exactly-once策略也只能保证一次会话中不会出现数据重复 例如PID重启后发生变化

消费者分区分配问题

RangeAssignor：

每次对一个主题分配消费者，分区数能整除消费者数，则每个消费者得到分区数一样，如果有余数，排在前面的消费者在有多的剩余分区情况下，就会多分配一个分区

比如两个消费者C0，C1；两个主题 t0， t1; 每个主题三个分区 t0p0，t0p1，t0p2；t1p0，t1p1，t1p2；（每个消费者都订阅了每个主题）

C0: [t0p0, t0p1, t1p0, t1p1] // 先分配t0, 消费者按字典序排序，往前的得到的多
C1: [t0p2, t1p2]

又比如：三个消费者，两个主题，五个分区 （每个消费者都订阅了每个主题）

C0: [t0p0, t0p1, t1p0, t1p1] // 先分配t0, 消费者按字典序排序，往前的得到的多
C1: [t0p2, t0p3, t1p2, t1p3] // 看起来不太均衡
C2: [t0p4, t1p4]

RoundRobinAssignor：

主题分区整合在一起，统一分配；构造消费者环，每个消费者循环消费一次（如果该消费者没有订阅该主题则跳到下一个消费者）

比如三个消费者，三个主题分别1，2，3 个分区，消费者1， 2，3 分别订阅了主题1；1，2；1，2，3；

C0: [t0p0]  //字典排序，C0 先获取分区，C1，C2 循环，没有订阅主题就跳过
C1: [t1p0]
C2: [t1p1, t2p0, t2p1, t2p2]

高效读写数据

1、顺序写磁盘
Kafka的producer生产数据写入log文件，过程是一直追加在文件末端，顺序写。同一个磁盘顺序写可达到600MB/S而随机写只能达到100KB/S；顺序写可以省去大量的磁头寻找地址的时间
2、使用零拷贝（零复制）技术
一般情况下：

零拷贝技术：
读文件直接由操作系统写下去

Zookeeper在Kafka中的作用

Kafka集群中有一个broker会被选举为Controller，它负责管理集群broker的上下线，所有topic的分区副本分配和leader选举等工作。
Controller的管理工作都是依赖于Zookeeper的。

Kafka事务

Producer事物

为了实现跨分区跨会话的事务，需要引入一个全局唯一的 Transaction ID，并将 Producer获得的PID 和Transaction ID 绑定。这样当Producer 重启后就可以通过正在进行的 TransactionID 获得原来的 PID。为了管理 Transaction，Kafka 引入了一个新的组件 Transaction Coordinator。Producer 就是通过和 Transaction Coordinator 交互获得 Transaction ID 对应的任务状态。TransactionCoordinator 还负责将事务所有写入 Kafka 的一个内部 Topic，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以得到恢复，从而继续进行。

API生产者流程

消息发送流程

Kafka的生产者(Producer)发送消息采用的是异步发送的方式.在消息发送过程中,涉及到了两个线程:main线程和Sender线程,以及一个线程共享变量——RecordAccumulator;main线程把消息发送给RecordAccumulator Sender线程不断从RecordAccumulator中拉取消息发送给Kafka broker;

相关参数：
batch.size：只有数据积累到 batch.size 之后，sender 才会发送数据。
linger.ms：如果数据迟迟未达到 batch.size，sender 等待 linger.time 之后就会发送数据。

Interceptors:拦截器
Serializer:序列化器
Partitioner:分区器
RecordAccumulator: 记录计数器

异步发送API

Kafka面试题：在Kafka中broker的意义是什么？
答：在Kafka集群中，broker术语用于引用服务器，Broker用于缓存代理，Kafka集群中的一台或多台服务器统称broker。