文章目录在 RocketMQ 里可以这样理解Topic消息的一级分类决定消息发到哪个“业务通道”。比如你项目里TOPIC_COUNT_NOTE_LIKECountNoteLikeTopicTOPIC_COUNT_NOTE_COLLECTCountNoteCollectTopicTOPIC_NOTE_OPERATENoteOperateTopicCountNoteLikeTopic专门放“笔记点赞计数消息”CountNoteCollectTopic专门放“笔记收藏计数消息”。生产者发送消息时必须指定 Topic消费者也按 Topic 订阅。TagTopic 下面的二级分类用来在同一个 Topic 内再区分消息类型。比如笔记操作都走同一个 TopicTOPIC_NOTE_OPERATENoteOperateTopicTAG_NOTE_PUBLISHpublishNoteTAG_NOTE_DELETEdeleteNote发送时可以这样StringdestinationMQConstants.TOPIC_NOTE_OPERATE:MQConstants.TAG_NOTE_PUBLISH;rocketMQTemplate.asyncSend(destination,message,callback);消费者可以根据 Tag 判断是“发布笔记”还是“删除笔记”。Tag 的好处是不用为每个小动作都新建一个 Topic。Group 名也就是consumerGroup消费者组决定“哪些消费者一起分摊消费”。比如RocketMQMessageListener(consumerGroupxiaohashu_group_CountNoteLikeTopic,topicCountNoteLikeTopic)意思是这个消费者属于xiaohashu_group_CountNoteLikeTopic这个组这个组一起消费CountNoteLikeTopic的消息。同一个consumerGroup里的多个消费者实例是竞争消费关系一条消息通常只会被组内一个实例消费。这样可以横向扩容比如启动 3 个计数服务实例它们共同分摊点赞计数消息。不同consumerGroup之间是广播式的独立消费关系同一条消息可以被多个组各消费一次。比如NoteOperateTopic既要给计数服务消费也要给搜索/推荐服务消费那它们应该用不同 group。简单比喻Topic 快递分拣中心的大类货架比如“笔记点赞消息” Tag 货架里的小标签比如“点赞”/“取消点赞” Group 一个取货团队同一个团队内分工取货不同团队各取一份最重要的规则同一个 consumerGroup 下订阅的 Topic/Tag 应该保持一致。 不同业务处理逻辑用不同 consumerGroup。否则就可能出现你截图里的问题同一个组里有人订阅 Topic-A有人订阅 Topic-BRocketMQ 做负载均衡时会把队列分错导致部分消息没人消费。
