消息队列|青训营笔记

前言

案例1：系统崩溃

假如我们在抖音搜索直播间，点开了一个商品详情。会形成一个行为记录。请求会先到搜索商品这个服务，并且记录下搜索行为，然后点击商品的时候，记录我们点击的商品，这些数据最终会通过计算分析，目的是为了下一次给出更准确的信息。

如果此时记录存储所在的机房被删库跑路了

解决方案：解耦

案例2：服务能力有限：

如果订单过多，服务器能处理的请求太少

解决方案：削峰

案例3：链路耗时长尾

前两步较快，但是通知商家较慢，如何优化？

解决方案：异步

消息队列种类

• Kafka:分布式的，分区的，多副本的日志提交服务，在高吞吐下优势大
• Rocket:低延迟，强一致性，高性能，高可靠性，万亿级容量和灵活的可扩展性，实时场景运用较多
• Pulsar:下一代云原生分布式消息流平台，集消息，存储，轻量化函数式计算为一体、采用存算分离的架构设计
• BMQ:和Pulsar相似，存算分离，初期定位是承接高吞吐的离线业务，逐步替换kafka集群

Kafka

-使用场景

• 使用流程

1. 创建kafka集群
2. 在集群中新增topic
3. 引入对应语言的SDK，配置好集群和Topic等参数，初始化生产者，调用Send方法，发送消息
4. 引入对应语言的SDK，配置好集群和Topic等参数，初始化消费者，调用Poll方法，拉取消息

• 基本概念

1. Topic:Kafka中的逻辑队列，可以理解为每一个不同的业务场景就是一个不同的topic,这个业务所有的数据都存储在这个topic中
2. Cluster：物理集群，每个集群可以新建多个不同的Topic
3. Producer:消息生产者，将业务消息发送到Topic中
4. Consumer：消息消费者，负责消费topic中的消息
5. Partition：通常Topic会有多个分片，不同的分片消息可以并发处理，提高单个Topic的吞吐
6. ConsumerGroup：消费者组，不同组Consumer消费进度互不干涉

7. offset:消息在partition内的相对位置信息，可以理解为唯一ID，在partition内部严格递增

8. Replica:分片的副本，分布在不同的机器上，可以用来容灾，Leader对外服务，Follower异步拉取leader的数据进行同步。如果leader挂掉了，可以将follower提升称为leader.每个分片有多个Replica,Leader Replica将会从ISR（同步中的副本）中选出

• 数据复制

Kafka中的副本分布图。每个Broker代表一个Kafka几点，所有的Broker节点组成了一个集群。Broker中的一个也作为Controller，负责对副本和Broker进行分配

• Kafka架构

集群的基础上，还有一个模块是Zookeeper，存储了集群的元数据信息，比如副本的分配信息等。COntroller计算好的方案会放到这里

• Producer

1. 批量发送

消息量大，带宽可能不够

3. 数据压缩

3. 数据的存储

   

• 消息文件结构

数据路径：/Topic/Partition/Segment/(log|index|timeindex|...)

• Broker 磁盘结构

所以Broker采用的是顺序写，末尾追加，提高写入效率 ....

BMQ

Rocket