Kafka基础知识

Kafka概述

###1.1 定义：
kafka分布式基于发布/订阅的消息队列

###1.2 应用场景：

1.异步处理 发送短信

2.流量消峰 秒杀系统

好处：

1.解耦 允许独立修改和扩展程序， 确保接口约束

2.可恢复性 一部分组件失效后，不会影响到整个系统。消息队列降低了耦合度，一个消息的进程挂掉，加入队列中在恢复仍可继续处理。

3.缓冲 有助于控制和优化经过系统的速度，解决生产者和消费者速度不一致的问题。

4.灵活性 流量消峰 访问剧增，突发流量并不常见，用这种处理方式造成资源浪费，使用消息队列顶住访问压力，不会因为突发的请求造成系统崩溃

5.异步处理 将消息放入队列中，需要的时候进行处理

###1.3 消息队列的两种模式

(1)点对点 不会持久化，消息发送到Queue中消费之后就删除，一个消息只能有一个消费者

(2)发布/订阅 一对多，消息发布到topic中，会被所有的消费者进行消费

###1.4 kafka基础架构

1.为方便拓展，提高吞吐量，一个topic分为多个partition（分区器）

2.配合分区，提出消费者组，组内每个消费者并行消费

3.为提高可用性，为每个partition增加若干副本，类似NameNode HA(不在同一个节点)

• Producer：生产者
• Consumer：消费者
• Consumer Group （CG）：多个消费者组成，每个消费者负责消费不同分区的数据，一个分区只能由一个消费者消费
• Brocker 一台kafka就是一个brocker，可以有多个topic
• Topic：一个队列，消费者和生产者面向topic
• Partition：一个非常大的topic分布到多个brocker上，一个topic分为多个partition
• Replica：副本，某个节点发生故障，该节点上partition数据不丢失，kafka继续工作

kafka集群部署

kafka架构深入

3.1 工作流程以及文件存储

生产者生产消息，面向topic；每个分区对应log文件，存放生产的数据，Producer生产的数据会不断加到log文件末端，且每条数据都有offset，消费者实时记录消费到哪个offset，出错时，从上次的位置继续消费。

为了防止log文件过大，采取了分片和索引机制，每个partition分为多个segment，每个segment下有.log和.index文件，命名规则以第一条消息的offset命名，
.index 存储大量索引信息 .log大量数据 索引文件的元数据指向对应数据文件message的偏移物理地址

3.2 Kafka生产者

分区策略

分区原因： 1. 方便在集群中扩展，通过调整适应所在的机器 2. 可以提高高并发（以Partition进行读写）

分区原则： 1.指明partition，将指明的值作为partition的值 ； 2.没有partition值但有key值，将key的hash值与topic值取余得到partition值； 3.两者都没有，第一次随机取一个整数，后面自增，将这个值与topic的值取余得到partition值

数据可靠性保证

保证Producer给topic发送数据成功，都要向Producer发送ack（acknowledgement确认收到），若producer收到ack，就会进行下一轮的发送，否则重新发送。

副本同步策略：1.全部副本同步之后进行发送，容忍n个节点故障，至少n+1副本，延迟高； 2.半数以上完成同步，就发送ack，容忍n个节点故障，至少2n+1副本
kafka选择全部，副本太多，每个分区大量的数据冗余，网络延迟对kafka影响小

ISR 全部同步，假如有一个节点故障，迟迟不能同步。leader维护了一个动态in-sync replica set (ISR)，和leader同步的follower集合，当ISR中都同步完成，就会发送ack，如果长时间未同步，就会踢出ISR，Leader挂掉，重新从ISR中选举leader
阈值由replica.lag.time.max.ms参数决定

ack应答机制：对于某些数据可靠性要求不太高，能够容忍少量丢失，没必要全部等ISR同步完成，kafka提供3种级别，进行权衡
0：最低的延迟，broker一收到还没等写入磁盘就已经返回；1：leader落盘成功，就返回ack；-1（all）：partition的leader和follower全部落盘成功，才返回；返回ack之前，leader挂掉，可能导致数据重复

故障处理细节：LEO:每个副本最后一个offset HW：所有副本最小的LEO
follower故障：就会踢出ISR，恢复之后，follower就会读取本地磁盘记录上次的HW，将高于HW的部分截取掉，从HW向leader进行同步，等LEO大于等于HW，即追上leader之后，重新加入ISR；

leader故障：从ISR中重新选举leader，将log文件中高于HW部分截取掉，从新的leader同步数据，只能保证数据一致性的问题

Exactly Once

保证每条数据发送且只发送一次
idempotent（幂等性机制） + at least once = exactly once
使用时，只需将enable.idempotence属性设置为true，kafka自动将acks属性设为-1。

3.3 Kafka 消费者

消费方式

1.push方式，速率是broker决定，以最快的速度传递消息，来不及处理消息造成堵塞；pull方式，陷入一个长轮询，传入一个timeout，当前没有数据可供消费，consumer等待一段时间返回

分区策略

1.roundrobin：轮询 TopicAndPartition 按照主题和分区进行消费
2.range 默认策略，按照主题进行消费

offset维护

consumer消费过程中出现宕机故障，恢复后继续消费，记录上次消费offset；将offset保存在kafka内置的一个topic主题中，__consumer_offsets

高效读写

1.顺序写磁盘 追加到log文件末端 2.零复制技术

Zookeeper在kafka作用

Kafka集群中有一个broker会被选举为Controller，负责管理broker上下线，所有topic分区副本和leader选举
Controller管理工作依赖于Zookeeper

kafka API

4.1 Producer API

4.1.1 消费发送流程

发送消息采取的是异步发送的方式，涉及到了2个线程，main线程和Sender线程，以及线程共享变量RecordAccumulator；Send线程不断从RecordAccumulator中拉取数据到Kafka broker
batch.size:只有数据累积到batch.size，sender才会发送数据
linger.ms 如果数据迟迟未达到batch.size，sender等待linge.ms之后就会发送数据

4.2 Consumer API

Consumer消费数据可靠性很容易保证，kafka数据是持久化的，不用担心数据丢失问题；consumer消费过程中可能宕机，需要记录消费到哪个offset，以便继续消费。

4.2.1 手动提交offset

手动提交方法有2种：commitSync(同步提交)和commitAsync(异步提交)；相同点：都会将poll最高的一次偏移量提交。
同步提交会进行失败尝试，直到提交成功。异步提交没有失败机制，可能提交失败；可能造成数据重复消费

自动提交offset

4.3 自定义Interceptor

对于producer而言，interceptor在消息发送前和回调逻辑前有机会对消息做一些定制化需求