RocketMQ概述
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