Apache RocketMQ的学习笔记

1,547 阅读4分钟

我正在参与掘金创作者训练营第4期,点击了解活动详情,一起学习吧!

Apache RocketMQ的前身

伴随着SpringCloud Alibaba一套成熟的微服务解决方案的成功, 作为原生的阿里内部支撑了历年双十一大促的消息中间件RocketMQ也基本上替代了选型时的其他消息中间件(Kafka, RabbitMQ, ActiveMQ).

标题中提到变形记, 其实是为了吸引人, 让人有个好奇的想法. 为什么说时变形记呢, 是因为RocketMQ在阿里内部的时候是叫做Metaq, 也就是最早其命名('Metamorphosis')的简写, 是作者为卡夫卡的一篇中篇小说代表作, 也就是为了致敬KafKa.

RocketMQ确实早期也借鉴了很多KafKa优秀的设计. 为了在Java为主流语言的阿里中进行定制化的需求, ali将之前的一款名为Notify的消息中间件进行了开发研究, 形成了RocketMQ.

2016年开源贡献给了Apache基金会, 为开源做出了其贡献. 也奠定了现在RocketMQ的地位.

Apache RocketMQ是一个分布式消息和

Apache RocketMQ的架构和细节

image.png 从RocketMQ官网的架构图中可以看出来:

  • 生产者(Producer): 生产消息的角色, 支持分布式集群部署. 至于消息通过哪个Broker队列来投递, 无需关心, 是RocketMQ自行进行负载均衡.

  • 消费者(Consumer): 消费消息的角色, 支持分布式集群部署. 支持以Push和Pull两种模式来进行消费(本质都是用拉取方式, push也是长轮询的方式来获取到然后进入监听里边, 达到Push的效果), 支持集群(CLUSTERING)和广播(BROADCASTING)两种方式消费.

  • 注册中心(NameServer): 一个简单使用的Topic Router注册中心, RocketMQ自行实现注册中心, 使得可以不依赖任何注册中心, 定制化更容易维护和升级扩展. 主要用于Broker管理和路由信息管理. 虽然集群部署, 但是各自为政, 由Broker向每一个NameServer进行注册.

    • Broker管理 当Broker配置NameServer地址然后启动, 将Broker集群的注册信息注册至NameServer中并保存起来, 然后使用Ping|Pong心跳机制来检查Broker的可用状态;
    • 路由信息管理 在Broker注册到NameServer中时, 也会将Broker中的整个路由信息以及队列信息存储, 用于Producer和Consumser来获取.

image.png

  • 掮客服务(BrokerServer): 主要负责消息的存储, 投递和查询. 而且建议分布式集群部署, 也做了很多设计以高可用为准则:

    • 远程模块(Remoting Module): 用于负责接受Clients请求处理;
    • 客户端管理(Client Manager): 负责管理生产和消费客户端的, 以及维护所有的Topic信息;
    • 存储服务(Store Service): 处理消息异步或同步存储到物理硬盘以及从硬盘查询;
    • 高可用服务(HA Service): High Available. 保证Master和Slaver之间数据同步, 使得如果Master不可用时, 切换到slaver也ok.
    • 索引服务(Index Service): 根据特定的MessageKey进行将消息索引, 提供更好的查询; 所以在发送消息的时, 建议每个消息尽量要设置唯一的标识码, 可以方便定位.

// 订单Id String orderId = "20034568923546"; message.setKeys(orderId);

若干小知识点

RocketMQ的持久化权衡

数据库 vs 文件存储?

选择文件存储. 目前的高性能磁盘,顺序写速度可以达到600MB/s, 超过了一般网卡的传输速度;

顺序写 vs 随机写?

为了能够保持高性能, rocketMQ使用的时顺序写的机制, 保证了连续性, 提高性能, 在硬盘存储机制上降低对于吞吐量的制约.

RocketMQ是否限制一次消费

rocketMQ 为了追求高性能,高吞吐量, 选择了简单的方式来实现, 让消费者自行来保证幂等性, 绝对保证消费一次.

RocketMQ广播模式和集群模式如何配置

广播模式和集群模式是在消费消费者Group的方式来区分, 然后在消费者端来的. 与RabbitMQ的生产者端来配置完全相反, 也是一种很好的设计

RocketMQ的事务消息和延迟消息有什么相同点

这是个小的知识点,也是RocketMQ中一个管用的有意思的设计:

事务消息在发送half Message时为了不被消费者消费,以及延迟消息在延迟时间内时,都是在其他另外的topic中,只有满足条件了,再切回到该到的topic被消费者消费。

看似复杂的事情总能找到一种简单方便的设计而实现,只是缺乏发现。