仰望星空，脚踏实地！安全感是自己给的，努力才是一辈子的安全感。

NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。

RocketMQ死信队列

*** @Author : 一叶浮萍归大海* @Description: RocketMQ消息重试机制*/@Slf4j/*** 发送消息*/@Test// 1、创建一个生产者// 2、连接NameServer// 生产者发送消息失败时，默认会重试2次// 3、启动// 4、创建消息Message message = new Message("retry-topic", "这是一个Retry消息".getBytes(StandardCharsets.UTF_8));

在RocketMQ的消息中，如果没有未消息设定Key那么会有一个默认的Key，如下：但是对于一些特殊的场景，例如交易系统，按照orderSn查找是一个和常见的操作，那么这种情况下就涉及到了如何在发送消息的时候，指定消息的Key了。请看下面的案例。

消息的种类纷繁复杂，不同的业务场景需要不同的消息，基于此RocketMQ提供了消息过滤功能，通过Tag或者Key进行区分，本章介绍Tag，我们再往一个Topic里面发送消息的时候，根据业务逻辑可能需要区分，例如带有tagA的消息被A消费，带有TagB的消息被B消费，还有在事务监听的类里面，只要是事务消息都要走同一个监听，这时我们也需要通过过滤才能区别对待。其实这种场景在生活中也很常见，例如大家每天都使用的微信公众号，当关注的博主在公众号发布完消息后，你只会收到自己自己感兴趣的那部分。

批量消息是指RocketMQ可以把一组消息集合一次性发送，这一组消息会被当做一个消息供消费者消费。

顺序消息是一种对消息发送和消费顺序有严格要求的消息。对于一个指定的Topic，消息严格按照先进先出（FIFO）的原则进行消息发布和消费，即先发布的消息先消费，后发布的消息后消费。在 Apache RocketMQ 中支持分区顺序消息，如下图所示。我们可以按照某一个标准对消息进行分区（比如图中的ShardingKey），同一个ShardingKey的消息会被分配到同一个队列中，并按照顺序被消费。需要注意的是 RocketMQ 消息的顺序性分为两部分，生产顺序性和消费顺序性。

延迟消息是指发送者发送完消息后，不希望消息被立即投送给订阅者，等一段时间之后再投递给订阅者，例如生活中我们常见的例子，京东商城购物、12306买火车票...，下完订单后就可以发送一个延迟消息，30分钟后检查该订单的状态，如果用户未付款就取消此订单，释放库存。使用 RocketMQ 的延时消息可以简化定时调度任务的开发逻辑，实现高性能、可扩展、高可靠的定时触发能力。

发送单向消息，适用于发送方不关心或者不在意消息的发送结果，这种方式的吞吐量很大，但是存在消息丢失的风险，对于重要消息要慎用！该种方式通常适用于对消息没有那么严格的场景中，例如日志信息的采集。

异步消息通常应用在对响应时间比较敏感的业务中，即发送端不能容忍长时间的等待Broker的响应，发送完成后会立即有一个异步消息通知。

发送 & 接收同步消息（Java操作RocketMQ）

其实不管消费者是采取Push模式还是Pull模式进行拉取数据，其底层原理是不变的，底层的Push模式也是基于Pull模式的，只不过客户端内部封装了api，一般场景下，上游消息生产量小或者均速的时候，选择Push模式，在特殊场景例如：电商大促，抢优惠券等场景可以选择Pull模式。Pull模式是客户端主动向服务端索取数据，优点是客户端可以依据自己的消费能力进行消费，但是拉取的频率需要由用户自己控制，拉取频繁容易造成服务端和客户端的压力，拉取间隔长又容易造成消费不及时；

编辑 /etc/profile 文件，添加如下内容：备注：此处的localhost根据自己的实际情况进行填写，具体语法为：export NAMESRV_ADDR=[localhost | 阿里云公网IP]:9876。

RocketMQ阿里巴巴旗下一款开源的消息中间件，2016年11月28日，阿里巴巴向Apache软件基金会捐赠RocketMQ，成为Apache孵化项目，2017年9月25日，Apache宣布RocketMQ孵化成为Apache顶级项目（TLP），成为国内首个互联网中间件在Apache上的顶级项目。

一、MQ简介1.1、概述MQ（Message Queue），是一种提供消息队列服务的中间件，也称为消息中间件，是一套提供了消息（消息即数据，一般消息的体量不会很大）生产、存储、消费全过程的API软件系统。1.2、应用场景MQ常用的应用场景主要分为以下三种，即：流量削峰、异步解耦、数据搜集，下面一 一介绍。1.2.1、流量削峰MQ可以将系统的超量请求暂存其中，以便系统后期可以慢慢进行处理，从而避免了请求的丢失或系统被压垮。