何为消息队列？

何为消息队列？

消息队列（MQ），指保持消息的一个容器，本质是个队列。但这个队列需要支持高吞吐、高并发、高可用。

常见消息队列对比

• Kafka：分布式的、分区的、多副本的日志提交服务，在高吞吐场景下发挥较为出色。
• RockerMQ：低延迟、强一致、高性能、高可靠、亿万级容量和灵活的可拓展性，在一些实用场景中运用较广。
• Pulsar：是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体、采用存算分离的架构设计。
• BMQ：和Pubsar架构类似，存算分离，初期定位是承接高吞吐的离线业务场景，逐步替换掉对应的Kafka集群。

Kafka

使用场景

离线消息处理中：日志信息、Metrics数据（程序状态、性能采集）、用户行为（搜索、点赞、评论、收藏）

搜索服务、直播服务、订单服务、支付服务

如何使用

1. 采集集群
2. 新增Topic
3. 编写生产者逻辑
4. 编写消费者逻辑

基本概念

• Topic：逻辑队列，不同Topic可以建立不用Topic（业务场景，所有数据都存储在这个业务中）
• Cluster：物理集群，每个集群中可以建立多个不同的Topic
• Producer：生产者，负责将业务消息发送到Topic中
• Consumer：消费者，负责消费Topic中的消息
• ConsumerGroup：消费者组，不同组Consumer消费进度互不干涉
• Partition：将Topic分区，不同分区可以并发处理
• offset：消息在partition内的相对位置信息，可以理解为唯一id，在partition内部严格递增

流程

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

Producer发送Message到Broker，若等到发送成功再发下一条，效率是远远不够的。可以先对消息做一个Batch（批量处理），减少IO次数，加强发送能力。

此时会遇到消息量过大，带宽不够的问题。可以使用压缩算法来解决Snappy、ZSTD等压缩到本地磁盘。那么如何存储？

Broker

消息文件结构

Topic/Partition/Replica/Segement/(log | index | timeindex | ... )

磁盘结构

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

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

如何找到消息

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