kafka消息队列
出现背景
解耦合
异步处理
-
秒杀活动
- 1: 风险控制 、2: 库存锁定 、3: 生成订单 、4: 短信通知 、5: 更新数据
通过消息系统将秒杀活动业务拆分开
将不急需处理的业务放在后面慢慢处理
-
秒杀活动
- 1: 风险控制 、2: 库存锁定 、3: 消息系统 、4: 生成订单 、5: 短信通知 、6: 更新数据
流量的控制
-
- 网关在接受到请求后,就把请求放入到消息队列里面
- 2.后端的服务从消息队列里面获取到请求,完成后续的秒杀处理流程。然后再给用户返回结果
- 优点:控制了流量 缺点:会让流程变慢
核心概念
生产者
- Producer 往Kafka集群生成数据
消费者
- Consumer 往Kafka里面去获取数据,处理数据、消费数据 Kafka的数据是由消费者自己去拉去Kafka里面的数据
主题
- topic
分区
- partition 默认一个topic有一个分区(partition),自己可设置多个分区(分区分散存储在服务器不同节点上)
Kafka的集群架构
broker
- 一个kafka服务器就是一个broker
partition
- Topic只是逻辑上的概念,partition在磁盘上就体现为一个目录。
Consumer Group
-
消费组 消费数据的时候,都必须指定一个group id,指定一个组的id假定程序A和程序B指定的group id号一样,那么两个程序就属于同一个消费组。
-
特殊:
- 同一个消费者成员,只有一个能消费topic
- 同一个topic,重新指定一个group id号以后,可以消费
- 不同消费组之间没有影响,消费组需自定义,消费者名称程序自动生成(独一无二)
Controller
- Kafka节点里面的一个主节点,借助zookeeper。
kafka写数据
-
顺序写(追加写)
- 保证写数据性能
零拷贝机制
-
消费者读取数据流程:
- 消费者发送请求给kafka服务
- kafka服务去os cache缓存读取数据(缓存没有就去磁盘读取数据)
- 从磁盘读取了数据到os cache缓存中
- os cache复制数据到kafka应用程序中
- kafka将数据(复制)发送到socket cache中
- socket cache通过网卡传输给消费者
-
linux sendfile技术
- 1.消费者发送请求给kafka服务
- 2.kafka服务去os cache缓存读取数据(缓存没有就去磁盘读取数据)
- 3.从磁盘读取了数据到os cache缓存中
- 4.os cache直接将数据发送给网卡
- 5.通过网卡将数据传输给消费者
Kafka日志分段保存
-
topic_a
-
三个分区
-
服务器1
-
目录topic_a-0
-
kafka数据就是message
-
数据存储在log文件里
- .log结尾的就是日志文件
- 在kafka中把数据文件就叫做日志文件
-
(分段存储)
-
一个分区下面默认有n多个日志文件
- 一个日志文件默认1G
-
-
-
-
服务器2
- 目录topic_a-1
-
服务器3
- 目录topic_a-2:
-
-
Kafka二分查找定位数据
-
一条消息就有两个位置
-
offset:相对偏移量(相对位置)
- 存在物理磁盘上面,在position Position
-
position:磁盘物理位置
-
-
稀疏索引
- kafka每当写入了4k大小的日志(.log),就往index里写入一个记录索引。其中会采用二分查找。
高并发网络设计
-
NIO
- Reactor网络设计模式
Kafka冗余副本保证高可用
-
创建主题时,可以指定分区,也可以指定副本个数
-
副本是有角色的:leader partition
- 1、写数据、读数据操作都是从leader partition去操作的。
- 2、会维护一个ISR(in-sync- replica )列表,但是会根据一定的规则删除ISR列表里面的值
-
生产者发送消息流程
- 消息首先要写入到leader partition中
- 写完了以后,还要把消息写入到ISR列表里面的其它分区,写完后才算这个消息提交
- follower partition:从leader partition同步数据
优秀架构思考-总结
高并发、高可用、高性能
-
高可用:多副本机制
-
高并发:网络架构设计
- 三层架构:多selector -> 多线程 -> 队列的设计(NIO)
-
高性能:
-
写数据
- 把数据先写入到OS Cache
- 写到磁盘上面是顺序写,性能很高
-
读数据:
- 根据稀疏索引,快速定位到要消费的数据
- 零拷贝机制 减少数据的拷贝 减少了应用程序与操作系统上下文切换
-
实际应用
coordinator
-
每个consumer group都会选择一个broker作为自己的coordinator
-
他是负责监控这个消费组里的各个消费者的心跳,以及判断是否宕机,然后开启rebalance的
-
运行流程
- 1)每个consumer都发送JoinGroup请求到Coordinator
- 2)然后Coordinator从一个consumer group中选择一个consumer作为leader
- 3)把consumer group情况发送给这个leader
- 4)接着这个leader会负责制定消费方案
- 5)通过SyncGroup发给Coordinator
- 6)接着Coordinator就把消费方案下发给各个consumer
- 他们会从指定的分区的 leader broker开始进行socket连接以及消费消息
Rebalance
-
consumer group靠coordinator实现了Rebalance
-
策略
-
range
-
range策略就是按照partiton的序号范围
- p0~3 consumer1
- p4~7 consumer2
- p8~11 consumer3
-
-
round-robin
-
轮询分配
- consumer1: 0,3,6,9
- consumer2:1,4,7,10
-
-
sticky
-
尽可能保证在rebalance的时候,让原本属于这个consumer 的分区还是属于他们,然后把多余的分区再均匀分配过去,这样尽可能维持原来的分区分配的策略
- consumer1:0-3 consumer2: 4-7 consumer3: 8-11
- 假设consumer3挂了
- consumer1:0-3,+8,9 consumer2: 4-7,+10,11
-
-
controller如何管理整个集群
- 1: 竞争controller的 /controller/id
- 2:controller服务监听的目录:/broker/ids/ 用来感知 broker上下线 /broker/topics/ 创建主题,我们当时创建主题命令,提供的参数,ZK地址。
- /admin/reassign_partitions 分区重分配 ……
时间轮机制
延时任务
Broker管理
-
LEO
- 在kafka里面,无论leader partition还是follower partition统一都称作副本(replica)。
- 每次partition接收到一条消息,都会更新自己的LEO,也就是log end offset,LEO其实就是最新的offset + 1
-
HW
- 高水位 LEO有一个很重要的功能就是更新HW,如果follower和leader的LEO同步了,此时HW就可以更新 HW之前的数据对消费者是可见,消息属于commit状态。HW之后的消息消费者消费不到。
其他
- Kafka的核心原理
如何去评估一个集群资源
搭建了一套kafka集群 -》 介绍了简单的一些运维管理的操作。
生产者(使用,核心的参数)
消费者(原理,使用的,核心参数)
broker内部的一些原理
XMind - Trial Version