Kafka详情

用户缓冲区

同步

生产者ack机制对于某些不太重要的数据，对数据的可靠性要求不是很高，能够容忍数据的少量丢失，所以没有必要等到ISR中所有的follower全部接受成功。Kafka为用户提供了三种可靠性级别，用户根据可靠性和延迟的要求进行权衡选择不同的配置

监听

logs2

消费者

（1）

分区分配策略时机？在 Kafka 内部存在两种默认的分区分配策略：Range 和 RoundRobin。当以下事件发生时，Kafka 将会进行一次分区分配：1、同一个 Consumer Group 内新增消费者2、消费者离开当前所属的Consumer Group，包括shuts down 或 crashes3、订阅的主题新增分区

服务器（Kafka节点）

3

生产者3

Topic BPartition-0Follower

磁盘文件

Zookeeper

socket缓冲区

consumer1

Leader主分区

Broker-1

磁盘(分区日志)默认存7天

0

一个partition分多个Segment一个segment分.log文件和.index文件

ZooKeeper的作用

Topic-1

Topic-2

Partition3

生产者1

生产者

7

Leader(New)

重新发送

4

log

HW之前的数据才对消费者(Consumer)可见

连接

message的结构是由Key和Value和timestamp(时间戳)组成

Producer：消息生产者，向Kafka中发布消息的角色。Consumer：消息消费者，即从Kafka中拉取消息消费的客户端。Consumer Group：消费者组，消费者组则是一组中存在多个消费者，消费者消费Broker中当前Topic的不同分区中的消息，消费者组之间互不影响，所有的消费者都属于某个消费者组，即消费者组是逻辑上的一个订阅者。某一个分区中的消息只能够一个消费者组中的一个消费者所消费Broker：经纪人，一台Kafka服务器就是一个Broker，一个集群由多个Broker组成，一个Broker可以容纳多个Topic。Topic：主题，可以理解为一个队列，生产者和消费者都是面向一个TopicPartition：分区，为了实现扩展性，一个非常大的Topic可以分布到多个Broker上，一个Topic可以分为多个Partition，每个Partition是一个有序的队列(分区有序，不能保证全局有序)Replica：副本Replication，为保证集群中某个节点发生故障，节点上的Partition数据不丢失，Kafka可以正常的工作，Kafka提供了副本机制，一个Topic的每个分区有若干个副本，一个Leader和多个FollowerLeader：每个分区多个副本的主角色，生产者发送数据的对象，以及消费者消费数据的对象都是Leader。Follower：每个分区多个副本的从角色，实时的从Leader中同步数据，保持和Leader数据的同步，Leader发生故障的时候，某个Follower会成为新的Leader。

消费方式consumer采用pull拉的方式来从broker中读取数据。push推的模式很难适应消费速率不同的消费者，因为消息发送率是由broker决定的，它的目标是尽可能以最快的速度传递消息，但是这样容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull方式则可以让consumer根据自己的消费处理能力以适当的速度消费消息。pull模式不足在于如果Kafka中没有数据，消费者可能会陷入循环之中 (因为消费者类似监听状态获取数据消费的)，一直返回空数据，针对这一点，Kafka的消费者在消费数据时会传入一个时长参数timeout，如果当前没有数据可供消费，consumer会等待一段时间之后再返回，时长为timeout。

LEO：每个副本的最后一个offsetHW：所有副本中最小的LEO

broker-0

Partition1(队列)

consumer3

Consumer

push

事务kafka从0.11版本开始引入了事务支持，事务可以保证Kafka在Exactly Once语义的基础上，生产和消费可以跨分区的会话，要么全部成功，要么全部失败。Producer事务为了按跨分区跨会话的事务，需要引入一个全局唯一的Transaction ID，并将Producer获得的PID(可以理解为Producer ID)和Transaction ID进行绑定，这样当Producer重启之后就可以通过正在进行的Transaction ID获得原来的PID。为了管理Transaction，Kafka引入了一个新的组件Transaction Coordinator，Producer就是通过有和Transaction Coordinator交互获得Transaction ID对应的任务状态，Transaction Coordinator还负责将事务信息写入内部的一个Topic中，这样即使整个服务重启，由于事务状态得到保存，进行中的事务状态可以恢复，从而继续进行。Consumer事务对于Consumer而言，事务的保证相比Producer相对较弱，尤其是无法保证Commit的信息被精确消费，这是由于Consumer可以通过offset访问任意信息，而且不同的Segment File声明周期不同，同一事务的消息可能会出现重启后被删除的情况。

内核程序上下文

Broker-0

Topic APartition-1Follower

logs1

发送数据Hello

生产者ISR（同步副本集）为保证producer发送的数据能够可靠的发送到指定的topic中，topic的每个partition收到producer发送的数据后，都需要向producer发送ackacknowledgement，如果producer收到ack就会进行下一轮的发送，否则重新发送数据。发送ack的时机确保有follower与leader同步完成，leader在发送ack，这样可以保证在leader挂掉之后，follower中可以选出新的leader（主要是确保follower中数据不丢失）follower同步完成多少才发送ack—半数以上的follower同步完成，即可发送ack—全部的follower同步完成，才可以发送ack

标记

leader

ack

Broker

consumer2

pull

.indx

Group-1Consumer-0

-1(all)：producer等待broker的ack，partition的leader和ISR的follower全部落盘成功才返回ack，但是如果在follower同步完成后，broker发送ack之前，如果leader发生故障，会造成数据重复。(这里的数据重复是因为没有收到，所以继续重发导致的数据重复)

.log

（3）

常规技术

ZooKeeper维护 组、offset(默认0)Partition选举

注册

2、常规技术和零拷贝技术kafka中的消费者在读取服务端的数据时，需要将服务端的磁盘文件通过网络发送到消费者进程，网络发送需要经过几种网络节点。如果有10个消费者，传统方式下数据复制次数为4*10=40次，零拷贝技术只需要1+10=11次，一次为从磁盘复制到页面缓存，10次表示10个消费者各自读取一次页面缓存。

font color=\"#e74f4c\

传统的读取文件数据并发送到网络的步骤如下：（1）操作系统将数据从磁盘文件中读取到内核空间的页面缓存；（2）应用程序将数据从内核空间读入用户空间缓冲区；（3）应用程序将读到数据写回内核空间并放入socket缓冲区；（4）操作系统将数据从socket缓冲区复制到网卡接口，此时数据才能通过网络发送。

1

发送消息

Partition2

Follower从区

Partition4

logs0

消费者分区策略

内核读取缓冲区

Partition-1

一个parition只能交给一个consumer消费，因为交给多个consumer让其进行pull拉取消息进行消费，会引起重复消费的问题如果所有的消费者实例在同一消费组中，消息记录会负载平衡到每一个消费者实例。如果所有的消费者实例在不同的消费组中，每条消息记录会广播到所有的消费者进程。

网卡接口

HW(LEO)

Group-0Consumer-0

客户端（消费者）

5

Producer

生产者2

follower

每个partition还会被复制到其它服务器作为replication，这是一种余备份策略>同一个partition的多个replication不允许在同一broker上>每个partition的replication中，有一个leader，零或多个follower>leader处理此分区的所有的读写请求，follower仅仅被动的复制数据>leader宕机后，会从follower中选举出新的leader

9

Partition-0

Kafka的消息会有多个订阅者，生产者发布的消息会被不同的消费者多次消费，为了优化这个流程，Kafka使用了“零拷贝技术”。只用将磁盘文件的数据复制到页面缓存中一次，然后将数据从页面缓存直接发送到网络中（发送给不同的订阅者时，都可以使用同一个页面缓存），避免了重复复制操作。

ZooKeeper

Partition5

会重复消费

LEO(Log End Offset)

consumer group

KafkaController

获取ISR

组2

ack三种可靠机制

继续发送

Topic A服务器

/brokers/topics/first/partitions/0/state\"leader\

水位一致

零拷贝技术

Hello

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

（2）

 分区模型图

LEO(Log End Offset)：每个副本最后的一个offsetHW(High Watermark)：高水位，指代消费者能见到的最大的offset，ISR队列中最小的LEO。

Segment

Partition6

Topic APartition-0Follower

消费者进程

Kafka0.9版本之前，consumer默认将offset保存在zookeeper中，从0.9版本之后，consumer默认将offset保存在kafka一个内置的topic中，该topic为__consumer_offsets

是否确认收到ack

offset=0

0：producer不等待broker的ack，这一操作提供了最低的延迟，broker接收到还没有写入磁盘就已经返回，当broker故障时有可能丢失数据1：producer等待broker的ack，partition的leader落盘成功后返回ack，如果在follower同步成功之前leader故障，那么将丢失数据。（只是leader落盘）

Group-1Consumer-1

Kafka高效读写

1、顺序写磁盘Kafka的producer生产数据，需要写入到log文件中，写的过程是追加到文件末端，顺序写的方式，官网有数据表明，同样的磁盘，顺序写能够到600M/s，而随机写只有200K/s，这与磁盘的机械结构有关，顺序写之所以快，是因为其省去了大量磁头寻址的时间。

message

详情

8

2

.log文件大小超过1G时，会创建新.log文件。同时为了快速定位大文件中消息位置，Kafka采取了分片和索引的机制来加速定位。在kafka的存储log的地方，即文件的地方，会存在消费的偏移量以及具体的分区信息，分区信息的话主要包括.index和.log文件组成。

HW

Broker1

数据一致性问题

更新leader及ISR

HW(High Watermark)

（4）

producer返ack0无落盘直接返、1只leader落盘然后返、-1全部落盘然后返、

transferTo()

Topic APartition-0Leader

Broker-2

Kafka Cluster

Topic CPartition-0Leader

Topic CPartition-0Follower

组1

文件描述符

应用程序上下文

选举新leader

Topic APartition-1Leade

6

Partition1

Group-0Consumer-1

follower故障和leader故障follower故障：follower发生故障后会被临时提出ISR，等待该follower恢复后，follower会读取本地磁盘记录的上次的HW，并将log文件高于HW的部分截取掉，从HW开始向leader进行同步，等待该follower的LEO大于等于该partition的HW，即follower追上leader之后，就可以重新加入ISR了。leader故障：leader发生故障之后，会从ISR中选出一个新的leader，为了保证多个副本之间的数据的一致性，其余的follower会先将各自的log文件高于HW的部分截掉，然后从新的leader中同步数据。这只能保证副本之间的数据一致性，并不能保证数据不丢失或者不重复

生产者分区策略分区的原因方便在集群中扩展：每个partition通过调整以适应它所在的机器，而一个Topic又可以有多个partition组成，因此整个集群可以适应适合的数据。可以提高并发：以Partition为单位进行读写。类似于多路。分区的原则指明partition（这里的指明是指第几个分区）的情况下，直接将指明的值作为partition的值没有指明partition的情况下，但是存在值key，此时将key的hash值与topic的partition总数进行取余得到partition值值与partition均无的情况下，第一次调用时随机生成一个整数，后面每次调用在这个整数上自增，将这个值与topic可用的partition总数取余得到partition值，即round-robin算法。

Topic BPartition-0Leader

Partition0