Kafka整理篇

kafka的数据可靠性
ack机制和ISR机制。
Leader维护了一个动态的in-sync replica set (ISR)，意为和leader保持同步的follower集合。当ISR中的follower完成数据的同步之后，leader就会给producer发送ack。如果follower长时间未向leader同步数据，则该follower将被踢出ISR列表，该时间阈值由replica.lag.time.max.ms参数设定（默认为30s）。Leader发生故障之后，就会从ISR中选举新的leader。
这里有两个概念：
LEO（Log End Offset）: 每个副本的最后一个offset
HW（High Watermark）: ISR中副本中最小的LEO（即一个分区中的中所有副本最小的offset）
follower故障恢复：
follower发生故障后会被临时踢出ISR，待该follower恢复后，follower会读取本地磁盘记录的上次的HW（即它挂掉时刻的HW），并将log文件高于HW的部分截取掉，从HW开始向leader进行同步。等该follower的LEO大于等于该Partition的HW（即该follwer的LEO>=当前Partition的HW的时候就可以重新加入），即follower追上leader之后，就可以重新加入ISR了。

leader故障恢复：
leader发生故障之后，会从ISR中选出一个新的leader，之后，为保证多个副本之间的数据一致性，其余的follower会先将各自的log文件高于HW的部分截掉（新leader并没有截掉，这样做为了保证效率，如果截掉的数据太多，就得不偿失了），然后从新的leader同步数据。

Kafka生产数据时如何保证生产数据不丢失不重复？（Kafka的Exactly Once语义）
ack+幂等性机制；kafka 0.11版本之后引入了事务，其实是借鉴了MySQL主键思想。将服务器的ACK级别设置为-1，再结合kafka的幂等性机制就能保证Exactly Once。幂等性就是Producer不论向Server发送多少次重复数据，Server端都只会保存一条。启用幂等性，Producer参数enable.idompotence设置为true即可（默认为false）。
Kafka幂等性机制原理：
step1：发送数据时，给每条数据增加一个数据id的编号，每次下一条数据的编号自增1
step2：Kafka将数据写入，并记住写入的数据id
step3：如果下一条数据的id与上一次的数据id一致，就不写入，直接返回ack

Kafka的文件存储机制
每个分区对应一个文件夹，该文件夹的命名规则为：topic名称+分区序号，内部为对应分区的.log和.index文件。最新版本的Kafka还有一个.timeindex文件，即时间索引文件，根据数据的读取时间来建立索引。

Kafka新建的分区会在哪个目录下创建
启动 Kafka 集群前，配置好 log.dirs 参数，其值是 Kafka 数据的存放目录，可以配置多个目录，目录之间使用逗号分隔。
log.dirs 参数配置了多个目录，那么 Kafka 会在哪个文件夹中创建分区目录呢？
Kafka 会在分区文件夹总数最少的目录创建新的分区目录，分区目录名为 topic名称+分区序号。

Kafka的分区分配策略有哪些
Kafka有两种分配策略，一是roundrobin，一是range。
（1） roundrobin（轮询），一个个分配，直到分完为止
（2） range（范围分配），分区数 % 消费者个数。
Kafka 0.9版本之前，consumer默认将offset保存在Zookeeper中，0.9版本之后，consumer默认将offset保存在Kafka一个内置的topic（__consumer_offsets这个topic）中。

Kafka的那些设计让它有如此高的性能？
1.partition：producer和consumer端的批处理：提高并行度；
2.页缓存：大量使用页缓存，内存操作比磁盘操作快很多，数据写入直接写道页缓存，由操作系统负责刷盘，数据读取也是直接命中页缓存，从内存中直接拿到数据；
3.零拷贝:如果数据读取命中了页缓存，数据会从页缓存直接发送到网卡进行数据传输，省略了用户态和内核态的切换以及多次的数据拷贝；
4.顺序读写：Kafka的数据是顺序追加的，避免了低效率的随机读写；
5.优秀的文件存储机制：分区规则设置合理的话，所有消息都可以均匀的分不到不同分区，分区日志还可以分段，相当于举行文件被平均分配为多个相对较小的文件，便于文件维护和清理；
6.索引文件：Kafka含有.index和.timeindex索引，以稀疏索引的方式进行构造，查找时可以根据二分法在索引文件中快速定位到目标数据附近位置，然后再.log文件中顺序读取到目标数据。

Kafka中的ISR、OSR、AR代表什么？
ISR（In-Sync Replicas）：与leader保持同步的follower集合（当然也有leader），当leader挂掉后，从ISR列表中随机选取Leader

OSR：Out-of-Sync Replicas（移除ISR列表的副本集合）

AR（Assigned Replicas）：分区的所有副本

AR=ISR+OSR。

LEO、HW、LSO、LW等分别代表什么？
LEO（Log End Offset）: 每个副本的最后一个offset
HW（High Watermark）: ISR集合中最小的LEO（即一个分区中的中所有副本最小的offset）
LSO：特指LastStableOffset，它与kafka 事务有关。对于未完成的事务而言，LSO的值等于事务中的第一条消息所在的位置（firstUnstableOffset）；对于已经完成的事务而言，它的值等同于HW相同。
LW是Low Watermark的缩写，俗称“低水位”，代表AR集合中最小的logStartOffset（不是LEW）值。

消费组中的消费者个数如果超过topic的分区会怎么样？
一般consumer个数和Topic的分区数相等。如果group中的consumer大于Topic的分区数，多余的消费者不会工作。（如果多个消费者消费一个分区，那不就重复消费了，因为每个消费者都有自己的offset）

kafka整合flume的方式有哪些？
（1）flume写数据到kafka分为2种：
第一种方式：netcatSource->memeory channel->kafkaSink
第二种方式：netcatSource->kafka channel
一般采用第二种方式（该方式不需要sink）
（2）flume从kafka读取数据
kafkaSource->memeory channel->Sink

失效副本是指什么？有那些应对措施？
失效副本为速率比leader相差大于10秒的follower
将失效的follower先提出ISR
等速率接近leader10秒内,再加进ISR

Kafka服务器一次能接收到的最大信息是多少？
Kafka服务器可以接收到的消息的最大大小是1000000（1G）字节。

从Kafka读取数据后，数据会自动删除吗？
不会，kafka中数据的删除跟有没有消费者消费完全无关。
数据的删除，只跟kafka broker上面的这两个配置有关：
log.retention.hours=48 #老版本数据最多保存48小时，新版默认保存7天

聊一聊你对Kafka的Log Retention的理解（留存期）？
1.清除单位：日志清除的单位是日志段，即删除符合清楚策略的日志段文件和对应的索引文件；
2.清除策略：
1.基于时间的留存策略：Kafka默认会清除7天前的日志算数据，可以根据参数进行配置；
2.基于大小的留存策略：Kafka默认只会为每个log保留log.retention.bytes参数值大小的字节数，可以根据参数进行配置；
3.清除过程：日志清除过程是一个异步过程，Kafkabroker启动后会创建单独的县城处理日志清除事宜；
4.注意事项：日志清除对于当前日志段是不生效的；
聊一聊你对Kafka的Log Compaction的理解？
日志压实：确保Kafka topic每个分区下的每条具有相同key的消息都至少保存最新的value的消息，它提供了更加细粒度话的留存策略，也就是说，如果要使用log.compaction1，Kafka必须为每条消息设置key；
特点：log.compaction只会根据某种策略有选择的移除.log中的消息，并不会更改分区日志的offset值；
配置：log.compaction是topic级别的配置，逻辑划分上，log.compaction会将日志划分为已清理部分和未清理部分，后者又可以进一步划分为可清理和不可清理部分。

聊一聊Kafka的延时操作的原理？
Kafka中由多种延时操作，比如延时生产，延时拉取，延时数据删除等；
延时操作创建之后会被加入到延时操作管理器中来做专门的处理，演示操作有时候会超时，每个延时操作管理器都会配备一个定时器来做超时管理，定时器的底层就是采用时间轮实现的。

为什么Kafka不支持读写分离？
读写分离缺点：
数据一致性问题：数据从主节点转到从节点，必然会有一个延时的时间窗口，这个时间窗口会导致主从节点之间的数据不一致；
延时问题：数据从写入主节点到同步至从节点中的过程，需要经历经历网络→主节点内存→主节点磁盘→网络→从节点内存→从节点磁盘阶段，对延时敏感的应用而言，主写从读的功能并不太适用。
当前方案收益：
1.可以简化代码的实现逻辑，减少出错的可能;
2.将负载粒度细化均摊，与主写从读相比，不仅负载效能更好，而且对用户可控（使用partition）；
3.没有延时的影响；
4.在副本稳定的情况下，不会出现数据不一致的情况。

Kafka有什么优缺点？
kafka的优点：
1.支持多个生产者和消费者；
2.支持broker的横向拓展；
3.副本集机制，实现数据冗余，保证数据不丢失；
4.通过分批发送压缩数据的方式，减少数据传输开销，提高吞高量
5.支持点对点和发布订阅；
6.基于磁盘实现数据的持久化；
7.毫秒级延迟；
8.对CPU和内存，网络的消耗比较小；
缺点：
1.由于是批量发送，所以数据达不到真正的实时；
2.只能支持统一分区内消息有序，无法实现全局消息有序；
3.需要配合zookeeper进行元数据管理；
4.可能会重复消费数据，消息会乱序。

还用过什么同质类的其它产品，与Kafka相比有什么优缺点？
ActiveMQ、RabbitMQ。Kafka吞吐量要高很多，而且能保证不丢失不重复，非常适合大数据场景。

Kafka 的Rebalance机制
在Kafka中，当有新消费者加入或者消费者订阅的topic数发生变化（比如更改topic）时，会触发Rebalance(再均衡)。
第一步：所有成员都向coordinator发送请求，请求入组。一旦所有成员都发送了请求，coordinator会从中选择一个consumer担任leader的角色，并把组成员信息以及订阅信息发给leader。
第二步：leader开始分配消费方案，指明具体哪个consumer负责消费哪些topic的哪些partition。一旦完成分配，leader会将这个方案发给coordinator。coordinator接收到分配方案之后会把方案发给各个consumer，这样组内的所有成员就都知道自己应该消费哪些分区了。
所以对于Rebalance来说，Coordinator起着至关重要的作用。

kafka为什么要设计Segment？
加快查询效率：将数据划分到多个小文件中，通过offset匹配可以定位某个文件，从小数据量中找到需要的数据
提高删除性能：以Segment为单位进行删除，避免以每一条数据进行删除，影响性能。