本次kafka相关分析总结,以apache kafka为准。
地址:http://kafka.apache.org/documentation/
中文文档地址:https://kafka.apachecn.org/
了解kafka需要先了解以下几个基本概念:
名称
说明
Broker
kafka作为中件,帮我们存储和转发消息,所以我们把kafkar的服务叫做Broker。
Record(消息)
客户端之间传输的数据
Topic
生产者与消费者关联的途径,可以理解为其他消息中间件的队列
Producer
发送消息的生产者
Consumer
接收消息的消费者
Partition与Cluster
topic分区
Segment
partition再做一个切分,切分出来的单位叫段(segment)
Consumer Group
消费组
Consumer Offset
消费偏移量
Broker
Brokder :kafka做为一个中间件,是帮我们存储和转发消息的,它做的事有点像中介,所以我们把kafka的服务叫Broker。生产者和消费者都需要跟这个Broker建立一个连接,才可以实现消息的收发。
消息
客户端之间传输的数据叫做消息,或者叫记录(Record)。 生产者对应的封装类是ProducerRecord,消费者对应的封装类是ConsumerRecord。
消息在服务端存储的格式(Record Batch和Record)
Record Batch
baseOffset: int64
batchLength: int32
partitionLeaderEpoch: int32
magic: int8 (current magic value is 2)
crc: int32
attributes: int16
bit 0~2:
0: no compression
1: gzip
2: snappy
3: lz4
4: zstd
bit 3: timestampType
bit 4: isTransactional (0 means not transactional)
bit 5: isControlBatch (0 means not a control batch)
bit 6~15: unused
lastOffsetDelta: int32
firstTimestamp: int64
maxTimestamp: int64
producerId: int64
producerEpoch: int16
baseSequence: int32
records: [Record]
Control Batches
version: int16 (current version is 0)
type: int16 (0 indicates an abort marker, 1 indicates a commit)
Record
length: varint
attributes: int8
bit 0~7: unused
timestampDelta: varint
offsetDelta: varint
keyLength: varint
key: byte[]
valueLen: varint
value: byte[]
Headers => [Header]
Record Header
headerKeyLength: varint
headerKey: String
headerValueLength: varint
Value: byte[]
生产者
发送消息的一方叫做生产者,接收消息的一方叫做消费者。
为了提升发送速率,生产者不是逐条发送消息给Broker,而是批量发送的。
参数名
默认值
说明
batch.size
16384(byte)
多少条发送一次
linger.ms
5(ms)
批量发送的等待时间
acks
1
0 发出去就确认、1 leader落盘就确认 、all所有Follower同步才完成
retries
3
异常自动重试次数
buffer.memory
33554432(32M)
客户端缓冲区大小,满了也会触发发送
max.block.ms
3000(ms)
获取元数据时生产者的相亲阻塞时间,超时后抛出异常
消费者
一般来说消费者有两种消费模式,一种是pull模式,一种是push模式。
Pull模式就是消息放到Broker,消费者自己决定什么时候去获取。
Push模式是消息放在Consumer,只要消息到达Broker,都直接给消费者。
Kafka只有pull模式。 是因Push模式下,如果消息生产的速度远远大于消费者的速率,那消费者就会不堪重负,直到挂掉。而Pull模式,消费者可以自己控制一次获取多少条消息。
参数名
默认值
说明
max.poll.records
500
一次获取消息数
auto.commit.interval.ms
1000(ms)
消费者自动提交间隔时间
auto.offset.reset
earliest
从最早的数据开始消费(earliest 、 latest、 none)
Topic
生产者如何与消费者关联起来?其他的消息中间件的关联名叫队列,也就是说,生产者发送消息,要指定发给哪个队列。消费者接收消息,要指定从哪个队列接收。
在kafka里面,这个队列叫Topic,是一个逻辑概念,可以理解为一组消息的集合。
参数名
默认值
说明
auto.create.topic.enable
true
是否开启默认创建Topic(生产环境建议关闭,手动控制)
Partition 与 Cluster
如果一个Topic中的消息太多,会带来两个问题:
不方便横向扩展,比如想在集群中把数据分布在不同的机器上实现扩展,而不是通过升级硬件做到,如果一个Topic的消息无法在物理上拆分到多台机器的时候,这个是做不到的。
并发或负载问题,所有客户端操作的都是一个Topic,在高并发场景下性能会大大下降。
如何解决这个问题?我们想到的就是把一个Topic进行拆分(分片思想)。
kafka引入了一个分区(Partition)的概念。一个Topic可以划分成多个分区。
Partition思想上有点类似于分库分表,实现的也是横向扩展和负载的目的。
如:Topic有3个分区,生产者依次发送9条消息,对消息进行编号。
第一个分区 1、4、7,第二个分区2、5、8、第三个分区3、6、9,这个就实现了负载。
每个partition都有一个物理目录。在配置的数据目录下(日志就是数据):
/tmp/kafka-logs/
test-topic-0
test-topic-1
与RabbitMQ不一样的地方是,Partition里面的消息被读取后不会被删除,所以同一批消息在一个Partition里面顺序、追加写入的。这个也是kafka吞吐量大的一个很重要的原因。
Partition 副本 Replica机制
如果partition数据只存储一份,在发生网络或者硬件故障时,该分区的数据就无法访问或者无法回复了。
每个partition可以有若干个副本(Replica),副本必须在不同的Broker上面。一般我们说的副本包括其中的主节点。
举例:部署了3个Broker,该Topic有3个分区,每个分区一共3个副本。
注意:这些存放相同数据的partition副本有Leader(图中红色)和follower(图中绿色)的概念。Leader在哪台机器是不一定的,是通过选举算法选举出来的。
生产者发消息、消费者读消息都是针对leader,主要是为一致性考虑,如Mysql中的主从同步会有一定的延迟问题。follower的数据是从leader同步过来的。
Segment
kafka的数据是放在后缀.log的文件里的。如果一个partition只有一个log文件,消息不断的追加,这个log文件也会越来越大,这个时候要检索数据效率就很低了。
所以把partiton再做一个切分,切分出来的单位就叫做段(Segment)。kafka的存储文件是划分成段来存储的。
默认存储路径:/tmp/kafka-logs/
每个segment都至少有1个数据文件和2个索引文件,这3个文件是成套出现的。
参数名
默认值
说明
log.segment.bytes
1G
一个segment大小
Consumer Group
如果生产者产生消息的速度过快,会造成消息在Broker的堆积,影响Broker的性能。怎么提升消息的消费速率呢?增加消费者的数量。但是这么多消费者,怎么知道大家是不是消费的同一个Topic呢?
所以引入了一个Consumer Group消费组的概念,在代码中通过group id来配置。消费同一个topic的消费者不一定是同一个组,只有group id相同的消费者才是同一个消费者组。
注意:同一个group中的消费者,不能消费相同的partition——partition要在消费者之间分配。
Consumer Offset
上边我们说了,partition里面的消息是顺序写入的,被读取之后不会被删除。
如果消费者挂了或者下一次读取,想要接着上次的位置读取消息,或者从某个特定的位置读取消息,该怎么办呢?会不会出现重复消费的情况?
因为消息是有序的,我们可以对消息进行编号,用来标识一条唯一的消息。
这个编号我们不把它叫做offset,偏移量。
offset记录着下一条将要发送给consumer的消息的序号。
这个消费者跟partition之间的偏移量没有保存在ZK,而是直接保存在服务端。
架构图:
总览: