RocketMQ学习总结

1、吞吐量:kafka>rocketmq>rabbitmq;消息堆积:kafka>rocketmq>rabbitmq;

2、rocketmq天然支持集群配置,默认conf配置下有两主两从异步、两主两从同步、两主没有从

3、为了保证正确运行,最好给出4g内存

4、先启动namesrv再启动broker,rocketmq控制台官方没有给,但是有开源爱好者研发rocketmq控制台的图形化管理界面,可以下载下来用idea运行即可查看,或者打成包运行也行。地址:https://github.com/apache/rocketmq-externals

5、Name Server相当于一个注册中心,记录生产者、消费者、broker集群的信息。所以要先启动Name Server

6、Producer发送消息,会默认发送到4个队列中并存储,队列是有序的。

7、针对事务消息的应答状态(LocalTransactionState):COMMIT_MESSAGE、ROLLBACK_MESSAGE、UNKNOW(未知状态,一般用于处理超时等现象);针对消费方消费的应答状态(ConsumerConcurrentlyState):CONSUME_SUCCESS(消费成功)、RECONSUME_LATER(消息重试,消费失败以后重试机制)。(4.4以后变了,看完以后自己查查)SUSPEND_CURRENT_QUEUE_A_MOMENT

8、事务消息可以解决分布式事务以实现数据最终一致性,同时通过补偿机制对消费者消费出问题进行补偿。

9、RocketMQ有推拉两种方式,拉取消息是消费者直接从broker拉取,推送并不是broker直接将消息推送给消费者,而是消费者向broker发送请求,然后broker定时扫描其收到的消息,如果发现是消费者需要的,则会主动推送给消费者。

10、顺序消息

顺序消息需要三个阶段去保证:消息按照顺序发送;消息被存储时保证和发送的顺序一致;消息被消费时保证和存储的顺序一致。

RocketMQ能严格保证顺序消息,但这不是全局顺序,只是分区顺序(queue)。

只用一个队列的话可以保证全局顺序。或者同样的消息只发送到某一个队列。

顺序消息有低延迟性,因为要扫描所有的队列。

11、批量发送消息

RocketMQ默认消费模式是集群模式,若要批量消费,则设置成广播模式。

12、消息的存储和发送

消息的存储采用顺序写磁盘,效率比随机写磁盘快6000倍,消息从磁盘读出来发送给消费者,采用的零拷贝技术,不然发送要经过四次复制,效率比较低。零拷贝技术默认单个文件1.5-2G,rocketmq默认单个commitLog是1G。

13、

commitLog存储在rocketmq/store下,其存储的是消息的元数据,大小默认为1G。

为了提高CommitLog的查询效率,因此有了ConsumerQueue,其存储了消费消息的偏移量,可通过偏移量快速在commitLog中查找到消息。

14、如何保证高可用性?

nameServer:nameServer是无状态的,如果新加一个nameServer无需重启整个集群,直接添加就行,等nameServer集群发现该新节点,就会主动将broker集群的信息同步一份信息新节点。

broker集群:依靠主从来保证高可用性。master负责读写,而slave只负责写,不跟生产者交互只跟消费者交互。 

消费者的高可用性:消费者默认是跟master交互的,当master比较繁忙或者不可用时,消费者会自动从slave读取数据,这个不需要我们控制,broker会自动控制。

15、消息消费重试

消息消费失败可以设置重试,但是只适合集群消费,对于广播模式的消费,没有消息的重试,只有一次消费,无论成功失败都不会有消息的重试。RocketMQ默认最多重试16次。

16、死信

消息消费超过重试次数,消息变为死信,进入死信队列,死信队列是针对消费者组来的,一个消费者组对应一个死信队列,如果该消费者组没有产生死信,则没有死信队列。

死信队列中的消息无法再次被消费,死信队列中的数据跟正常消息一样三天之后就会被删除,因此三天之类必须要处理死信消息。

可通过控制面板再次发送死信消息,或者再单独写个消费者消费死信队列。

17、重复消费

可能产生重复消费的情况:

(1)生产者发送消息给broker,broker本地持久化还没反馈,结果生产者宕机或者网络波动,没收到反馈,生产者会再发一条给broker,broker持久化两条,会发给消费者两条;

(2)消费者消费以后还没反馈给broker,然后宕机或者网络波动,broker一段时间以后收不到反馈会重试,导致消费者二次消费;

(3)当消费者实例重启或者宕机,会触发负载均衡重排,已经消费的队列可能会被分配到新消费者,导致不同的消费者消费了相同的消息。

消息消费做幂等:

不能用messageID,RocketMQ不保证消息的messageID唯一,因此可能不同的消息有同一个messageID,因此不能用messageID。可以用业务的唯一标识,发送消息是传过去一个key,这样对这个key进行做幂等。消费者本地可将消费以后的key存入数据库,当每次收到消息以后与数据库对比,若key能查到,则不再消费。

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值