最近做项目的过程中很多地方用到了RocketMQ，接下来一起复习RocketMQ领域模型。
首先是RocketMQ的简介。
RocketMQ是一个由阿里巴巴集团开发的分布式消息和流媒体平台。它基于发布-订阅模型，旨在以低延迟和高可靠性处理大量消息。RocketMQ提供了消息排序、消息过滤和消息跟踪等功能，使其适用于实时数据分析、金融交易和电子商务等用例。它是开源的，用Java编写，支持多种编程语言，包括Java、C++、Python和Go。
接着来看一下RocketMQ的相关模型。
首先是整体的RocketMQ模型的介绍。
在图中包含三点：消息生产、消息存储和消息消费。其工作流程为生产者生产消息并传输到Broker，消息通过Broker路由到对应的topic存储起来，消费者通过订阅的方式去消费topic里面的消息。
接着复习一下RocketMQ中相关属性术语：
-
Broker：Broker(代理)是一个服务器，用于接收和存储来自生产者的消息，并将其传递给消费者。每个代理可以处理多个主题和分区。
-
Topic：主题是一个逻辑实体，表示RocketMQ中的消息流。生产者向特定主题发送消息，消费者订阅某个主题以接收消息。
-
Message：消息是由生产者通过代理发送给消费者的数据单元。消息由主题、正文和可选属性（如标记和键）组成。
-
Producer：生产者是一个向代理发送消息的客户端应用程序。生产者可以同步或异步发送消息。
-
Consumer：消费者是一个从代理接收消息的客户端应用程序。消费者可以订阅一个或多个主题，并同步或异步地接收消息。
-
NameServer：NameServer是一个中央注册表服务，用于维护主题和代理之间的映射。生产者和消费者可以查询NameServer以找到处理特定主题的代理。
-
集群：RocketMQ集群是一组协同工作以提供消息服务的代理。集群可以有多个代理来复制消息，以确保高可用性和容错性。
接下来介绍下在RocketMQ中消息传输的两种模型。
-
点对点模型
在点对点模式下，消息生产者将消息发送到一个特定的队列中，而消息消费者从该队列中接收消息。
点对点模式的优点是可以确保消息被传递到唯一的消费者，从而避免了消息的重复消费。同时，点对点模式还可以提高消息的可靠性和稳定性，因为每个消息都只会被一个消费者消费。
但存在一些缺点。
不适合高并发场景：RocketMQ 点对点消息传输采用的是同步阻塞模式，对于高并发场景来说，可能会导致消息传输的延迟和性能下降。 消息传输可靠性有限：RocketMQ 点对点消息传输虽然可以保证消息传输的可靠性，但是在网络不稳定或者出现故障的情况下，仍然可能会出现消息传输失败的情况。 消息传输的实时性不高：RocketMQ 点对点消息传输需要经过多个环节，包括消息发送、路由、存储和消费等，这些环节都需要一定的时间，因此消息传输的实时性不高。 部署和维护成本较高：RocketMQ 点对点消息传输需要进行部署和维护，需要专业的运维人员进行管理，因此成本较高。
-
发布订阅模型
在RocketMQ中，发布者将消息发布到一个主题（Topic）中，订阅者可以通过订阅该主题来接收消息。发布者在发布消息时需要指定主题名称，RocketMQ会将该消息存储到该主题对应的队列中。订阅者可以订阅一个或多个主题，RocketMQ会将该订阅者订阅的主题的消息推送给该订阅者。
RocketMQ支持两种订阅模式：广播模式和集群模式。
在广播模式下，一个消息会被发送到所有订阅该主题的消费者，每个消费者都会独立消费该消息，互不影响。
在集群模式下，一个消息只会被发送到一个消费者进行消费，不同的消费者消费不同的消息。如果某个消费者宕机或者出现故障，RocketMQ会自动将该消费者的任务分配给其他健康的消费者。
发布订阅模式的特点：
消费独立：相比点对点模型的匿名消费方式，发布订阅模型中消费方都会具备身份，一般叫做订阅组（订阅关系），不同订阅组之间相互独立不会相互影响。 一对多通信：基于独立身份的设计，同一个主题内的消息可以被多个订阅组处理，每个订阅组都可以拿到全量消息。
如上介绍RocketMQ的基本概念，整个的工作流程、并且也介绍了两种消息传递模型：点对点模型、发布订阅模型，也介绍了不同消息传递模型的各自特点。
原文始发于微信公众号（CodeJames）：在项目中用到RocketMQ后，再来了解其架构模型
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
文章由极客之音整理，本文链接：https://www.bmabk.com/index.php/post/148220.html
