borker

kafka集群可能由多个服务器组成，一个服务器称为一个broker。

topic

kafka是按照topic 来区分消息的，发往同一个topic的消息可以看作一类消息。topic以文件的方式来存储消息。为了解决大文件的问题，提出了分区的概念

分区

一个topic可以对应多个分区，简单理解为一个文件按照分区数目被切分。这样的好处是提高了生产者写的消息，可以并行写。消费的效率也提高了，可以并行读。

副本

数据的备份

生产者相关的

生产者可以配置发送失败的重试次数

发送缓冲区

消息会先被放入到缓冲区内，kafka会从从缓冲区内拉取指定大小的数据发送，如果没有达到指定的大小，会在一定的等待时间后发送消息

消费者相关的

消费组

一个消费组内可以有多个消费者

消费组和分区的关系

一个分区只能被一个消费组内的一个消费者消费
消费组的一个消费者可以消费多个分区。

之所以做这个限制，是为了保证一个分区内消息在一个消费组内消费的有序性。如果一个分区可以被一个消费组内的多个消费者消费，由于消费速度不同，无法保证消息被顺序消费。但是无法保证一个topic多个分区总体消费的有序性。

消费offset

消费者在消费消息的时候，会向topic提交消费信息的offset，可以在一定程度上保证不会重复消费消息。这些信息会保存在一个默认的topic内，保存信息中包含topic，分区，offset等信息

消费者自动提交和手动提交 offset

自动提交，存在重复消费或漏消费的情况，通过参数来配置系统自动提交offset的时间间隔。如果在数据消费过程中出现了异常，可能产生问题。比如自动提交间隔很短，但是业务处理时间很长，在自动提交offset后，业务端数据还没有落盘就异常了，那么重启后这条数据就被遗漏了。反之自动提交间隔长，处理多条数据后才提交offset，业务端异常重启后就会重复消费
手动提交，消费者消费完消息后在提交对应的offset，手动提交也无法保证精确一次性消费。只有业务端支持事务，保证offset的提交和数据落盘在一个事务中，才能保证精确一次性消费
- 同步提交
- 异步提交

消费者消费消息的配置

可以设置每次pull 消息的最大数目
可以设置每次pull消息所耗费的最大时间，如果在规定时间内拉取到了设置的最大数目就停止pull，处理消息。如果没有达到最大数目，达到最大时间后就停止拉取消息，处理获取到的消息
可以设置pull的时间间隔。如果两次pull的时间超过了设定值，kafka认为消费能力弱，会把消费者踢出集群，触发rebalance

新消费者offset

默认是消费最新的消息
可以设置从从开始消费，也会消费历史消息

消费者分配策略

range ，根据分区个数，消费者数目，按照公式，每个消费者消费指定的分区
round ，每个消费者依次消费每个分区。
sticky，如果出现rebalance，保证原有的消费者和分区的消费关系不变。只会重新规划变化的部分。

rebalance机制

前提是消费者没有指定消费那个分区。这是会触发rebalance，为消费者指定分区

hw 和 leo

LEO 指的是最后一条消息的位置
hw指的是最小的leo 值，对于消费者而言，只能消费hw之前的数据。通过这种方式保证了数据的可靠性这两个概念是针对一个分区和此分区对应的副本而言的。假设一个分区由两个副本，由于消息的读写都是通过leader来处理的，leader在存储消息后，会通知副本存储。2个副本的同步可能存在时间差。假设当前有2条消息，hw 和leo 都是2，消费者可以消费这两条消息，随后写入了三条消息，hw 为2 ，leo 为5 。当副本一同步了2 条消息，副本二同步了一条消息后，hw 为3，leo还是5 ，消费者可以消费3条消息。但副本一和二同步了所有消息后，hw变为5，leo 还是5 ,这时消费者可以消费5条消息

如何保证消息的可靠性

发送端的可靠性。
- 要采用同步发送的方式。
  - ack 为0，可靠性最低，不需leader确认是否收到了消息。
  - ack 为1 ，leader 确认接受到了消息，但是消费没有被follower备份
  - ack 为all ，leaser收到消息，并所有的follower已备份
broker的可靠性
- 在ack 为 0，或1 的情况下，如果leader故障。导致消息丢失
消费端手动提交

kafka 发送幂等性

开启相关配置，发送方会自动携带发送方的id 和序列id（顺序增加的），由broker来进行重复消息的处理。这种方法有一定的局限性，可以保证单一分区的幂等性，但是多分区无法保证（个人理解和生产者分区策略相关，假如是轮询分配分区，在消息发送到分区后，由于网络原因，生产者没有收到应答，导致了重新发送，按照轮询策略应该发到下一个分区了，对于同一个topic的两个分区而言收到了重复的数据）。生产者重启后会导致发送方id 的变化，影响了幂等性。

如何保证消息的可靠行和幂等性

发送端配置 ack 为all ，保证数据的到达到broker。开启幂等性，保证数据不重复
broker配置多分区，多副本，保证数据的可靠性
消费端开启手动确认，开启事务，消费端的后续操作也要支持事务，保证提交offset 和后续的数据操作在一个事务中完成，防止漏消费和重复消费