RocketMQ的设计理念
- 追求简单和性能第一
功能特点
- 支持并且仅支持Topic路由模式
- 支持集群消费/广播消费两种消费模式
- Broker端和Consumer端消息过滤
- Broker消息过期机制，默认保留3天
- Broker存储空间报警
- 按时间节点回溯消息
- 定时消息
- 消息重试机制
性能特点
- Broker Crash、OS Crash、机器断电、磁盘损坏分情况高可用
- 确保消息必须被消费一次
- 消息顺序到达
架构图
架构特点
- 每个Broker和NameServer 集群中的所有节点建立长链接，定时注册Topic信息到到所有NameServer
- Producer和NameServer集群中的某一个节点（随机选择）建立长连接，定期从NameServer 获取Topic 路由信息，并向提供Topic服务的Master建立长连接，且定时向Master发送心跳，Producer完全无状态，可以集群部署
- Consumer与NameServer集群中的其中一个节点(随机选择)建立长连接，定期从NameServer获取Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向Master、Slave 収送心跳。Consumer 既可以从 Master 订阅消息，也可以从 Slave 订阅消息，订阅规则由 Broker 配置决定。
ActiveMQ、Kafka、RocketMQ、RabbitMQ比较
从图中不难看出
- RocketMQ在单机吞吐量和集群高可用以及可靠性方面有很大的优势
- RocketMQ在时效性方面差一些
- RocketMQ基于java开发，便于二次开发
消息队列技术选型建议
- Kafka主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，适合产生大量数据的互联网服务的数据收集业务。
- RocketMQ天生为金融互联网领域而生，对于可靠性要求很高的场景，尤其是电商里面的订单扣款，以及业务削峰的情况，
- RabbitMQ 结合erlang语言本身的并发优势，性能较好，社区活跃度也比较高，但是不利于做二次开发和维护。不过，RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug，如果你的数据量没有那么大，小公司优先选择功能比较完备的RabbitMQ