kafka学习

简介

定义

Apache Kafka 是一个开源分布式事件流平台

什么是事件流？

事件流是从数据库、传感器、移动设备、云服务和软件应用程序等事件源以事件流的形式实时捕获数据的做法；持久地存储这些事件流以供以后检索；实时和回顾性地操作、处理和响应事件流；并根据需要将事件流路由到不同的目标技术。

我可以使用事件流做什么？

件流应用于 众多行业和组织的各种用例。它的许多例子包括：

• 实时处理支付和金融交易，例如在证券交易所、银行和保险中。

• 实时跟踪和监控汽车、卡车、车队和货物，例如物流和汽车行业。

• 持续捕获和分析来自 IoT 设备或其他设备（例如工厂和风电场）的传感器数据。

• 收集客户互动和订单并立即做出反应，例如在零售、酒店和旅游行业以及移动应用程序中。

• 监测住院病人并预测病情变化，以确保在紧急情况下得到及时治疗。
  连接、存储和提供公司不同部门产生的数据。

• 作为数据平台、事件驱动架构和微服务的基础。

消息队列

模式

点对点

特点

• 只有一个接收者
• 没有依赖性
• 删除消息

发布订阅

特点

• 多个订阅者
• 针对topic，必须创建一个订阅者后才能消费消息，有依赖性
• 拉取以后消息不回立即删除，有状态

kafka结构

生产者消费者模型

组成

broker

分区（partition）

副本（replication）

生产者（produser）&消费者（consumer）&消费者组（consumer group）

主题（topic）

Topic 是数据被发布到 Kafka 的一个分类

偏移量（offset）

一个分区中，消息时有顺序得方式存储着，每个分区的消息有一个递增id，这个就是偏移量

特性

幂等性

PID：producer唯一标识
Sequence Number：针对每个生产者发送到指定主题分区的消息都对应一个从0开始递增的seq。

消息处理方案

分区和副本机制

生产者分区写入策略

生产者写入消息到topic，kafka将依据不同的策略将数据分配到不同的分区涨

1. 轮询分区策略
2. 随机分区策略
3. 按key分区分配策略
4. 自定义分区策略

消费者Rebalance机制

Rebalance再均衡

Kafka中的Rebalance称之为再均衡，时kafka中确保Consumer group下所有的Consumer如何达成一致，分配订阅的topic的每个分区的机制
触发条件：

• 消费者组中Consumer的个数发生变化
• 订阅的topic个数发生变化
• 订阅的分区数量发生变化

Rebalance影响

• 触发Rebalance时，Consumer Group下的所有Consumer都会协调在一起共同参与，kafka使用分配策略尽可能达到最公平的分配
• Rebalance过程会对Consumer Group产生严重影响，消费者会停止工作直到Rebalance完成

消费者分区分配策略

Range范围分配策略

RoundRobin轮询策略

RoundRobin轮询策略时将消费者组内所有消费者以及消费者订阅的所有topic的partition按照字典序排序（topic和分区的hashcode进行排序），然后通过轮询方式逐个将分区以此分配给每个消费者。

Stricky粘性分配策略

没有发生Rebalance时，Stricky粘性分配策略和RoundRobin分配策略类似

如果上面Consumer2崩溃了

副本机制

produser的ACK机制

ACK = 0

ACK = 1

ACK = -1 & all

kafka原理

分区的Leader和Follower

Leader和Follower

• kafka中的Leader负责处理读写操作，Follower只负责副本数据的同步
• 如果Leader出现故障，其他Follower会被重新选举为Leader
• Follower像一个Consumer一样，拉取Leader对应分区的数据，并保存到日志数据文件中

AR、ISR、OSR

kafka中把follower可以按照不同状态分为三类

• AR：分区的所有副本
• ISR（In-Sync Replicas）：所有与Leader保持一定程度同步的副本
• OSR(Out-of-Sync Replicase)：副本同步滞后过多的副本

AR = ISR + OSR
正常情况下 RSR 应该为空

Controller

• kafak启动时，会在所有的Broker中选择一个Controller
• 前面Leader和Follower时针对Partition，而Controller时针对Broker
• 创建topic、或者添加分区、修改副本数量之类的管理任务都是由Controller完成的
• Kafka分区Leader的选举，也是由Controller决定的

Leader选举

如果Leader崩溃，Kafka会如何？

• 所有Partition的Leader选举 都由Controller决定
• Controller会将Leader的改变直接通过RPC的方式通知需为此作出响应的Broker
• Controller读取到当前分区的ISR, 只要有一个Replica还幸存, 就选择其中一个作为leader否则， 则任意选这个一个Replica作为Leader
• 如果该Partition的所有Replica都已经宕机, 则新的Leader为-1

kafka生产、消费数据工作流程

kafka数据写入流程

kafka数据消费流程

kafka的数据存储形式

文件名	说明
.index	索引文件，根据offset查找数据就是通过该索引
.log	日志数据文件，消息数据
.timeindex	时间索引，清理数据用
leader-epoch-checkpoint	日志文件中下一条待写入消息的offset

消息不丢失机制

Broker数据不丢失

生产者通过分区的leader写入数据后，所有在ISR中follower都会从leader中复制数据，这样，可以确保即使leader崩溃了，其他的follower的数据仍然是可用的。

生产者数据不丢失

生产者连接leader写入数据时，可以通过ACK机制来确保数据已经成功写入。ACK机制有三个可选配置。

1. 配置ACK响应要求为-1时——表示所有的节点都收到数据(leader和follower都接收到数据)。
2. 配置ACK响应要求为 1时——表示leader收到数据
3. 配置ACK影响要求为 0时——生产者只负责发送数据，不关心数据是否丢失(这种情.况可能会产生数据丢失，但性能是最好的)。

消费者数据不丢失

只要每个消费者记录号offset值，就能保证数据不丢失

为什么选择kafka

超过 80% 的财富 100 强公司 信任并使用 Kafka。