这是我参与「第五届青训营 」笔记创作活动的第14天
只不过是字节给我的任务罢了
消息队列
-
删库跑路，系统崩溃
- 解耦，将待处理任务放入消息队列
-
服务能力有限
- 削峰，将请求放入消息队列，每次只获取10个请求进行处理
-
链式耗时长尾
- 异步，将订单请求放入消息队列，显示订单正在处理，库存处理完毕后，用户方再显示已经处理的订单
-
日志存储
- 先存入消息队列，再存储
消息队列，是保存消息的一个容器，本质是一个队列，但是这个队列需要支持高吞吐、高并发、并且高可用
- kafka：分布式、分区的、多副本的日志提交任务，高吞吐场景很出色
- RocketMQ：低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，实时场景应用
- Pulsar：下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用存算分离的架构设计
- BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群
Kafka
使用
- 创建集群
- 新增Topic
- 编写生产者逻辑
- 编写消费者逻辑
基本概念
-
Topic：逻辑队列，不同的Topic可以建立不同的Topic
-
Partition，Topic内部分片，可以并发
-
Offset，消息在Partition内部的相对位置信息
-
Replica，每个分片都有多个Replica副本
- Leader，负责读写，从ISR中选出
- Follower，一个Replica有多个Follower，Follower与Leader保持一致，如果与Leader的差距过大（可配置差距），则会被踢出
- ISR（In-Sync Replicas）
-
-
-
Cluster：物理集群，每个集群中可以建立多个不同的Topic
-
Producer：生产者，负责将业务消息发送到Topic中
-
Consumer：消费者，负责消费Topic中的消息
-
ConsumerGroup：消费者组，不同组的Consumer消费进度互不干涉
-
Controller负责告知其他Broker某Topic的分片所在位置
Kafka架构
Producer
- 批量发送，减少IO次数，加强发送能力
- 数据压缩，减少消息大小，目前支持Snappy、Gzip、LZ4、ZSTD压缩算法，推荐ZSTD
Broker
-
数据存储
-
Replica
-
Log
-
LogSegment
- .log日志文件
- .index偏移量索引文件
- .timeIndex时间戳索引文件
- 其他文件
-
-
-
-
磁盘结构
- 采用顺序写的方式，提高写入效率
-
如何找到消息？
- Consumer通过发送FetchRequest请求消息数据，Broker会指定Offset处的消息，按时间窗口和消息大小窗口发送给Consumer
-
Broker偏移量文件
- 二分找到小于Offset的最大文件
-
Broker时间戳索引文件
- 在偏移量文件的基础上添加一层二级索引
-
传统数据拷贝
- 调用系统调用不经过应用空间和SocketBUffer，零拷贝
Consumer
消息的接收端
解决Partition在ConsumerGroup中的分配问题
-
手动分配：哪一个Consumer消费哪一个Partition完全由业务决定
- 优点：快速
- 缺点：不能容灾
-
High Level，Coordinator感知Consumer状态，自动分配
-
Rebalance，选取一个Consumer当Leader，推导出分配方案，Consumer发送心跳
问题
-
数据复制
-
重启操作
- 关闭重启
- 切换Leader
- 数据同步
- Leader回切
-
替换、扩容、缩容
-
负载不均衡
