个人中心
文章发布
退出
作者热门文章
- VisualStudio2022插件的安装及使用-编程手把手系列文章
- pprof-在现网场景怎么用
- C#实现的下拉多选框，下拉多选树，多级节点
- 【学习笔记】基础数据结构：猫树
58
4
★消息队列16篇 。
Apache RocketMQ 是一款典型的分布式架构下的消息中间件产品，使用异步通信方式和发布订阅的消息传输模型。 Apache RocketMQ 产品具备异步通信的优势，系统拓扑简单、上下游耦合较弱，主要应用于异步解耦，流量削峰填谷等场景.
说明：以上图片来自官网 。
如上，RocketMQ 中消息的生命周期主要分为消息生产、消息存储、消息消费这三部分:
生产者（Producer）：RocketMQ 中用于产生消息的运行实体，一般集成于业务调用链路的上游.
消费者分组（ConsumerGroup）： Apache RocketMQ 发布订阅模型中定义的独立的消费身份分组，用于统一管理底层运行的多个消费者（Consumer）。同一个消费组的多个消费者必须保持消费逻辑和配置一致，共同分担该消费组订阅的消息，实现消费能力的水平扩展.
消费者（Consumer）： Apache RocketMQ 消费消息的运行实体，一般集成在业务调用链路的下游。消费者必须被指定到某一个消费组中.
订阅关系（Subscription）： Apache RocketMQ 发布订阅模型中消息过滤、重试、消费进度的规则配置。订阅关系以消费组粒度进行管理，消费组通过定义订阅关系控制指定消费组下的消费者如何实现消息过滤、消费重试及消费进度恢复等。 RocketMQ 的订阅关系除过滤表达式之外都是持久化的，即服务端重启或请求断开，订阅关系依然保留.
分布式系统架构思想下，将复杂系统拆分为多个独立的子模块，例如微服务模块。此时就需要考虑子模块间的远程通信，典型的通信模式分为以下两种，一种是同步的RPC远程调用；一种是基于中间件代理的异步通信方式.
同步RPC调用模型下，不同系统之间直接进行调用通信，每个请求直接从调用方发送到被调用方，然后要求被调用方立即返回响应结果给调用方，以确定本次调用结果是否成功.
异步消息通信模式下，各子系统之间无需强耦合直接连接，调用方只需要将请求转化成异步事件（消息）发送给中间代理，发送成功即可认为该异步链路调用完成，中间件会确保任务执行完成。他有如下优势:
主流的消息中间件的传输模型主要为点对点模型和发布订阅模型，RocketMQ也不例外.
在点对点模式下，每个消息只能被一个消费者消费，一旦消息被消费，它就会从队列中删除。这种模式下，消息的生产者和消费者之间没有依赖性，生产者发送消息后，无论是否有消费者接收，都不会影响下一次发送消息。点对点模式适用于需要确保每条消息只被消费一次的场景，例如订单处理、支付确认等.
在发布订阅模式下，每个消息可以被多个消费者消费。消息生产者将消息发布到主题（Topic）上，所有订阅该主题的消费者都能接收到这条消息。这种模式下，生产者不需要关心有多少消费者，只需要发送消息即可。发布订阅模式适用于需要广播消息给多个消费者的场景，例如实时通知、日志收集等.
点对点模式：适用于需要确保每条消息只被消费一次的场景，优点是消息传递可靠，缺点是扩展性较差，不适合大量消费者同时消费的情况。 发布订阅模式：适用于需要广播消息给多个消费者的场景，优点是扩展性好，可以支持大量消费者同时消费，缺点是消息可能会被重复消费，需要额外的机制来处理这种情况.
点对点模式：在订单处理系统中，每个订单的创建、支付等操作可以看作是一个独立的消息，确保每个订单的处理过程不会相互影响。 发布订阅模式：在实时通知系统中，当有新的事件发生时，可以将消息发布到主题上，所有订阅该主题的客户端都能实时接收到通知。 通过了解这两种模式的定义、区别和适用场景，可以更好地选择适合自己需求的消息队列模式.
了解RockectMQ的基本组成、通信方式、消息传输模型 。
最后此篇关于RocketMQ系列2：领域模型和技术概念的文章就讲到这里了,如果你想了解更多关于RocketMQ系列2：领域模型和技术概念的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。
58
4
0
什么是RocketMQ RocketMQ作为一款纯java、分布式、队列模型的开源消息中间件，支持事务消息、顺序消息、批量消息、定时消息、消息回溯等。主要功能是异步解耦和流量削峰：。 常见的MQ主要有
1、说说你们公司线上生产环境用的是什么消息中间件? 见【2、多个mq如何选型？】 2、多个mq如何选型？ MQ 描述 Rabb
消费者从Broker拉取到消息之后，会将消息提交到线程池中进行消费，RocketMQ消息消费是批量进行的，如果一批消息的个数小于预先设置的批量消费大小，直接构建消费请求 ConsumeReques
全局有序 在RocketMQ中，如果使消息全局有序，可以为Topic设置一个消息队列，使用一个生产者单线程发送数据，消费者端也使用单线程进行消费，从而保证消息的全局有序，但是这种方式效率低，一
RocketMQ支持集群部署来保证高可用。它基于主从模式，将节点分为Master、Slave两个角色，集群中可以有多个Master节点，一个Master节点可以有多个Slave节点。Master节点
RocketMQ 4.5版本之前，可以采用主从架构进行集群部署，但是如果master节点挂掉，不能自动在集群中选举出新的Master节点，需要人工介入，在4.5版本之后提供了DLedger模式，使用
RocketMQ是通过 DefaultMQProducer 进行消息发送的，它实现了 MQProducer 接口， MQProducer 接口中定义了消息发送的方法，方法主要分为三大类：
当Broker收到生产者的消息发送请求时，会对请求进行处理，从请求中解析发送的消息数据，接下来以单个消息的接收为例，看一下消息的接收过程。 数据校验 封装消息 首先Broker会创
在上一讲中，介绍了消息的存储，生产者向Broker发送消息之后，数据会写入到CommitLog中，这一讲，就来看一下消费者是如何从Broker拉取消息的。 RocketMQ消息的消费以组为单位
NameServer是一个注册中心，提供服务注册和服务发现的功能。NameServer可以集群部署，集群中每个节点都是对等的关系（没有像ZooKeeper那样在集群中选举出一个Master节点），节
RocketMQ 4.5版本之前，可以采用主从架构进行集群部署，但是如果master节点挂掉，不能自动在集群中选举出新的Master节点，需要人工介入，在4.5版本之后提供了DLedger模式，使用
消息存储 在 【RocketMQ】消息的存储 一文中提到，Broker收到消息后会调用 CommitLog 的asyncPutMessage方法写入消息，在DLedger模式下使用的是
RocketMQ在集群模式下，同一个消费组内，一个消息队列同一时间只能分配给组内的某一个消费者，也就是一条消息只能被组内的一个消费者进行消费，为了合理的对消息队列进行分配，于是就有了负载均衡.
RocketMQ有两种获取消息的方式，分别为推模式和拉模式。 推模式 推模式在 【RocketMQ】消息的拉取 一文中已经讲过，虽然从名字上看起来是消息到达Broker后推送给消费者
主从同步的实现逻辑主要在 HAService 中，在 DefaultMessageStore 的构造函数中，对 HAService 进行了实例化，并在start方法中，启动了 HAService :
在 【RocketMQ】消息的拉取 一文中可知，消费者在启动的时候，会创建消息拉取API对象 PullAPIWrapper ，调用pullKernelImpl方法向Broker发送拉取消息的
全局有序 在RocketMQ中，如果使消息全局有序，可以为Topic设置一个消息队列，使用一个生产者单线程发送数据，消费者端也使用单线程进行消费，从而保证消息的全局有序，但是这种方式效率低，一
概述 RocketMQ 支持发送延迟消息，但不支持任意时间的延迟消息的设置，仅支持内置预设值的延迟时间间隔的延迟消息； 预设值的延迟时间间隔为： 1s、 5s、 10s、 30s、 1m
RocketMQ 支持定时消息，但是不支持任意时间精度，仅支持特定的 level，例如定时 5s， 10s， 1m 等。 其中，level=0 级表示不延时，level=1 表示 1 级延时，le
我尝试给 rockerMQ broker 加注星标，但我收到了错误消息: There is insufficient memory for the Java Runtime Environment t
我是一名优秀的程序员,十分优秀！