为什么需要消息队列？

首先要知道什么是消息队列：消息队列通过解耦生产与消费者来实现消息异步、流量控制等功能。

那么什么是生产者/消费者：生产者通常是业务动作的发起者，生产需要被传递或处理的业务数据，可以是订单系统、支付系统、传感器设备等；而消费者通常是下游服务或数据分析模块，比如库存系统、Spark 作业等。

为什么需要解耦生产者和消费者：消息队列产品的主要作用就是转储日志、监控数据等，举个例子就像丰巢快递柜，快递员若是不能把快递及时送到人员手上会造成快递拥堵，效率减慢；但是有丰巢柜来存储后就可以有一个地方暂存，消费者需要消费的时候再去拿快递，拉消息一样的道理。通过消息队列，业务系统可以做到故障隔离（生产者宕机不影响消费者）弹性扩展（应对流量波动），真正实现“高内聚、低耦合”的业务架构。

为什么叫消息队列为集群？

集群是一组节点的集合，节点可以是物理机或虚拟机。消息队列产品采用了分布式架构设计，通过多节点协作实现高可用、高性能和可扩展性（具体参见上面的架构设计图）。

命名空间是做什么的？

命名空间能在多租户之间实现逻辑隔离。

首先要理解多租户的概念，多租户就是多个用户共享一个集群。消息队列产品通过命名空间和角色权限的配合来实现权限管控，从而实现不同命名空间之间的逻辑隔离。具体来讲就是为用户（角色）配置某个命名空间内的读写权限，一个命名空间里的所有 topic 都继承相同的设置，则用户只对该命名空间内的 topic 有操作权限。可以参考下图帮助理解：

如何理解 topic 这个概念？

在学习消息队列产品的过程中，要注意区分逻辑概念和物理概念。像 topic 和 partition 都是业务上的逻辑概念，实际上最后消息都是以一个个 segment 文件的形式存储在物理机器上。

topic 代表了消息的类别或主题，是生产消费的最小单位。从业务层面来讲，topic 就像是一个消息的分类标签，生产者将相关的消息发送到特定的 topic 中，而消费者则通过订阅感兴趣的 topic 来获取和处理这些消息。这种设计使得不同业务领域的消息能够自然地隔离，比如订单系统的消息可以发布到"order_topic"，而支付系统的消息则流向"payment_topic"，从而实现业务逻辑的清晰划分。

topic 的设计还体现了消息队列的关键特性——发布/订阅模式。生产者不需要知道有哪些消费者存在，只需关注将消息发送到正确的 topic；同样，消费者也只需订阅自己关心的 topic，无需感知消息的生产者是谁。这种松耦合的架构使得系统各组件能够独立演化，大大提升了整体架构的灵活性。此外，通过 topic 可以实现消息的多播，即一条消息可以被多个消费者组同时消费，这在需要将同一数据用于不同业务场景时显得尤为重要。

什么是数据落盘？

计算机存储分为磁盘、内存和缓存等。

消息队列将接收到的数据写入磁盘持久化存储的过程叫做落盘，比如消息存储到 kafka 和 rocketmq 的 broker 以及 pulsar 的 bookie 的磁盘上这个过程。

具体实现上，kafka 是将消息先写入 Page Cache（内存缓冲），再异步刷盘（可配置同步刷盘），RocketMQ 支持同步刷盘（每条消息立即写入磁盘）或异步刷盘（批量写入）。

消息队列如何保证数据的一致性？

kafka 通过 ISR（In-Sync Replicas）机制来维护数据一致性。当生产者发送消息时，Leader 副本会先将消息写入本地日志，然后要求所有 ISR 中的 Follower 副本完成同步复制后，这条消息才会被确认为已提交。

RocketMQ 采用了双重保障机制来维护数据一致性。首先是同步刷盘策略，当 Broker 接收到消息后，可以选择立即将消息写入磁盘（同步刷盘）而非仅保留在内存中。其次是主从同步机制，每个主节点都会将消息同步到其从节点，只有当主从都成功写入后才会向生产者返回确认响应。

Pulsar 依赖 BookKeeper 作为底层存储引擎，每条消息都会被同步复制到多个 Bookie 节点，只有当大多数节点确认写入后，这条消息才会被标记为持久化成功。