RocketMQ 的设计理念
以下简要介绍下 RocketMQ 的设计理念:
- 消息存储:消息存储是RocketMQ中最为复杂和最为重要的一部分。主要分为三个部分:消息存储整体架构、页缓存与内存映射、消息刷盘
- 通信机制:为了实现客户端与服务器之间高效的数据请求与接收,RocketMQ消息队列自定义了通信协议并在Netty的基础之上扩展了通信模块
- 消息过滤:RocketMQ分布式消息队列的消息过滤方式有别于其它MQ中间件,是在Consumer端订阅消息时再做消息过滤的
- 负载均衡:RocketMQ中的负载均衡都在Client端完成,具体来说的话,主要可以分为Producer端发送消息时候的负载均衡和Consumer端订阅消息的负载均衡。
- 事务消息:Apache RocketMQ在4.3.0版中已经支持分布式事务消息,这里RocketMQ采用了2PC的思想来实现了提交事务消息,同时增加一个补偿逻辑来处理二阶段超时或者失败的消息
【参考资料】若想更加详细地了解,请移步:
相关推荐
rocketmq-4.9.0.zip
rocketmq-4.9.0.zip
RocketMQ NameServer 背后的设计理念
Nameserver 在 RocketMQ 整体架构中所处的位置就相当于 ZooKeeper、Dubbo 服务化架构体系中的位置,即充当“注册中心”,在 RocketMQ 中路由信息主要是指主题(Topic)的队列信息,即一个 Topic 的队列分布在哪些 Broker 中。 Nameserver 工作机制 Topic 的注册与发现主要的参与者:Nameserver、Producer、Consu...
RocketMQ之去重操作
本文来自于liangzl,文章主要讨论了RocketMQ本身是否提供某些关键信息可以帮助我们去重,和业务上如何支持幂等。之前聊过一个问题,RocketMQ的设计上,是不考虑消息去重的问题,即不考虑消息是否会重复的消费的问题,而是将这个问题抛给业务端自己去处理幂等的问题。作为RocketMQ的使用者,现在去讨论RocketMQ为何不支持消息去重的问题,己经是无关痛痒,并且也意义不大。如果站在如何设计一个消息队列的角度去思考这个问题,这是设计上舍与得,无关对错。而现在要考虑的是,既然它不支持消息去重,那么就只能自己通过某些方式去保证消息去重。RocketMQ本身是否提供某些关键信息可以帮助我们去重
RocketMQ相关资料
包含RocketMQ_userguide、RocketMQ_experience、Rocket_MQ_design
你应该知道的RocketMQ
RocketMQ前身叫做MetaQ,在MeataQ发布3.0版本的时候改名为RocketMQ,其本质上的设计思路和Kafka类似,但是和Kafka不同的是其使用Java进行开发,由于在国内的Java受众群体远远多于Scala,所以RocketMQ是很多以Java语言为主的公司的首选。同样的RocketMQ和Kafka都是Apache基金会中的顶级项目,他们社区的活跃度都非常高,项目更新迭代也非常快。 直接定义好一个producer,创建好Message,调用send方法即可。 对于RocketMQ先抛出几个问题: RocketMQ的topic和队列是什么样的,和Kafka的分区有


