这是我参与「第五届青训营」伴学笔记创作活动的第11天。

1 走进消息队列

1.1 案例一：系统崩溃

如果此时记录存储程序所在的机房被删库跑路了，上面这个流程会发生什么问题？

解决方案：解耦

1.2 案例二：服务能力有限

面对庞大的请求量，处理订单的服务一脸茫然，它的命运该何去何从？

解决方案：削峰

1.3 案例三：链路耗时长尾

对于这个流程应该怎么优化来挽回这个暴躁的用户？

解决方案：异步

1.4 案例四：日志存储

解决方案：日志处理

1.5 消息队列

定义：指保存消息的一个容器，本质是个队列。但这个队列呢，需要支持高吞吐，高并发，并且高可用。

1.6 消息队列前世今生

1.6.1 发展历程

1.6.2 业界消息队列对比

Kafka：分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色。

RocketMQ：低延迟、强一致、高性能、高可靠、万亿级容量和灵活的可扩展性，在一些实时场景中运用较广。

Pulsar：是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计。

BMQ：和Pulsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。

2 Kafka

2.1 使用场景

2.2 如何使用Kafka

2.3 基本概念

Topic：逻辑队列，不同Topic可以建立不同的Topic。

Cluster：物理集群，每个集群中可以建立多个不同的Topic。

Producer：生产者，负责将业务消息发送到Topic中。

Consumer：消费者，负责消费Topic中的消息。

ConsumerGroup：消费者组，不同组Consumer消费者进度互不干涉。

2.3.1 基本概念-Offset

定义：消息在partition内的相对位置信息，可以理解为唯一ID，在partition内部严格递增。

2.3.2 基本概念-Replica

每个分片有多个Replica，Leader Replica将会从ISR中选出。

2.4 数据复制

2.5 Kafka架构

ZooKeeper：负责存储集群元信息，包括分区分配信息等。

2.6 一条信息的自述

从一条消息的视角，看看为什么Kafka能支撑这么高的吞吐？

如果发送一条消息，等到其成功后再发一条会有什么问题？

2.7 Producer-批量发送

如果消息量很大，网络带宽不够用，如何解决？

2.8 Broker-数据的存储

、

Broker消息文件结构

磁盘结构：移动磁盘找到对应磁道，磁盘转动找到对应扇区，最后写入。寻道成本比较高，因此顺序写可以减少寻道所带来的时间成本。

Broker-顺序写

采用顺序写的方式进行写入，以提高写入效率。

如何找到消息：Consumer通过发送FetchRequest请求消息数据，Broker会将指定Offset处的消息，按照时间窗口和消息大小窗口发送给Consumer，寻找数据这个细节是如何做到的呢？

Broker偏移量索引文件

目标：寻找offset=28

二分找到小于目标offset的最大索引位置，再通过寻找offset的方式找到最终数据。

传统数据拷贝

零拷贝

2.9 Consumer-消息的接收端

Low Level：通过手动进行分配，哪一个Consumer消费哪一个Partition完全由业务来决定。

High Level：