Kafka面试必问几个概念

接下来围绕下面几个概念来进行分析

生产者： producer主要是用于生产消息，是kafka当中的消息生产者，生产的消息通过topic进行归类，保存到kafka的broker里面去
消费者：消息消费者，从Broker读取消息的客户端

Topic: Kafka根据topic对消息进行归类，发布到Kafka集群的每条消息都需要指定一个topic

partition: kafka当中，topic是消息的归类，一个topic可以有多个分区，每个分区保存部分topic的数据，所有的partition当中的数据全部合并起来，就是一个topic当中的所有的数据.topic的partition会跨节点分布，一个topic下的多个partition会分布到不同broker上，每个 partition内部消息是有序的;
比如说broker集群有三个 b0,b1,b2 topic: test 有三个partition ,这样3个partittion就会平均分到三个broker上，每一个broker都会有test主题的一个分区 ，这就是kafka的高扩展性

Broker: 消息中间件处理节点，一个Kafka节点就是一个broker，一个或者多个Broker可以组成一个Kafka集群

ConsumerGroup: 消费者组 每个Consumer属于一个特定的ConsumerGroup，一条消息可以被多个不同的Consumer Group消费，但是一个 Consumer Group中只能有一个Consumer能够消费该消息 关于不同消费者消费统一topic数据后面会讲

对于每一个Topic，下面可以有多个分区(Partition)日志文件:

Partition是一个有序的message序列 这些message按顺序添加到一个叫做commit log的文件中。每个partition中的消息都有一个唯一的编号，称之为offset，用来唯一标示某个分区中的message。

每个partition，都对应一个commit log文件。一个partition中的message的offset都是唯一的，但是不同的partition中的message的offset可能是相同的。

kafka一般不会删除消息，不管这些消息有没有被消费。只会根据配置的日志保留时间(log.retention.hours)确认消息多久被删除，默认保留最近一周的日志消息。kafka的性能与保留的消息数据量大小没有关系，因此保存大量的数据消息日志信息不会有什么影响。每个consumer是基于自己在commit log中的消费进度(offset)来进行工作的。在kafka中，消费offset由consumer自己来维护；一般情况下我们按照顺序逐条消费commit log中的消息，当然我可以通过指定offset来重复消费某些消息，或者跳过某些消息。
这意味kafka中的consumer对集群的影响是非常小的，添加一个或者减少一个consumer，对于集群或者其他consumer来说，都是没有影响的，因为每个consumer维护各自的消费offset。

可以这么来理解Topic，Partition和Broker
一个topic，代表逻辑上的一个业务数据集，比如按数据库里不同表的数据操作消息区分放入不同topic，订单相关操作消息放入订单topic，用户相关操作消息放入用户topic，对于大型网站来说，后端数据都是海量的，订单消息很可能是非常巨量的，比如有几百个G甚至达到TB级别，如果把这么多数据都放在一台机器上可定会有容量限制问题，那么就可以在topic内部划分多个partition来分片存储数据，不同的partition可以位于不同的机器上，每台机器上都运行一个Kafka的进程Broker。

Replicats: 其实就是partition的副本，用于数据同步和容灾，保证了kafka的高可用，如kafka集群有三个broker节点  b0,b1,b2  topic:test 有两个分区  每个分区有三个副本replicate  ,此时应该是2*3=6个分区    如下图 表示分区0 分布到broke0上  分区1 分布到broke1上，而且 分区0的两个副本分布在broke1 和broke2上，可以在kafka的数据目录broker下查看replicate日志
1

ISR:表示已同步的副本集，如果Leader宕机后会从ISR里面选一个作为Leader Replicate

当把broke1宕机后，再来检查下分区副本Leader以及Isr

HW俗称高水位，HighWatermark的缩写，取一个partition对应的ISR中最小的LEO(log-end-offset)作为HW，consumer最多只能消费到HW所在的位置。另外每个replica都有HW,leader和follower各自负责更新自己的HW的状态。对于leader新写入的消息，consumer不能立刻消费，leader会等待该消息被所有ISR中的replicas同步后更新HW，此时消息才能被consumer消费。这样就保证了如果leader所在的broker失效，该消息仍然可以从新选举的leader中获取。对于来自内部broker的读取请求，没有HW的限制。

下图详细的说明了当producer生产消息至broker后，ISR以及HW和LEO的流转过程：

由此可见，Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。事实上，同步复制要求所有能工作的follower都复制完，这条消息才会被commit，这种复制方式极大的影响了吞吐率。而异步复制方式下，follower异步的从leader复制数据，数据只要被leader写入log就被认为已经commit，这种情况下如果follower都还没有复制完，落后于leader时，突然leader宕机，则会丢失数据。而Kafka的这种使用ISR的方式则很好的均衡了确保数据不丢失以及吞吐率。再回顾下消息发送端对发出消息持久化机制参数acks的设置，我们结合HW和LEO来看下acks=1的情况
结合HW和LEO看下 acks=1的情况