RocketMQ 流存储解析：面向流场景的关键特性与典型案例
内容提要
RocketMQ 5.0发布，专注于云原生架构，覆盖更多业务场景。引入了“流存储”概念，用于数据集成，并提供静态主题扩展、高吞吐量和结构化消息的模式。适用于日志收集和分析、异构数据库的实时同步等场景。
延伸解读
流存储与消息场景的核心差异
文章指出，消息场景侧重业务集成，连接业务应用，解耦业务架构，类似OLTP，单次操作数据量少，要求低延迟；而流场景侧重数据集成，连接数据组件，解耦数据架构，类似OLAP，单次操作数据量大，侧重批量吞吐。这种差异决定了流存储的访问模式不同：需要固定分区数、按队列读写、支持checkpoint和分片内有序，而消息场景只需关注Topic资源。
静态Topic扩容如何解决数据迁移难题
传统RocketMQ扩容需新增队列，导致分区数变化，不满足流存储固定分区需求；Kafka扩容虽保持分区数，但需迁移分区数据，可能引发流量风暴且时间不可控。RocketMQ 5.0引入静态Topic，通过逻辑队列绑定多个物理队列，扩容时旧队列转为只读，新数据写入新物理队列，读老数据则转发到旧队列，实现分区数不变、无数据迁移的秒级扩容。
CompactTopic与Schema的实用价值
CompactTopic以KV形式维护流状态，定期合并相同Key的消息，只保留最新值，适用于流计算状态存储或最新值队列（如股票价格）。Schema则为消息增加结构化描述，提升类型安全，避免上下游集成不兼容，并通过Schema注册中心（基于CompactTopic存储）和内置序列化机制，减少重复代码，提高研发效率，同时增强与流式SQL的亲和度。
典型场景中的流存储实践要点
日志采集场景中，利用批量索引提升吞吐，引入Schema使数据像流动的表，便于对接FlinkSQL等进行分析。异构数据库同步场景中，按订单ID对Binlog分片，确保同一记录进入同一队列，消费端顺序重放实现同步；流量不足时通过静态Topic扩容，分区数不变，保障数据同步正确性。这些案例展示了流存储在数据集成中的实际用法。
Q&A
RocketMQ 5.0 的主要特点是什么？
RocketMQ 5.0 专注于云原生架构，支持流存储，提供静态主题扩展、高吞吐量和结构化消息的模式，适用于多种业务场景。
流存储与传统消息存储有什么区别？
流存储侧重于数据集成，强调数据分片和有序消费，而传统消息存储主要关注业务消息的低延迟和单条消息处理。
RocketMQ 5.0 如何解决扩容过程中的数据迁移问题？
RocketMQ 5.0 引入静态 Topic 扩容模式，允许在不迁移数据的情况下扩容，确保分区数不变，提升系统稳定性。
流存储的高吞吐量是如何实现的？
通过端到端的批量消息处理，RocketMQ 5.0 在发送和消费阶段都采用批量操作，显著提升消息 TPS。
CompactTopic 在 RocketMQ 5.0 中的作用是什么？
CompactTopic 用于维护流的状态，支持有状态计算，能够节约存储空间并提高读效率。
RocketMQ 5.0 如何提升数据治理能力？
通过引入 Schema 概念，RocketMQ 5.0 提高了类型安全和数据集成的研发效率，确保上下游数据兼容。
