RocketMQ架构及特性

架构

  1. RocketMQ包含四个组件NameServer, Broker, Consumer, Producer

  2. NameServer类似注册中心, Broker接收存储消息, Consumer和Producer在项目内定义

  3. Broker向所有NameServer注册自己, 持续发送心跳包

  4. Consumer和Producer向NameServer保持长连接, 每隔30s向NameServer获取所有Topic的队列情况

  5. Consumer和Producer向NameServer获取Broker的地址, 进行消息收发, 也会与所有关联的Broker保持长连接

  6. 一个Broker内有多个Queue, 一个Queue内会存在多个Topic的消息, 一个Topic也会映射到多个Broker

  7. Queue内存储的并非消息内容, 而是指向CommitLog的索引

  8. 消息在每个Broker内以Queue的形式存储

特性

基于rocketmq-spring-boot-starter

  1. 发送普通消息, 延时消息和顺序消息, 事务消息

  2. 事务消息, Producer先把消息发送到Broker, 此时的消息状态为半消息, 之后Producer再对消息进行二次确认(Commit或Rollback), Consumer才能消费该条消息, Broker会定时扫描长时间没有进行二次确认的消息, 主动向Producer进行消息回查

  3. 普通和延时可以并行消费, 顺序消息按照先入先出的顺序进行消费

  4. 发送失败重试, 失败后重试指定次数

  5. 消费重试按异常类型可以分为异常重试和超时重试

  6. 超时重试: Consumer处理时间过长, 在超时时间内没有返回给Broker消费状态, 那么Broker也会自动重试(通过System.exit(-1)重现类似场景, Thread.sleep()无法复现)

  7. 异常重试, 根据消费者返回的状态判断消费是否成功, 按消息类型可以分为两种重试机制

    • 顺序消息: 失败后默认1秒重试一次, 直到成功; 顺序消息与普通消息可能存放在一个Queue中, 由于顺序消息的消费特性, 当顺序消息被消费时, 会锁住当前Queue, 若该消息消费失败, 则同一Queue内后续的消息会阻塞到该消息消费成功为止, 对应状态枚举为ConsumeOrderlyStatus

    • 普通消息: 失败后有限次数的重试, 重试过程不阻塞Queue, 间隔时间依次递增, 对应状态枚举为ConsumeConcurrentlyStatus

  8. 顺序消息 消息会被发送到同一个broker中, 消费者进行消费时, 会锁住当前队列, 以保证消费顺序

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值