作用

• 流量削峰
• 系统解耦

功能

• 普通消息
  • 同步消息
  • 异步消息
• 事务消息
• 顺序消息
• 延迟消息
• 订阅与发布
• 消息过滤
• 消息消费重试
• 死信队列
• ......

架构设计

• 1个broker是1台实例
• 每个broker都有从节点，便于做故障转移
• 每个broker对应一个文件，存储数据？还是会根据topic分开放置？
• 每个broker都有topic对应的queue（topic是虚拟的，代表一组queue，消息到达后会根据规则存储到某个broker的queue中）
• broker模型设计的优点：
  • 数据均匀分布
  • 同一个group多个消费者连接不同的broker的queue，能消费同一个topic下的数据，提高了消费端的能力
•  nameServer 相当于eureka,nacos,zookeeper 做注册中心
• nameServer多节点部署提高可用性

重要属性介绍

topic

        逻辑上消息存储的位置，一个topic表示一组queue。topic对外概念

queue

        实际上消息存储的位置。queue是为了提高性，做的存储设计

        优点：容灾，防止数据倾斜

tag

        消息过滤使用，比如同一个topic下的消息，在同一个queue队列中，有订单类型、商品类型2种消息，依据tag区分，mq推送前会根据consumer订阅的tag过滤

      优点：避免了无效的数据传输（如：订单consumer不用接收同一个queue种的商品消息）

  ps：阿里云rocketMQ会根据topic数量收费（4.0版本），所以可能会有2种业务共用topic情景

group

        应用所属的组，同一组应用，消息只会发送到一个应用

        消费消息时，同一组应用，同一个queue，只会有1个消费者连接（保证消息不会发送到同组下的多个消费者）

问题

为什么不设计成1个broker，1个从节点，然后通过故障转移做高可用？

  1. 1个broker发生问题产生的影响更大（3台broker坏1个，相当于只坏了1/3）

  2. 1个broker节点负载能力是一个问题

  3. 如果没有queue，数据根据topic值，通过hash存到同一个broker，会导致数据倾斜

与kafka的对比

	rocketMQ	kafka
高可用	支持10w/s	100w/s
可用性	product支持同步消息+异步消息	异步消息	rocketMQ更加可靠
扩展性	支持5W级的queue（一个topic在一个broker就有1个queue）	queue到达64后，性能下降
功能全面性	支持普通消息、顺序消息、事务消息、延迟消息等	仅支持普通消息 支持幂等性过滤重复消息
适用场景	业务	日志