有AB两个消费者他们的groupname不同，然后订阅了同一个topic，A 订阅 tag1，B订阅tag2
B消费者里面像这个topic下面的tag1发送一个消息。
这个重试队列的订阅应该是到A的重试队列下面。然后由A去消费?
消息正常抵达到消费者A，但是由于A异常没有返回success也没用返回重试。导致这条消息最终进入到了B的消费者重试队列里面，也就是Mq的%RETRY%ConsumerB下面，但是由于集群模式订阅的重试队列MQ默认订阅是的tagall。所以导致这个消息会被推送给B 但是由于消息的tag是 tag1，B是没有办法消费的
能否让重试队列订阅的时候消费者自己set 订阅的tag呢？.
实在没有看懂你的描述，B消费者里面像这个topic下面的tag1发送一个消息。B是消费者怎么会发送消息了。
是B在自己的业务处理逻辑里面，用一个生产者的方法像A的ta1目标发送一个消息。消息也推到A了。但是A没有返回提交位移。就导致这条消息进入到B的的%RETRY%groupname下的重试队列里面去了。后面重试会被MQ推送给B。这里像A的tag1发送消息失败了。不应该是到A的%RETRY%groupneame下面的重试队列么。为啥到%RETRY%B里面去了
你的描述很可能不符合现实，或者还有一些别的信息没有输入。按照你的说法， B消费了消息1，发送了消息2给A，这时候A对于消息2的消费失败了，这个消息2肯定进的是%RETRY%ConsumerA里面，而不可能进入B的重试Topic的，麻烦检查下是否A B 用了一样的consumer group名字？还是说有别的信息你没有提供。
我遗漏了一些前提条件。我补充一下。AB两个消费者他们的groupname不一样，然后订阅的是同一个topic下面的 tag1，tag2。 B在业务代码里面像topic的tag1发送一条消息 ，A也接收到了但是没有处理成功。然后这条消息我同步控制台发现进入到了topic 为%RETRY%ConsumerB的下面。由于mq默认消费者B订阅重试主题是ALL也就是* 所以导致这个重试消息再推送的时候推给了B。
@jiaoxinnyu 你说的现象不合逻辑，如果是真的如此就是bug了。建议你贴一下能复现问题的test case。
我的代码是消费者1的group 为ExternalOrderClusteringConsumer 订阅TopicExternalOrder下的 tag1,mq默认订阅%RETRY%ExternalOrderClusteringConsumer的tag all 消费者2的group为TopicExternalOrder 订阅TopicExternalOrder下的 tag2,mq默认会订阅%RETRY%order_callback_group 的tag all。是不是因为两个groupname公用一个topic的问题？这个消息的tag不一样 但是topic是一样的 所以导致进入到了消费者2的重试队列里面了
@jiaoxinnyu 共同监听一个topic是没问题的，检查下你的消费者1发送消息给消费者2的时候是否消费失败了，而不是消费者2自己消费失败。