RocketMQ的模型和基本概念

消息中间件有两种模型，一种是队列模型，一种是主题模型（也叫发布订阅模型）

这些都只是提出的标准，实现各有不同

队列模型的实现都是一样的，区别就在与主题模型

RabbitMQ的主题模型的实现通过Exchange（topic）来实现，而RocketMQ则通过队列实现

模型如下

Topic：代表一类消息，比如订单消息，物流消息等等

主题中含有很多队列，而一个队列只能被一个消费者消费，如果其中一个消费者挂掉，同组其他的消费者会接替来消费这份消息，所以一般控制同组消费者个数与队列个数相同

所以总结来说，RocketMQ 通过使用在一个 Topic 中配置多个队列并且每个队列维护每个消费者组的消费位置 实现了 主题模式 / 发布订阅模式 。

以上就是RocketMQ的消息模型

扫描二维码关注公众号，回复： 9657691 查看本文章

RocketMQ架构

• NameServer：注册中心，类似ZooKeeper和Spring Cloud

里面记载着Broker的注册信息，生产者和消费者都是通过NameServer才能确定Broker（可能多个Broker在做负载均衡）

有解耦的作用（当改变Broker的时候只要修改下NameServer里的信息就可以了）

• Broker：队列服务器，和RabbitMQ的概念一样的

一个 Topic 分布在多个 Broker上，一个 Broker 可以配置多个 Topic ，它们是多对多的关系。

消息队列（物理模型）在Broker上，Topic（抽象模型）利用Broker

相当于Topic是软件，而运行资源就是Broker上的queue，可以多分配一点，也可以少分配

• Producer：生产者，支持分布式部署
• Consumer：消费者，也支持分布式部署

官方架构图：

1. Broker做了集群，并对集群做了主从部署

   master/slave部署，slave定期从master同步数据

2. NameServer做了集群（去中心化）

   单个Broker和所有的NameServer连接，并且实现了心跳机制（Broker每隔30s向NameServer发送心跳）

3. 生产者向Broker发送消息的时候，先从NameServer获取Broker（至于哪个Broker，则是由每个消息队列的负载影响，以达到负载均衡的目的）

4. 最后，当Broker收到消息后，会自动发送pull请求来获取消息数据，Consumer可以以两种方式启动：集群和广播

   集群即是消息队列模式，而广播则是主题模式

由上面我们知道，RocketMQ的主题是无序的，只有在队列层面是有序的

排序的两个基本概念：

1. 普通排序：消费者通过同一个消息队列收到的消息是有序的（推荐） 原因：消息队列可以容忍短暂的乱序
2. 严格排序：消费者收到的所有消息都是有序的（不推荐） 原因：如果broker集群里面只要有一台机器不可用，整个集群都不可用

Topic与Queue的理解

要这样理解：Consumer1~Consumer3都具有消费【创建，支付，发货】消息的功能（即属于Topic主题下）

此时属于此Topic的Producer可以将产出的消息随便放入该Topic的任意Queue中（达到负载均衡），但是因为他们不再一个Queue中，而绝大多数的消息中间件只实现了普通排序，无法保证订单的创建、支付、发货顺序执行，即无法顺序消费

解决办法：

那么，怎么解决呢？

其实很简单，我们需要处理的仅仅是将同一语义下的消息放入同一个队列 (比如这里是同一个订单)，那我们就可以使用 Hash 取模法 来保证同一个订单在同一个队列中就行了。

重复消费,分布式事务,消息堆积问题,回溯消费,RocketMQ 的刷盘机制,同步复制和异步复制,存储机制

请参考文章（说白了就是还没来得及做笔记 :）

https://gitee.com/LuckyCurve/JavaGuide/blob/master/docs/system-design/data-communication/RocketMQ.md