本次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，而是直接保存在服务端。
架构图：
总览：
