為什么需要消息隊列？

首先要知道什么是消息隊列：消息隊列通過解耦生產與消費者來實現消息異步、流量控制等功能。

那么什么是生產者/消費者：生產者通常是業務動作的發起者，生產需要被傳遞或處理的業務數據，可以是訂單系統、支付系統、傳感器設備等；而消費者通常是下游服務或數據分析模塊，比如庫存系統、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 節點，只有當大多數節點確認寫入后，這條消息才會被標記為持久化成功。