Hi, imjyz, the proposal may need a more detailed design, especially on the broker side.
In the current model, all consumers within a consumer group share the same subscription, and messages pulled from a queue can be assigned to any consumer in the group. However, in this new scenario, each consumer effectively has a different "subscription" (via tag-based filtering). This raises several important questions: How should messages be cached when pulled, given the divergent filtering logic per consumer? In the event of consumer failures, how can we ensure no message loss and minimize duplicates? If a single consumer gets stuck or falls behind, could its associated cache grow indefinitely? Given that the goal is to enable canary deployment capabilities, I believe this part of the implementation should ideally remain lightweight. Additionally, an alternative approach—creating a separate consumer group for each canary variant and configuring distinct subscription filters—seems capable of achieving similar outcomes (albeit with limitations in fine-grained traffic control). This alternative is simpler to implement and doesn’t require changes to the existing core logic. Could you clarify the specific advantages of this proposal over that approach? "贾彦昭" <[email protected]>写道： > To the RocketMQ Developers and Community, > I am initiating a formal discussion for RIP-84: Consumer Tag. > > Motivation > > I hope RocketMQ can better support use cases such as gray-scale rollouts and > multi-environment deployments. To this end, I'm proposing a more flexible > message consumption model to enable dynamic and environment-aware > subscription behaviors. > > Proposal Link > > Since I don't have write access to the official wiki, the full RIP document > is available here: > > > https://github.com/imjyz/rocketmq/blob/develop/docs/en/RIP-84-Consumer-Tag.md > > > > > > > Thank you for your review. I look forward to your thoughts and discussion on > this proposal. > > Best regards, > > imjyz
