RocketMQ 其他特性

一、延时 / 定时消息实现

延迟消息（Scheduled Message）是指生产者发送的消息不会立即被消费者消费，而是延迟一定时间后才可被消费。

RocketMQ 延迟消息通过延迟级别 + 定时投递实现：

1️⃣ Producer 发送延迟消息时指定 DelayLevel，消息写入 CommitLog 并标记延迟级别

2️⃣ Broker 的定时调度线程扫描延迟消息，检查延迟时间是否到达

3️⃣ 延迟时间到达后，将消息投递到普通队列，Consumer 可正常消费

延迟消息本质上还是普通消息，只是消费可见性被延迟。RocketMQ 并没有单独的延迟队列，而是通过定时任务 + 队列偏移控制实现延迟投递。

二、过滤消息实现

支持 Tag过滤（服务器端）和 SQL92表达式过滤消息属性，消息发送时可设置属性，消费者订阅时使用 Tag 或 SQL 表达式。Broker 优先做服务器端过滤，消费端可做二次过滤。

三、为什么不使用 Kafka？

性能与适用场景

Kafka在数据吞吐上是远超rocketmq的，但是它的topic很多的情况下，性能又远低于rocketmq。基于这种情况kafka多用于处理海量的日志，历史数据等体量庞大的数据集合体，这样在个体数据庞大的情况下使用的topic点更少；rocketmq有着更加严谨的检查和规则，所以它更适合分散式的短消息和小数据，这也得于它的topic算法和规划，即使有成千上万个topic点，性能下降并不多。

功能对比

从功能上来说，Kafka 不支持广播、延时、事务、消息轨迹，以及顺序消息时，如果一台 Broker 宕机后，会产生消息乱序，不支持基于 Broker 的 Tag 消息过滤，网上说当 Kafka 分区多的时候，性能会下降。

语言与开发

从语言上来说，Kafka 使用 Java 和 Scala，针对一些框架原理查看以及二开不便利。

使用场景

从使用场景 Kafka 更侧重于通过流处理引擎实现实时数据流处理，在大数据流处理和实时数据分析方面使用较多。RocketMQ 的设计更注重实现高可用和多功能的消息服务，在国内较多公司应用较为广泛。

综合比对

综合比对，Kafka 的优势在于性能高，而 RocketMQ 的功能和业务场景更贴合国内公司，所以使用也较多。

Kafka： 优势在于极高性能和吞吐量，适合大数据、日志、流式处理场景；劣势是功能相对单一，多 Topic 性能下降明显。

RocketMQ： 优势在于功能丰富、支持顺序、延迟、事务和消息过滤，适合国内业务场景、短消息、小数据、高 Topic 高并发场景。