这个需求，做不了

使用消息过滤的方式，即可在 MQ 服务端进行消息的过滤，将消息投递给特定的消费者，使每个消费者只需关注与自身相关的消息进行消费。tag 标签过滤方式为，生产者发送消息时为消息设置一个 Tag 标签，消费者在消费时匹配该 Tag ，如果匹配则消费发送给该消费者，如果不匹配则不发送。注2：对于某个资源（比如：topic），如果有其对应的权限配置，则使用配置的权限，如果没有配置则使用默认的权限。注意：IP 白名单如果通过，则不会验证签名，如果你要使用签名方式认证，最好就不要设置对应的 IP 白名单。

RocketMQ 消息重试分为发送重试（生产者）和消费重试（消费者）

在消费过程中，前面的消息M1、M2被消费者Consumer A1处理时，只要消费状态没有提交，消费者A2是无法并行消费后续的M3、M4消息的，必须等前面的消息提交消费状态后才能消费后面的消息。消费者获取某条消息后，服务端会将该消息加锁，保证这条消息对其他消费者不可见，直到该消息消费成功或消费超时，因此，即使多个消费者同时消费同一队列的消息，服务端也可保证消息不会被多个消费者重复消费。使用此命令，我们可以添加消费者分组，并且可以设置分组相关信息，比如-o 顺序消费，-r 最大重试次数等。

在断网或者是生产者应用重启的特殊情况下，若服务端未收到发送者提交的二次确认结果，或服务端收到的二次确认结果为Unknown未知状态，经过固定时间后，服务端将对消息生产者即生产者集群中任一生产者实例发起消息回查。此图我们还是按照用户订单支付操作的例子来说明，订单支付操作是订单系统的操作，其对应一个本地事务（branch 2），其余下游系统都是在这个支付事务之后需要执行的事务（branch 2.1、branch 2.2、branch 2.3）。我们的消费者代码和普通消息的消费者是一样的，无需特殊的处理。

MessageQueueSelector 意为队列选择器，Remoting 协议客户端中没有 消息组的概念，所以需要我们手动的为消息进行分组（将需要严格顺序的消息放在同一个队列），这个接口就是完成此任务的，而且分组的逻辑需要我们自己实现。RocketMQ 顺序消息的顺序关系通过消息组（MessageGroup）判定和识别，发送顺序消息时需要为每条消息设置归属的消息组，相同消息组的多条消息之间遵循先进先出的顺序关系，不同消息组、无消息组的消息之间不涉及顺序性。要保证生产的顺序，需要满足以下条件。

Remoting 协议客户端关于延时消息与gRPC协议客户端有不一样的地方，gRPC客户端只允许设置24小时内的延时（推荐使用方式），Remoting 协议客户端关于延时消息的设置更多，但是真不建议设置过长的延时时长，这样可以有效的避免消息的堆积。如果真的需要设置5天或者10天的延时消息，可以使用定时任务扫描 + 发送延时消息的方式来实现细粒度的延时任务，比如：2023-10-1 9:00 下单，在10 天后，2023-10-11 9:00 时需要撤销订单。延时消息：消息在特点的时间之后触发消费。

因此，大部分场景下，单一进程内同一个消费分组只需要初始化唯一的一个消费者即可，开发过程中应避免以相同的配置初始化多个消费者。普通消息一般应用于微服务解耦、事件驱动、数据集成等场景，这些场景大多数要求数据传输通道具有可靠传输的能力，且对消息的处理时机、处理顺序没有特别要求。对于生产者的创建和初始化，建议遵循够用即可、最大化复用原则，如果有需要发送消息到多个主题的场景，无需为每个主题都创建一个生产者。主题的类型与消息的类型要对应，所以普通消息的主题类型为 Normal。

Topic 是 RocketMQ 中消息传输和存储的顶层容器，用于表示同一类业务逻辑的消息。比如：我们将通知类消息和业务类消息进行隔离，就可以使用不同的主题。也可以通过主题的分隔来做身份识别和鉴权等。RocketMQ 5.x 版本开始，不建议使用自动添加主题，主题作为 RocketMQ 的顶层容器，需要严格合理的创建与管理，而且主题的创建与管理会占用一定的系统资源，所以特别是在生产环境下增删改查都不要随意进行。

Apache RocketMQ 自诞生以来，因其架构简单、业务功能丰富、具备极强可扩展性等特点被众多企业开发者以及云厂商广泛采用。历经阿里十余年的大规模场景打磨，RocketMQ 已经成为业内共识的金融级可靠业务消息首选方案，被广泛应用于互联网、大数据、移动互联网、物联网等领域的业务场景。