Hi, Rongtong Jin:
I've updated the RIP document with a more detailed design: - 中文版: https://github.com/imjyz/rocketmq/blob/develop/docs/cn/RIP-84-%E6%B6%88%E8%B4%B9%E8%80%85%E6%A0%87%E7%AD%BE.md - English version: https://github.com/imjyz/rocketmq/blob/develop/docs/en/RIP-84-Consumer-Tag.md Regarding the concern about lightweight implementation: my proposal only introduces an additional cache—no new components are added, and the client-side usage remains sufficiently lightweight. For other questions (due to their complexity and volume), please refer to the detailed answers in the documentation: 1. https://github.com/imjyz/rocketmq/blob/develop/docs/en/RIP-84-Consumer-Tag.md#broker-side 2. https://github.com/imjyz/rocketmq/blob/develop/docs/en/RIP-84-Consumer-Tag.md#rejected-alternatives At 2025-12-11 11:26:33, "Rongtong Jin" <[email protected]> wrote: >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
