RocketMQ 总体概括

概述

官网地址

RocketMQ 领域模型

官方领域模型概述

下面图，是在自己理解的基础上，对官方的模型图添加了一些。

• Topic：主题，可以理解为类别、分类的概念。
• MessageQueue：消息队列，存储数据的一个容器(队列索引数据)，默认每个 Topic下有4个队列被分配出来存储消息。
• Message：消息，真正携带信息的载体概念。
• Producer：生产者，负责发送消息。
• Consumer：消费者，负责消费消息。
• ConsumerGroup：众多消费都构成的整体或构成的集群，称之为消费者组。
• Subscription：订阅关系，消费者得知道自己需要消费哪个 Topic 下的哪个队列的数。

MQ 解决的问题

对于 MQ 解决的问题做总结。

• 异步：侧重的处理流程，流程上将以前的一些同步逻辑，改造成为异步的逻辑流程。
• 解耦：侧重功能设计，在做一些业务架构分析的时候，可以有力度有重点的区分主干流程、分支流程。
• 削峰限流：侧重在数量级的问题，相比于未接入 MQ 时能再次抗上几倍甚至几十倍的流量。
• 延迟调用(准实时、一定延时)：侧重定制化诉求，在 db 与 MQ 之间做一个抉择(用户下单，半小时未支付则自动取消订单，不是定时任务，而是触发，精确操作)。

电商平台案例

初步设计

通过电商平台用户注册送积分、送优惠券这个场景来理解异步解耦合。如果不使用消息中间件，电商平台送积分的实现也许是下图这个样子：

• 用户在网站前端注册页面填写相关信息，然后调用账号中心服务，注册账号。
• 账户中心首先执行用户注册逻辑处理（例如判断用户是否已注册、是否符合注册条件等），然后写入到数据库。
• 注册成功后，需要调用积分中心（赠送积分接口）给用户送积分。
• 送完积分后，再调用优惠券相关接口，为用户赠送优惠券。
• 成功送完积分、优惠券后，向用户返回“注册成功”。

由上图可知，这个 设计 有一个比较严重的问题，那就是可扩展性低。
如，如果调整活动策略，在发送积分的同时，还需要发送额外的大礼包，就不得不修改用户注册流程，并重新部署用户注册模块。

从功能来看，需求的变更集中在活动相关的内容。用户注册本身的逻辑并未发生变化，但由于用户注册逻辑与活动模块存在耦合，两个模块必须一起调整和发布。

另外，调用积分、优惠两个功能，也会增加用户注册流程时间变长，在高并发场景下，用户注册易变成系统瓶颈。

引入中间件设计

将注册逻辑与积分、优惠业务分离，这样，注册逻辑就不会因为积分、优惠业务的变化，而修改，即使添加了新的大礼包，优惠、积分的业务，后续也不再变化，做到了真正对新增开放，对修改关闭。

MQ 选型

一般从业务出发，选择合适的 MQ ，如果是从普适性出发，可根据功能、单机吞吐、水平扩展上进行选择，还可以根据公司或团队的技术栈来选择 MQ ，如果公司语言以 Erlang ，那可以选择 RabbitMQ ，性能可以通过更多的集群来解决。如果是以 Java 为主，建议使用 Kafka，或者 RocketMQ。两者都是性能优秀的中间件，在这两者之间选择时，可以更多关注功能特性。

特别是 RocketMQ 提供了消息重试、消息过滤、消息轨迹、消息检索等功能特性，特别是 RocketMQ 的消息检索功能，因此很适合核心业务场景。而 Kafka 更加擅长于日志、大数据计算、流式计算等场景。

如下是常见的 MQ 做的相关对比。

维度	对比项	Kafka	RocketMQ	RabbitMQ
功能维度	延迟消息	不支持	支持	支持
功能维度	优先级队列	不支持	不支持	支持
功能维度	事务消息	支持	支持	支持
功能维度	消息重试	不支持	支持	不支持
功能维度	消息堆积能力	强	强	弱(性能会受影响)
功能维度	消息回溯	支持	支持	不支持
功能维度	消息过滤	不支持	支持	不支持
功能维度	消息轨迹	不支持	支持	支持(需要插件)
功能维度	多语言	支持多语言客户端	支持多语言客户端	支持多语言客户端
功能维度	ACL	支持	支持	支持
性能维度	单机吞吐量	百万级	十万级	万级
性能维度	消息发送时延	ms级	us级	us级
性能维度	水平伸缩能力	支持(伴随大量数据复制)	支持(轻量级)	支持
其它维度	技术栈	Java/Scala	Java	Erlang

结束

RocketMQ 总体概括至引结束，如有疑问，欢迎评论区留言。