Subscription Relationship Consistency

Last updated: 2025-07-15 17:46:17
Subscription Relationship Consistency
Last updated: 2025-07-15 17:46:17
This document describes the key points of subscription relationship consistency, from definition and constraint mechanisms to underlying implementation principles and optimization practices. It also combines actual case sharing of TDMQ RocketMQ's solution for inconsistent subscription relationships, helping developers quickly locate the root cause and build a stable and reliable distributed messaging system.
Defining Subscription Relationships
The subscription relationship is the rule and status configuration for consumers to obtain and process messages in the RocketMQ system. It is dynamically registered to the server by the consumer group and subsequently matches messages and maintains consumption progress according to the filtering rules defined in the subscription relationship during message transmission.
By configuring the subscription relationship, you can control the following consumption behavior:
Message filter rule: Used to control which messages within a topic consumers process when consuming messages. Setting a filter rule enables efficient filtering of required message collections and flexible adjustment of the reception range based on different business scenarios.
Consumption status: The RocketMQ server provides subscription relationship persistence by default. After a consumer group registers its subscription relationship with the server, it can obtain the pre-offline consumption progress and resume consumption post-launch.
In the domain model of RocketMQ, the location and process of the subscription relationship are as follows:
﻿
1. The message is initialized by the producer and sent to the RocketMQ server.
2. Messages are stored in the specified queue of the topic in the order they arrive at the RocketMQ server.
3. Consumers obtain messages from the RocketMQ server according to the specified subscription relationship and consume them.
Subscription Relationship Consistency Constraints
Subscription relationship consistency requires that all consumer instances in the same consumer group must have identical subscribed topics and filter rules. Here, three constraints are involved:
Consumption groups must be consistent
For most distributed applications, a consumption group typically mounts multiple Consumer instances, and the constraint range for subscription relationship consistency is all consumers in the same consumption group.
Subscribed topics must be consistent
All consumers in the same consumption group must subscribe to the same topics. For example, if consumer1 subscribes to TopicA and TopicB, consumer2 must also subscribe to TopicA and TopicB. It cannot subscribe only to TopicA, only to TopicB, or to TopicA and TopicC.
Filter rules must be consistent
All consumers in the same consumption group must have consistent filter rules, including the number of tags and the order in which they appear. For example, if consumer1 subscribes to TopicB with tags Tag1||Tag2, consumer2 must also subscribe to TopicB with tags Tag1||Tag2. It cannot subscribe only to Tag1, only to Tag2, or to Tag2||Tag1.
Examples of Consistent Subscription Relationship
The following diagram shows two common correct subscription relationships, corresponding to two cases:
﻿
Correct example 1: Single Topic with Single Tag subscription
As shown in figure, both consumer1 and consumer2 in Group 1 subscribe to all messages in TopicA.
Correct example 2: Single Topic with multiple Tag subscriptions
As shown in figure, both consumer1 and consumer2 in Group 2 subscribe to messages in TopicA with Tag1 or Tag2, and the sequence is Tag1||Tag2.
Examples of Inconsistent Subscription Relationship
The following diagram shows three typical incorrect subscription relationships, corresponding to three cases:
﻿
Incorrect example 1: Different subscription topics
As shown in figure, consumer1 and consumer2 in Group 1 subscribe to different topics.
Incorrect example 2: The subscription Topic is identical but the Tag is different
As shown in figure, consumer1 in Group 2 subscribes to Tag1 in TopicA, while consumer2 subscribes to Tag2 in TopicA.
Incorrect example 3: The subscription Topic and Tag are the same but the Tag sequence is different
As shown in figure, consumer1 in Group 3 subscribes to Tag1||Tag2 in TopicA, while consumer2 subscribes to Tag2||Tag1 in TopicA. Although the subscribed tags are the same, the sequential order is different, which does not meet the subscription consistency constraint.
Impact of Inconsistent Subscription Relationship
If the subscription relationship is inconsistent, it may cause message consumption logic chaos, duplicate consumption, or message loss.
In the following example, here we start two consumers, they belong to consumption group Group1, both subscribe to topic TopicA, but consumer1 subscribes to messages of Tag1, consumer2 subscribes to messages of Tag2.
String topic = "TopicA";
String consumerGroup = "Group1";
FilterExpression filterExpressionTag1 = new FilterExpression("Tag1", FilterExpressionType.TAG);
PushConsumer consumer1 = provider.newPushConsumerBuilder()
    .setConsumerGroup(consumerGroup)
    .setSubscriptionExpressions(Collections.singletonMap(topic, filterExpressionTag1))
    .build();
FilterExpression filterExpressionTag2 = new FilterExpression("Tag2", FilterExpressionType.TAG);
PushConsumer consumer2 = provider.newPushConsumerBuilder()
    .setConsumerGroup(consumerGroup)
    .setSubscriptionExpressions(Collections.singletonMap(topic, filterExpressionTag2))
    .build();
﻿
In such cases, what are the performance of the two clients?
Consumer1 is unable to consume messages with Tag1 because when pulling messages, the subscription information of the consumption group on the server side has Tag2. After server-side filtering, all messages pulled by consumer1 have Tag2. However, the consumer also filters messages after receiving them, so some messages are filtered.
Consumer2 can only consume part of messages with Tag2 because only part of the queue is assigned to consumer2.
However, on the server side, the subscription information of each consumer client in the same consumption group may be overwritten mutually, so this kind of consumption status is super chaotic. In the example above, the consumption of consumer1 and consumer2 may also switch.
Tencent Cloud Optimization Practice
Inconsistent subscription relationship may directly cause message consumption exception, requiring rapid positioning and fix. TDMQ RocketMQ Console provides visual inspection capacity without manual intervention to check logs or configuration one by one. Via console, you can complete issue discovery, locating, and fix in 3 steps to reduce Ops complexity.
1. One-click scan
Automatically compare subscription configurations of all clients in the consumption group and highlight inconsistent subscription relationships.
﻿
2. Precise positioning
Click the inconsistency details to directly associate with the specific client instance and quickly determine the instance of unexpected subscription relationships.
﻿
3. Closed-loop verification
Revised real-time synchronization of subscription relationship status to ensure the consumption group behaves as expected.
FAQs
In which typical scenarios does inconsistent subscription relationship occur?
The environment is not completely isolated. The non-production and production environments use the same Group to subscribe to different Topics.
Business code modifies the subscription relationship. New and old versions of consumers coexist during grayscale and version release.
Usage recommendations
Subscription Relationship Consistency is the core guarantee for correct consumption behavior in the RocketMQ message system.
1. Core constraints: All consumption within the same consumption group must strictly adhere to the principle of identical topic and filter rule (including Tag sequence). Any variation may cause message loss.
2. Tencent Cloud capacity: Rely on the console's one-click scan, precise positioning, and closed-loop verification feature, developers can rapidly identify anomalies in instances and fix them, shortening traditional manual troubleshooting duration from hour-level to minute-level.
3. Best practice: It is recommended to pass strategies such as consumption group isolation, strict verification of dynamic configuration, and hierarchical governance in multi-Topic scenarios to avoid the risk of inconsistent subscription relationship from the source.
﻿
﻿