消息中间件有两种模型，一种是队列模型，一种是主题模型（也叫发布订阅模型）
这些都只是提出的标准，实现各有不同
队列模型的实现都是一样的，区别就在与主题模型
RabbitMQ的主题模型的实现通过Exchange（topic）来实现，而RocketMQ则通过队列实现
模型如下
Topic：代表一类消息，比如订单消息，物流消息等等
主题中含有很多队列，而一个队列只能被一个消费者消费，如果其中一个消费者挂掉，同组其他的消费者会接替来消费这份消息，所以一般控制同组消费者个数与队列个数相同
所以总结来说，RocketMQ 通过使用在一个 Topic 中配置多个队列并且每个队列维护每个消费者组的消费位置 实现了 主题模式 / 发布订阅模式 。
以上就是RocketMQ的消息模型
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：消费者，也支持分布式部署
官方架构图：
Broker做了集群，并对集群做了主从部署
master/slave部署，slave定期从master同步数据
NameServer做了集群（去中心化）
单个Broker和所有的NameServer连接，并且实现了心跳机制（Broker每隔30s向NameServer发送心跳）
生产者向Broker发送消息的时候，先从NameServer获取Broker（至于哪个Broker，则是由每个消息队列的负载影响，以达到负载均衡的目的）
最后，当Broker收到消息后，会自动发送pull请求来获取消息数据，Consumer可以以两种方式启动：集群和广播
集群即是消息队列模式，而广播则是主题模式
由上面我们知道，RocketMQ的主题是无序的，只有在队列层面是有序的
排序的两个基本概念：
普通排序：消费者通过同一个消息队列收到的消息是有序的（推荐） 原因：消息队列可以容忍短暂的乱序
严格排序：消费者收到的所有消息都是有序的（不推荐） 原因：如果broker集群里面只要有一台机器不可用，整个集群都不可用
Topic与Queue的理解
要这样理解：Consumer1~Consumer3都具有消费【创建，支付，发货】消息的功能（即属于Topic主题下）
此时属于此Topic的Producer可以将产出的消息随便放入该Topic的任意Queue中（达到负载均衡），但是因为他们不再一个Queue中，而绝大多数的消息中间件只实现了普通排序，无法保证订单的创建、支付、发货顺序执行，即无法顺序消费
解决办法：
那么，怎么解决呢？
其实很简单，我们需要处理的仅仅是将同一语义下的消息放入同一个队列 (比如这里是同一个订单)，那我们就可以使用 Hash 取模法 来保证同一个订单在同一个队列中就行了。
重复消费,分布式事务,消息堆积问题,回溯消费,RocketMQ 的刷盘机制,同步复制和异步复制,存储机制
————————————————
版权声明：本文为CSDN博主「Lucky Curve。」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/LuckyCurve/article/details/104534143