Rocket MQ队列学习笔记

https://www.bilibili.com/video/BV1L4411y7mn?p=24

1.如何保证高可用

2.消息丢失怎么办,重复消费问题,消息顺序如何保证

3.消息一致性,A成功传给BCD D挂了,如何一致

 

1.基本消息例子

默认是负载均衡模式,还有一个广播模式

P24.张三:创建订单,扣减库存,付款订单,完成订单

Broker默认会把消息依次放入多个队列

消费者多线程的同时消费多个消息

2. 保证消息顺序

1.保证消息选举顺序

2.局部消息顺序

只要保证张三的消息顺序即可

把张三的消息丢在一个队列里,一个线程处理一个队列的模式

发送的时候增加一个顺序标记MessageQueue 消息队列选择器

producer.send(msg,new MessageQueueSelector(){

},orderID);

消费的时候掉用顺序标记MessageListenerOrderly

3 延迟消息

发送的时候,设置延迟时间setDelayTimeLevel(2),消费者就要延迟消费

2表示级别 对应5ms 最高1ms到2小时 18个级别

4 批量消息

不能超过4M,超过需要分割

5 消息过滤

  1. 根据tag
  2. 用SQL,消息设置一个property不同的属性,sql查询

6 事务消息

消息发送带有事务,生产者发送后要进行提交,消费者才能进行消费 这类消息要half 消息

1)事务消息发送及提交

  • 发送消息(half消息)
  • 服务端响应消息,写入结果
  • 根据发送结果执行本地事务,如果写失败half消息对业务不可见
  • 根据本地事务状态执行commit 或者Rollback

2)事务补偿

  • 没有Commit/Rollback的消息,服务器发起回查
  • 生产者收到回查消息,检查消息本地事务状态
  • 根本本地事务状态,重新Commit或者Rollback

补偿机制用来解决消息Commit或者Rollback发生超时或者失败的情况

事务消息三个状态,提交,回滚,中间状态unknown

P38 MQ在下单的使用

下单,库存扣减,优惠券,用户积分,成功是用PRC顺序掉用,如果失败发送失败消息给MQ,直接反馈失败消息给客户。库存,优惠券和用户模块监听MQ进行回滚

MQ在支付回调的使用

第三方支付后返回成功给系统,系统要做的事情1.修改订单 2.记录支付日志,3.修改客户积分。 直接把成功消息发给MQ,另外三个服务器监听MQ 异步处理

######华丽的分割线######

P89开始讲解高级功能,如何存储消息,如何高可用,注册复制

P91 写性能 Rocket MQ 用顺序写文件方式,写入速度很快

消息发送 读性能:普通读过程

磁盘数据–内核态内存–用户态内存–网络驱动内核内存–网卡 > 用户

四步,零拷贝 采用了Java的MappedByteBuffer ,省略了用户态内存哪一步

一次只能映射1.5G到2G,所以CommitLog大小为1G的原因

1. 1 消息的存储结构

1.CommitLog 2.ConsumerQueue 存储消息索引 3. IndexFile 提供Key或者时间查找的方式

刷盘机制

1.安全性:同步刷盘 Producer – Java Heap – Memory -Disk Flush到Disk才返回成功

2.高性能:异步刷盘 不用Flush到Disk就相应成功

1.2 . 高可用机制

NameServer 用集群搭建

1.Consumer 会默认从Master读,Master繁忙,自动切换到Slave去读

2.Broker双主双从保证写入高可用 发送的时候指到不用的Broker,这样有一个主节点挂了,可以发给另外的主节点

Consumer集群

Producer集群

主从复制

1.同步复制 2.异步复制

配置文件里主节点分同步和异步,从节点配成Slave

建议刷盘:配制成异步(保证吞吐量),主从复制用同步复制(最小保证数据不丢失)

1.3 负载均衡

1.Producer 负载均衡

通过Topic 路由发送轮询消息给不同的Broker Queue,且会分发给不同的Boker

  1. 消费者

    1.集群模式 a.顺序领取任务,b.平均分摊每一条queue,环状轮流分queue的形式给多个消费者(消费者数量不要大于queue的数量)

    2.广播模式

    没有负载,每个消费者都消费每一条消息

1.4 消息重试

1.顺序消息重试

前面没有消费完,如果失败了发生阻塞,后面不能消费消息,要关注消息前面是否失败,及时处理

2.无序消息重试

无序消息(普通,定时,延时,事务消息)失败后,通过返回状态达到消息重试的目的。无序只对集群,广播不能重试

1)次数最多16次,每次重试时间不同 逐渐递增 1 10秒 2.30秒

最长为4小时46分钟16次重试后,不再投递,这个消息就进入死信队列

三种返回触发消息重试

  1. 如果返回了Action.ReconsumeLater 消息将重试
  1. null 重试
  1. 异常,重试

失败后,不想重试,java代码,直接return Action.commitMessage;

重试次数,可以手工设置,超过16次,每次都是2小时,最大次数20次

一个GroupID 下设置,那么所有消费者都生效这个 重试设置

最后启动的实例会覆盖前面的设置。重试都失败,进入死信队列

1.5 死信队列

特征1.不能再被消费

特征2.有死信消息3天,3天后自动删除

特点:

1.一个队列对应一个GroupID,而不是某个消费者实例

2.一个GROUPID没有死消息,不创建死信队列

3.一个队列包含了GroupID对应所有的死信消息,不论属于哪个Topic

处理

1.选择RokctMQ重新发送

2.专门对死信队列的操作,去操作这些死信

1.6 消费幂等性

一条消息不管消费多少次,结果一致

重复消息

  1. 发送时重复发送

    网络原因,生产者没有收到应答,重复发送

  2. 投递时消息重复

    消费后,网络闪断,没有给MQ正确的响应,重复投递

  3. 负载均衡模式消息重复

    某个MQ的Broker发生down机,或者重启,扩容,重新负载均衡,不同的消费者消费了相同的消息

手段1. Message ID。不建议,MQ会产生重复messageID

手段2.用业务唯一标识,消息业务key message.setKey("order10001");

处理过的消息,存起来(问题不同的JVM如何保证?有个方案是利用redis集群)

 


This entry was posted in 高并发与大数据 and tagged , , , . Bookmark the permalink.
月小升QQ 2651044202, 技术交流QQ群 178491360
首发地址:月小升博客https://java-er.com/blog/rocket-mq-note/
无特殊说明,文章均为月小升原创,欢迎转载,转载请注明本文地址,谢谢
您的评论是我写作的动力.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

*