Kafka重点内容

\1. Kafka如何保证数据不丢失 如何保证不重复

producer 生产端是如何保证数据不丢失的 ack+hw+isr 都不能100%解决.

consumer端是如何保证数据不丢失的  ISR： enable.auto.commit=false（手动）

Kafka幂等写⼊可以保证同⼀分区数据不会重复.

\2. Kafka副本ISR的作⽤?为什么需要ISR?原理是什么?

检测folloer是否在线，有没有失去联系
当ACK等于-1的时候，如果有follower同步过慢，会造成数据重复
ISR定期检测follower与leader的同步进度，当同步过慢时，默认此folloer宕机，删除出group


ReplicaManager(副本管理器)依据replica.lag.time.max.ms(允许副本落后的最⼤时间)参数决定固定副本是否
加⼊ISR.
只要存在ISR中的副本,肯定是和leader同步的.

当ack=-1时,Kafka采⽤的全部follower同步策略.但这种情况下⽆法防⽌某些副本宕机的情况,leader不可能⽆限
等待这个follower,所以重新维护⼀个动态副本同步列表(ISR).

ISR同步源码解析:ReplicaManager
 val ReplicaLagTimeMaxMs = 10000L //10s kafka.server.Defaults#ReplicaLagTimeMaxMs
 实现上调度周期是5s.

\3. Kafka为什么快 ?

log有索引（index），
log文件顺序写入（本地文件）
读取零copy技术，Nginx
批量
数据压缩

\4. Kafka的应答机制是什么 ACK不同取值情况下会有哪些⻛险?

ACK机制来
当等于ack=0 的时候，producer 不需要cluster的确认
	有可能数据丢失
当等于1 的时候，只需要leader回复即可
	有可能数据丢失：当发送数据后，其他操作出现失误，而leadery已经回复
	有可能数据重复：当发送数据后，leader失误（宕机）没有回复，会再次发送数据
当等于-1的时候，需要所有的分区副本都完成确认，由leader回复
	基本保证不会丢数据
	幂等写入保证不重复实现EOS语义
	有可能数据重复：当发送数据后，leader或者follower出现失误无法回复时，会再次发送数据

\5. Kafka如何保持数据的，有没有时间限制 ?retention

设置kafka保存数据的时间
	在 server.properties中配置
	log.retention.minutes=7days
	log.cleanup.policy = delete

Kafka定期为那些超过磁盘空间阈值的topic进行日志段的删除。这个阈值由broker端参数log.retention.bytes和topic级别参数retention.bytes控制，默认是-1，表示Kafka当前未开启这个留存机制，即不管topic日志量涨到多少，Kafka都不视其为“超过阈值”。如果用户要开启这种留存机制，必须显式设置log.retention.bytes（或retention.bytes）。 

一旦用户设置了阈值，那么Kafka就会在定时任务中尝试比较当前日志量总大小是否超过阈值至少一个日志段的大小。这里所说的总大小是指所有日志段文件的大小，不包括索引文件的大小！如果是则会尝试从最老的日志段文件开始删起。注意这里的“超过阈值至少一个日志段的大小”，这就是说超过阈值的部分必须要大于一个日志段的大小，否则不会进行删除的，原因就是因为删除的标的是日志段文件——即文件只能被当做一个整体进行删除，无法删除部分内容。

举个例子来说明，假设日志段大小是700MB，当前分区共有4个日志段文件，大小分别是700MB，700MB，700MB和1234B——显然1234B那个文件就是active日志段。此时该分区总的日志大小是3*700MB+1234B=2100MB+1234B，如果阈值设置为2000MB，那么超出阈值的部分就是100MB+1234B，小于日志段大小700MB，故Kafka不会执行任何删除操作，即使总大小已经超过了阈值；反之如果阈值设置为1400MB，那么超过阈值的部分就是700MB+1234B > 700MB，此时Kafka会删除最老的那个日志段文件。

\6. Kafka为什么整合Flume

Kafka可以作为flume的source、channel、sink
流处理

我们很多人在在使用Flume和kafka时，都会问一句为什么要将Flume和Kafka集成？那首先就应该明白业务需求，一般使用Flume+Kafka架构都是希望完成实时流式的日志处理，后面再连接上Flink/Storm/Spark Streaming等流式实时处理技术，从而完成日志实时解析的目标。

1. 生产环境中，往往是读取日志进行分析，而这往往是多数据源的，如果Kafka构建多个生产者使用文件流的方式向主题写入数据再供消费者消费的话，无疑非常的不方便。

2. 如果Flume直接对接实时计算框架，当数据采集速度大于数据处理速度，很容易发生数据堆积或者数据丢失，而kafka可以当做一个消息缓存队列，从广义上理解，把它当做一个数据库，可以存放一段时间的数据。

3. Kafka属于中间件，一个明显的优势就是使各层解耦，使得出错时不会干扰其他组件。

   因此数据从数据源到flume再到Kafka时，数据一方面可以同步到HDFS做离线计算，另一方面可以做实时计算，可实现数据多分发。

\7.Flume:BTC (batchsize,transactionCapacity,capacity)

```java
   batchSize——Maximum number of messages written to Channel in one batch 每批次写入channel的最大条数
    
    capacity——The maximum number of events stored in the channel channle 容纳的最大event条数
    
    transactionCapacity
    ——The maximum number of events the channel will take from a source or give to a sink per transaction
    从source获取或传递给sink的每个事务（每个处理过程）最大event条数
    
    batchSize <= transactionCapacity <= capacity

    
    
1.如何从__consumer_offsets 主题中找到你要的消费组的进度 

2.enable.auto.commit=false时并且没有⼿动提交,如何跟踪当前consumer的offset