This is an automated email from the ASF dual-hosted git repository.
RongtongJin pushed a commit to branch new-official-website
in repository https://gitbox.apache.org/repos/asf/rocketmq-site.git
The following commit(s) were added to refs/heads/new-official-website by this
push:
new 60e72f600b add LiteTopic Documents (#773)
60e72f600b is described below
commit 60e72f600bdcd6b02bab39b5a74a7764ebe9b1a0
Author: WentingYang <[email protected]>
AuthorDate: Thu May 14 14:56:39 2026 +0800
add LiteTopic Documents (#773)
* add LiteTopic Documents
* add documents
---------
Co-authored-by: wenting <[email protected]>
---
docusaurus.config.js | 4 +-
.../version-5.0/01-introduction/02concepts.md | 12 +-
.../version-5.0/03-domainModel/01main.md | 12 +-
.../version-5.0/03-domainModel/02topic.md | 2 +-
.../version-5.0/03-domainModel/03litetopic.md | 69 +++++++
.../{03messagequeue.md => 04messagequeue.md} | 0
.../03-domainModel/{04message.md => 05message.md} | 2 +-
.../{04producer.md => 05producer.md} | 2 +-
.../{07consumergroup.md => 08consumergroup.md} | 4 +-
.../{08consumer.md => 09consumer.md} | 2 +-
.../{09subscription.md => 10subscription.md} | 0
.../04-featureBehavior/07messagefilter.md | 2 +-
.../04-featureBehavior/09consumerprogress.md | 2 +-
.../04-featureBehavior/10consumerretrypolicy.md | 4 +-
.../04-featureBehavior/11messagestorepolicy.md | 2 +-
.../version-5.0/06-bestPractice/02ratelimit.md | 218 +++++++++++++++++++++
.../version-5.0/06-bestPractice/03session.md | 75 +++++++
.../version-5.0/06-bestPractice/04multiagent.md | 59 ++++++
.../06-bestPractice/{02dledger.md => 05dledger.md} | 0
.../06-bestPractice/{03access.md => 06access.md} | 2 +-
.../06-bestPractice/{04JVMOS.md => 07JVMOS.md} | 0
.../{05subscribe.md => 08subscribe.md} | 2 +-
.../06-bestPractice/{06FAQ.md => 09FAQ.md} | 0
.../{07access-1.0.md => 10access-1.0.md} | 2 +-
...ms Overview.md => 01RocketMQStreamsOverview.md} | 0
...eams Concept.md => 02RocketMQStreamsConcept.md} | 0
...ick Start.md => 03RocketMQStreamsQuickStart.md} | 0
.../picture/v5/litetopic_domain_model.png | Bin 0 -> 1298128 bytes
.../picture/v5/litetopic_multiagent.png | Bin 0 -> 154100 bytes
.../picture/v5/litetopic_multiagent_practice.png | Bin 0 -> 154100 bytes
.../picture/v5/litetopic_multiagent_practice.svg | 3 +
.../picture/v5/litetopic_ratelimit_practice.svg | 4 +
.../version-5.0/picture/v5/litetopic_session.png | Bin 0 -> 154100 bytes
.../picture/v5/litetopic_session_practice.png | Bin 0 -> 154100 bytes
.../picture/v5/litetopic_session_practice.svg | 3 +
.../version-5.0/01-introduction/02concepts.md | 12 +-
.../version-5.0/03-domainModel/01main.md | 12 +-
.../version-5.0/03-domainModel/02topic.md | 2 +-
.../version-5.0/03-domainModel/03litetopic.md | 70 +++++++
.../{03messagequeue.md => 04messagequeue.md} | 0
.../03-domainModel/{04message.md => 05message.md} | 2 +-
.../{04producer.md => 05producer.md} | 2 +-
.../{07consumergroup.md => 08consumergroup.md} | 4 +-
.../{08consumer.md => 09consumer.md} | 2 +-
.../{09subscription.md => 10subscription.md} | 0
.../04-featureBehavior/07messagefilter.md | 2 +-
.../04-featureBehavior/09consumerprogress.md | 2 +-
.../04-featureBehavior/10consumerretrypolicy.md | 4 +-
.../04-featureBehavior/11messagestorepolicy.md | 2 +-
.../version-5.0/06-bestPractice/02ratelimit.md | 217 ++++++++++++++++++++
.../version-5.0/06-bestPractice/03session.md | 75 +++++++
.../version-5.0/06-bestPractice/04multiagent.md | 59 ++++++
.../06-bestPractice/{02dledger.md => 05dledger.md} | 0
.../06-bestPractice/{03access.md => 06access.md} | 2 +-
.../06-bestPractice/{04JVMOS.md => 07JVMOS.md} | 0
.../{05subscribe.md => 08subscribe.md} | 2 +-
.../06-bestPractice/{06FAQ.md => 09FAQ.md} | 0
.../{07access-1.0.md => 10access-1.0.md} | 2 +-
.../09-streams/01RocketMQ Streams Overview.md | 38 ----
.../09-streams/01RocketMQStreamsOverview.md | 0
.../09-streams/02RocketMQ Streams Concept.md | 65 ------
.../09-streams/02RocketMQStreamsConcept.md | 0
.../09-streams/03RocketMQ Streams Quick Start.md | 162 ---------------
.../09-streams/03RocketMQStreamsQuickStart.md | 0
.../picture/v5/litetopic_domain_model.png | Bin 0 -> 448858 bytes
.../picture/v5/litetopic_multiagent.png | Bin 0 -> 154100 bytes
.../picture/v5/litetopic_multiagent_practice.png | Bin 0 -> 154100 bytes
.../picture/v5/litetopic_multiagent_practice.svg | 1 +
.../picture/v5/litetopic_ratelimit_practice.svg | 4 +
.../version-5.0/picture/v5/litetopic_session.png | Bin 0 -> 154100 bytes
.../picture/v5/litetopic_session_practice.png | Bin 0 -> 154100 bytes
.../picture/v5/litetopic_session_practice.svg | 1 +
72 files changed, 912 insertions(+), 319 deletions(-)
diff --git a/docusaurus.config.js b/docusaurus.config.js
index 5c41c3ffb4..31adc1bc31 100644
--- a/docusaurus.config.js
+++ b/docusaurus.config.js
@@ -200,11 +200,11 @@ const darkCodeTheme =
require("prism-react-renderer/themes/dracula");
},
{
from: '/docs/system-config',
- to: '/docs/bestPractice/04JVMOS'
+ to: '/docs/bestPractice/07JVMOS'
},
{
from: '/docs/faq/',
- to: '/docs/bestPractice/06FAQ'
+ to: '/docs/bestPractice/09FAQ'
},
{
from: '/docs/logappender-example/',
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/01-introduction/02concepts.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/01-introduction/02concepts.md
index 3d99f8b671..1403573a59 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/01-introduction/02concepts.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/01-introduction/02concepts.md
@@ -16,11 +16,11 @@ Starting from version 5.0, Apache RocketMQ supports
enforcing the validation of
## MessageQueue
-MessageQueue is a container that is used to store and transmit messages in
Apache RocketMQ. MessageQueue is the smallest unit of storage for Apache
RocketMQ messages. Learn more
[MessageQueue](../03-domainModel/03messagequeue.md).
+MessageQueue is a container that is used to store and transmit messages in
Apache RocketMQ. MessageQueue is the smallest unit of storage for Apache
RocketMQ messages. Learn more
[MessageQueue](../03-domainModel/04messagequeue.md).
## Message
-A message is the smallest unit of data transmission in Apache RocketMQ. A
producer encapsulates the load and extended attributes of business data into
messages and sends the messages to a Apache RocketMQ broker. Then, the broker
delivers the messages to the consumer based on the relevant semantics. Learn
more[Message](../03-domainModel/04message.md).
+A message is the smallest unit of data transmission in Apache RocketMQ. A
producer encapsulates the load and extended attributes of business data into
messages and sends the messages to a Apache RocketMQ broker. Then, the broker
delivers the messages to the consumer based on the relevant semantics. Learn
more[Message](../03-domainModel/05message.md).
## MessageView
@@ -41,16 +41,16 @@ A message is not removed from the queue immediately after
it has been consumed b
MessageKey is The message-oriented index property. By setting the message
index, you can quickly find the corresponding message content.
## Producer
-A producer in Apache RocketMQ is a functional messaging entity that creates
messages and sends them to the server. A producer is typically integrated on
the business system and serves to encapsulate data as messages in Apache
RocketMQ and send the messages to the server. Learn more
[Producer](../03-domainModel/04producer.md)。
+A producer in Apache RocketMQ is a functional messaging entity that creates
messages and sends them to the server. A producer is typically integrated on
the business system and serves to encapsulate data as messages in Apache
RocketMQ and send the messages to the server. Learn more
[Producer](../03-domainModel/05producer.md)。
## TransactionChecker
Apache RocketMQ uses a transaction messaging mechanism that requires a
producer to implement a transaction checker to ensure eventual consistency of
transactions. Learn more[Transaction
Message](../04-featureBehavior/04transactionmessage.md)。
## ConsumerGroup
-A consumer group is a load balancing group that contains consumers that use
the same consumption behaviors in Apache RocketMQ. Learn more
[ConsumerGroup](../03-domainModel/07consumergroup.md)。
+A consumer group is a load balancing group that contains consumers that use
the same consumption behaviors in Apache RocketMQ. Learn more
[ConsumerGroup](../03-domainModel/08consumergroup.md)。
## Consumer
-A consumer is an entity that receives and processes messages in Apache
RocketMQ. Consumers are usually integrated in business systems. They obtain
messages from Apache RocketMQ brokers and convert the messages into information
that can be perceived and processed by business logic. Learn more
[Consumer](../03-domainModel/08consumer.md)。
+A consumer is an entity that receives and processes messages in Apache
RocketMQ. Consumers are usually integrated in business systems. They obtain
messages from Apache RocketMQ brokers and convert the messages into information
that can be perceived and processed by business logic. Learn more
[Consumer](../03-domainModel/09consumer.md)。
## Subscription
-A subscription is the rule and status settings for consumers to obtain and
process messages in Apache RocketMQ. Subscriptions are dynamically registered
by consumer groups with brokers. Messages are then matched and consumed based
on the filter rules defined by subscriptions. Learn more
[Subscription](../03-domainModel/09subscription.md)。
+A subscription is the rule and status settings for consumers to obtain and
process messages in Apache RocketMQ. Subscriptions are dynamically registered
by consumer groups with brokers. Messages are then matched and consumed based
on the filter rules defined by subscriptions. Learn more
[Subscription](../03-domainModel/10subscription.md)。
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/01main.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/01main.md
index 622e5301fc..0703a1b685 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/01main.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/01main.md
@@ -20,7 +20,7 @@ A producer generates a message and sends it to a Apache
RocketMQ broker. The mes
**Message production**
-[Producer](../03-domainModel/04producer.md)：
+[Producer](../03-domainModel/05producer.md)：
The running entity that is used to generate messages in Apache RocketMQ.
Producers are the upstream parts of business call links. Producers are
lightweight, anonymous, and do not have identities.
@@ -30,11 +30,11 @@ The running entity that is used to generate messages in
Apache RocketMQ. Produce
The grouping container that is used for message transmission and storage in
Apache RocketMQ. A topic consists of multiple message queues, which are used to
store messages and scale out the topic.
-* [MessageQueue](../03-domainModel/03messagequeue.md)：
+* [MessageQueue](../03-domainModel/04messagequeue.md)：
The unit container that is used for message transmission and storage in
Apache RocketMQ. Message queues are similar to partitions in Kafka. Apache
RocketMQ stores messages in a streaming manner based on an infinite queue
structure. Messages are stored in order in a queue.
-* [Message](../03-domainModel/04message.md)：
+* [Message](../03-domainModel/05message.md)：
The minimum unit of data transmission in Apache RocketMQ. Messages are
immutable after they are initialized and stored.
@@ -43,15 +43,15 @@ The running entity that is used to generate messages in
Apache RocketMQ. Produce
**Message consumption**
-* [ConsumerGroup](../03-domainModel/07consumergroup.md)：
+* [ConsumerGroup](../03-domainModel/08consumergroup.md)：
An independent group of consumption identities defined in the
publish/subscribe model of Apache RocketMQ. A consumer group is used to
centrally manage consumers that run at the bottom layer. Consumers in the same
group must maintain the same consumption logic and configurations with each
other, and consume the messages subscribed by the group together to scale out
the consumption capacity of the group.
-* [Consumer](../03-domainModel/08consumer.md)：
+* [Consumer](../03-domainModel/09consumer.md)：
The running entity that is used to consume messages in Apache RocketMQ.
Consumers are the downstream parts of business call links, A consumer must
belong to a specific consumer group.
-* [Subscription](../03-domainModel/09subscription.md)：
+* [Subscription](../03-domainModel/10subscription.md)：
The collection of configurations in the publish/subscribe model of Apache
RocketMQ. The configurations include message filtering, retry, and consumer
progress Subscriptions are managed at the consumer group level. You use
consumer groups to specify subscriptions to manage how consumers in the group
filter messages, retry consumption, and restore a consumer offset.
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/02topic.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/02topic.md
index 73bdf0d9f1..5ddfcf630e 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/02topic.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/02topic.md
@@ -38,7 +38,7 @@ A topic contains one or more queues. Message storage and
scalability are impleme
**Queues**
-* Definition: the actual storage unit that stores messages. A topic contains
one or more queues. For more information, see [Message
queues](../03-domainModel/03messagequeue.md).
+* Definition: the actual storage unit that stores messages. A topic contains
one or more queues. For more information, see [Message
queues](../03-domainModel/04messagequeue.md).
* Value: You can specify the number of queues when you create a topic. Apache
RocketMQ allocates the specified number of queues to the topic.
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/03litetopic.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/03litetopic.md
new file mode 100644
index 0000000000..edfb9bbbfa
--- /dev/null
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/03litetopic.md
@@ -0,0 +1,69 @@
+# LiteTopic
+
+LiteTopics are lightweight, ephemeral sub-channels within a single Apache
RocketMQ topic. You can create millions of fine-grained message channels -- one
per session, task, or user -- without the resource overhead of separate topics.
Each LiteTopic is an auto-managed secondary container inside a single parent
topic, with its own ordered queue, lifecycle, and subscription scope.
+
+## Key concepts
+
+### What is a LiteTopic
+
+A LiteTopic is a secondary container for message transmission and storage
within a parent topic. It groups messages of different child classes -- such as
individual sessions, tasks, or users -- under the same business logic.
+
+LiteTopics serve two purposes:
+
+* **Exclusive consumption and data fencing**: Isolate data from different
child classes into separate LiteTopics for finer-grained storage and
subscription boundaries.
+
+* **Identity and permissions**: Control access at a granularity finer than the
topic level by assigning identities and permissions to individual LiteTopics.
+
+### How LiteTopics fit into the domain model
+
+
+
+A topic is the top-level container for message transmission and storage in
Apache RocketMQ. If a topic is of the Lite type, LiteTopics can be created
within it. The combination of a topic and a LiteTopic uniquely identifies a
message storage container.
+
+Each LiteTopic contains one queue by default, and messages within that queue
are stored and consumed in order.
+
+### LiteTopic properties
+
+**Name**
+
+* Must be globally unique within the parent topic.
+
+* Auto-created on first use: if `setLiteTopic` is called on a message and the
specified LiteTopic does not exist, the system creates it automatically.
+
+* For naming constraints, see [Parameter
limits](../01-introduction/03limits.md).
+
+**Time-to-live (TTL)**
+
+* If a LiteTopic receives no messages for longer than its TTL, the system
deletes it automatically. Deletion releases the quota count.
+
+* Set the TTL through the `expiration` value when you create the Lite-type
topic.
+
+* For TTL constraints, see [Parameter limits](../01-introduction/03limits.md).
+
+## Version compatibility
+
+| **Component** | **Minimum version** |
+|-------------------|------------------------------|
+| Server | 5.5.0 or later |
+| Client (gRPC SDK) | RocketMQ gRPC 5.1.0 or later |
+
+## LiteTopics vs. normal topics
+
+:::info
+Switching a topic to Lite type changes its behavior. Each LiteTopic has only
one queue by default, which limits per-channel TPS but enables ordered
consumption and fine-grained subscription control. Evaluate this tradeoff
before adopting Lite-type topics.
+:::
+
+| **Dimension** | **Lite topic** | **Normal topic** |
+|-------------------------------------|-----------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------|
+| **Primary topic** | Both require you to create topic resources in advance. |
Same as Lite. |
+| **Secondary channels** | Supports millions of LiteTopics under a single
parent topic, each with auto-managed lifecycle. | No secondary channel support.
|
+| **Lifecycle management** | Automatic creation on first send or subscribe.
Automatic deletion after the configured TTL expires. | Manual creation and
deletion only. |
+| **Ordering** | Each LiteTopic has one queue by default. Messages are stored
in order. | Multiple queues. Only partitioned ordered topics guarantee order. |
+| **Per-channel TPS** | Limited per LiteTopic (single queue). Total TPS scales
with the number of LiteTopics. | TPS scales horizontally by queue count and
cluster nodes. |
+| **Subscription consistency** | Flexible: each consumer in the same group can
subscribe to a different set of LiteTopics. | Strict: all consumers in the same
group must share the same subscription. |
+| **Consumption mode** | Ordered only. Each LiteTopic is processed by one
consumer thread. | Ordered or concurrent. |
+| **Dynamic subscription** | Consumers can add or remove LiteTopic
subscriptions at runtime. | Not supported. |
+| **Per-consumer subscription scale** | Up to thousands of LiteTopics per
consumer. | Not applicable. |
+| **Observability** | Message accumulation metrics available. Message
processing latency metrics not available. | Both accumulation and latency
metrics available. |
+| **Message trace** | Supported. | Supported. |
+
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/03messagequeue.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/04messagequeue.md
similarity index 100%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/03messagequeue.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/04messagequeue.md
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/04message.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/05message.md
similarity index 99%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/04message.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/05message.md
index f5bcd9e105..10502f0ed6 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/04message.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/05message.md
@@ -58,7 +58,7 @@ The following figure shows the position of messages in the
domain model of Apach
**Message queue**
-* Definition: the queue to which a message belongs. For more information, see
[Message queues](./03messagequeue.md).
+* Definition: the queue to which a message belongs. For more information, see
[Message queues](./04messagequeue.md).
* Values: specified and populated by the broker.
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/04producer.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/05producer.md
similarity index 99%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/04producer.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/05producer.md
index 6c6bf25bf0..07af0d3359 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/04producer.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/05producer.md
@@ -7,7 +7,7 @@ This section describes the concept of producers in Apache
RocketMQ. It also desc
A producer in Apache RocketMQ is a functional messaging entity that creates
messages and sends them to the server.
-A producer is typically integrated on the business system and serves to
encapsulate data as messages in Apache RocketMQ and send the messages to the
server. For more information about messages, see [Messages](./04message.md).
+A producer is typically integrated on the business system and serves to
encapsulate data as messages in Apache RocketMQ and send the messages to the
server. For more information about messages, see [Messages](./05message.md).
The following message delivery elements are defined on the producer side:
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/07consumergroup.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/08consumergroup.md
similarity index 98%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/07consumergroup.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/08consumergroup.md
index 60e89a28da..246689b947 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/07consumergroup.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/08consumergroup.md
@@ -9,7 +9,7 @@ Unlike consumers that are running entities, consumer groups are
logical resource
In a consumer group, consumers consume messages based on the consumption
behaviors and load balancing policy that are defined in the group. The
following section describes the consumption behaviors that are defined:
-* Subscription: Apache RocketMQ manages and traces subscriptions based on
consumer groups. For more information, see [Subscriptions](./09subscription.md).
+* Subscription: Apache RocketMQ manages and traces subscriptions based on
consumer groups. For more information, see [Subscriptions](./10subscription.md).
aa
* Delivery order: The Apache RocketMQ broker delivers messages to consumers by
using ordered delivery or concurrent delivery. You can configure the delivery
method in the consumer group. For more information, see [fifo
messages](../04-featureBehavior/03fifomessage.md).
@@ -65,7 +65,7 @@ For more information about the valid values and default
values of maximum retrie
**Subscription**
-* Definition: the set of subscription relationships that are associated with
the current consumer group. A subscription includes the topics to which the
consumers subscribe and the message filter rules that are used by consumers.
For more information, see [Subscriptions](../03-domainModel/09subscription.md).
+* Definition: the set of subscription relationships that are associated with
the current consumer group. A subscription includes the topics to which the
consumers subscribe and the message filter rules that are used by consumers.
For more information, see [Subscriptions](../03-domainModel/10subscription.md).
Consumers dynamically register subscriptions for consumer groups. The Apache
RocketMQ broker persists subscriptions and matches the subscriptions to the
consumption progress of messages.
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/08consumer.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/09consumer.md
similarity index 99%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/08consumer.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/09consumer.md
index d8ae4cca66..b95c9dd58f 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/08consumer.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/09consumer.md
@@ -32,7 +32,7 @@ The following figure shows how consumers are positioned in
the domain model of A
**Consumer group name**
-* Definition: the name of the consumer group associated with the current
consumer. Consumers inherit their behavior from the consumer groups. For more
information, see [Consumer groups](./07consumergroup.md).
+* Definition: the name of the consumer group associated with the current
consumer. Consumers inherit their behavior from the consumer groups. For more
information, see [Consumer groups](./08consumergroup.md).
* Values: Consumer groups are the logical resources of Apache
RocketMQ{#product-name}
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/09subscription.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/10subscription.md
similarity index 100%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/09subscription.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/03-domainModel/10subscription.md
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/07messagefilter.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/07messagefilter.md
index 94f19e01ef..740b528a4a 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/07messagefilter.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/07messagefilter.md
@@ -43,7 +43,7 @@ For more information about how to use the filtering methods,
see [Tag-based filt
## Subscription consistency
-Filter expressions are part of a subscription. According to the
publish-subscribe pattern of Apache RocketMQ, the subscription of one consumer
must be consistent with that of another within a consumer group, including
their filter expressions, to avoid situations where some messages cannot be
consumed. For more information, see
[Subscriptions](../03-domainModel/09subscription.md).
+Filter expressions are part of a subscription. According to the
publish-subscribe pattern of Apache RocketMQ, the subscription of one consumer
must be consistent with that of another within a consumer group, including
their filter expressions, to avoid situations where some messages cannot be
consumed. For more information, see
[Subscriptions](../03-domainModel/10subscription.md).
## Tag-based filtering
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/09consumerprogress.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/09consumerprogress.md
index 6a565c5a8c..0939ac3a56 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/09consumerprogress.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/09consumerprogress.md
@@ -21,7 +21,7 @@ The consumer progress management mechanism of Apache RocketMQ
solves the followi
**Message Offset**
-In Apache RocketMQ, messages are queued in topics in the order that they
arrive, and are assigned a unique Long-type coordinate. This is also known as
the offset of the message. For more information about the individual
definitions of these concepts, see [Topic](../03-domainModel/02topic.md) and
[Message queue](../03-domainModel/03messagequeue.md).
+In Apache RocketMQ, messages are queued in topics in the order that they
arrive, and are assigned a unique Long-type coordinate. This is also known as
the offset of the message. For more information about the individual
definitions of these concepts, see [Topic](../03-domainModel/02topic.md) and
[Message queue](../03-domainModel/04messagequeue.md).
Theoretically speaking, a message queue can store an indefinite number of
messages. Therefore, the value range of offset is from 0 to Long.MAX_VALUE. You
can locate any message based on its topic, queue, and offset. The following
figure shows the relationship between these three
concepts.
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/10consumerretrypolicy.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/10consumerretrypolicy.md
index c75662a08d..78702f53ac 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/10consumerretrypolicy.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/10consumerretrypolicy.md
@@ -90,7 +90,7 @@ When a message is retried, its state changes from Ready to
Inflight and then to
**Maximum number of retries**
-The maximum number of retries for a push consumer is specified in the metadata
when the consumer group is created. For more information, see [Consumer
groups](../03-domainModel/07consumergroup.md).
+The maximum number of retries for a push consumer is specified in the metadata
when the consumer group is created. For more information, see [Consumer
groups](../03-domainModel/08consumergroup.md).
For example, if the maximum number of retries is three, the message can be
delivered four times: one original attempt and three retries.
@@ -169,7 +169,7 @@ As shown in the following figure, the change takes effect
immediately, that is,
**Maximum number of retries**
-The maximum number of retries for a simple consumer is specified in the
metadata when the consumer group is created. For more information, see
[Consumer groups](../03-domainModel/07consumergroup.md).
+The maximum number of retries for a simple consumer is specified in the
metadata when the consumer group is created. For more information, see
[Consumer groups](../03-domainModel/08consumergroup.md).
**Message retry interval**
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/11messagestorepolicy.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/11messagestorepolicy.md
index 13d7bcd642..a087e6a417 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/11messagestorepolicy.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/04-featureBehavior/11messagestorepolicy.md
@@ -4,7 +4,7 @@ This topic describes how Apache RocketMQ stores messages,
including storage gran
## Background information
-Based on the definition of [MessageQueue](../03-domainModel/03messagequeue.md)
in Apache RocketMQ, messages are stored in queues in the order in which the
messages are received by the broker. In theory, the number of messages that a
queue can store is unlimited.
+Based on the definition of [MessageQueue](../03-domainModel/04messagequeue.md)
in Apache RocketMQ, messages are stored in queues in the order in which the
messages are received by the broker. In theory, the number of messages that a
queue can store is unlimited.
In actual deployment scenarios, messages cannot be permanently stored because
the physical storage space of a broker is limited. Therefore, when you deploy
messages, you need to answer three questions: What criteria are used to
determine how to store messages on a broker? What granularity is used to manage
the stored messages? What measures must be taken when message storage usage
exceeds the limit? The message storage and cleanup mechanisms of Apache
RocketMQ provide answers to the prec [...]
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/02ratelimit.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/02ratelimit.md
new file mode 100644
index 0000000000..f1f77fd4c0
--- /dev/null
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/02ratelimit.md
@@ -0,0 +1,218 @@
+# Fine-Grained Task Isolation and Rate Limiting Based on RocketMQ LiteTopic
+
+This document provides a detailed guide on how to leverage Apache RocketMQ's
**LiteTopic** feature to build a general-purpose system supporting fine-grained
task isolation and dynamic rate limiting at massive scale.
+
+## Background and Challenges
+In AI inference and business processing scenarios (such as image generation,
video rendering, large-scale computation, etc.), backend services typically
rely on high-cost computing resources like GPUs. As a platform service
provider, with limited computing resources, it is essential to prioritize
service quality for important users or critical task types.
+
+While ensuring proper allocation of high-priority computing resources, the
platform also faces the following typical challenges:
+
++ **Resource Isolation**: Requests from important customers or critical tasks
require dedicated processing resource pools to avoid mixing with other traffic.
++ **Traffic Non-interference**: Customers at the same priority level should be
isolated from each other, preventing a single customer's burst traffic from
occupying resources and causing long queuing for other customers' requests.
++ **Dynamic Subscription Management**: User ID lists or task type lists change
in real-time; downstream consumers need to dynamically adjust subscription
relationships, adding or removing subscription targets.
++ **Fine-grained Rate Limiting**: When request volume for a specific type or
user exceeds the maximum processing capacity, consumption must be paused
individually for that dimension with backoff handling, without affecting other
dimensions.
++ **Cluster-level Traffic Governance**: When the overall cluster processing
capacity reaches its limit, the system needs to identify and pause consumption
of top-traffic queues, gradually resuming after the cluster completes scaling.
++ **Peak Shaving and Valley Filling**: Smooth out highly fluctuating request
traffic to ensure backend service stability and availability.
+
+### Limitations of Traditional Approaches
+#### Approach 1: Isolation Based on RocketMQ Standard Topics
+Creating independent Topics and ConsumerGroups for each user ID or task type,
and launching corresponding consumer instances for each ConsumerGroup. This
approach has the following issues:
+
++ Topics and ConsumerGroups are heavyweight resources. After creation,
producers and consumers need to complete connection initialization and other
resource preparation, affecting the smoothness of message sending and
consumption.
++ Downstream consumers need to actively detect changes in the upstream
producer's user or task type lists, dynamically adding or removing subscription
relationships, making true decoupling between producers and consumers
impossible.
+
+#### Approach 2: Isolation Based on Kafka
+Kafka faces the same heavyweight resource issues as the RocketMQ standard
Topic approach. If attempting to map different users or task types through
Kafka Topic partitions, having too many partitions in a single Topic leads to
dramatic increases in Broker resource consumption and performance overhead,
introducing stability risks.
+
+## Solution
+### Core Architecture: Fine-Grained Isolation and Rate Limiting Based on
LiteTopic
+
+
+
+This document adopts Apache RocketMQ's **LiteTopic (Lightweight Topic)**
feature to build a novel fine-grained isolation and dynamic rate limiting
architecture:
+
++ **Message Sending Side**: Routes messages to the corresponding LiteTopic
based on business dimensions (such as user ID, model ID, task type).
++ **Message Consuming Side**: Consumers uniformly subscribe to the parent
Topic (i.e., all LiteTopics). When LiteTopics are dynamically added or removed,
consumers do not need to adjust their subscription relationships — they can
continue working as long as the consumer cluster has sufficient capacity.
+
+### Core Advantages of LiteTopic
++ **Lightweight with Massive Scale Support**: A single instance can support
millions of LiteTopics, allowing creation of dedicated lightweight queues for
each user or task type to meet large-scale fine-grained isolation requirements.
++ **Resource Decoupling and Efficient Reuse**: LiteTopics do not need to be
pre-created — they are automatically generated on demand when messages are
written, without affecting send latency. After becoming idle, they are
automatically cleaned up according to built-in TTL policies, enabling fully
automated lifecycle management.
++ **Precise Flow Control**: The consuming side supports returning a Suspend
status, enabling precise suspension of specific LiteTopics to pause consumption
and achieve millisecond-level fine-grained rate limiting. This only affects the
target LiteTopic without interfering with normal consumption of other queues.
++ **Physical Isolation with Logical Unity**: Each user or business dimension
has an independent LiteTopic, achieving data-level isolation. Meanwhile, all
consumer instances belong to the same ConsumerGroup, sharing thread pools and
other resources, balancing isolation with resource utilization.
+
+## Steps
+### Step 1: Create the Parent Topic
+Create a parent Topic through the Apache RocketMQ console or API to host all
LiteTopics. All rate-limited objects share the same parent Topic — no need to
create separate ones for each user.
+
+Example configuration:
+
++ Topic name: `rate-limit-parent-topic`
++ Message type: Normal message
+
+> **Note**: The parent Topic is the carrier of LiteTopics. A single parent
Topic can host millions of LiteTopics.
+
+### Step 2: Create a Consumer Group
+Create a unified Consumer Group shared by all consumer machines.
+
+Example configuration:
+
++ Group name: `GID_rate_limit_consumer`
++ Consumption mode: **Cluster consumption**
+
+### Step 3: Send Messages to LiteTopic
+On the message sending side, write messages to the corresponding LiteTopic
based on user identifiers. LiteTopics do not need to be pre-created — they are
automatically generated on first send.
+
+```java
+// Parent Topic name
+String topic = "rate-limit-parent-topic";
+
+// Get Producer instance
+final Producer producer = ProducerSingleton.getInstance(topic);
+
+// Build message body
+byte[] body = "your message content".getBytes(StandardCharsets.UTF_8);
+
+// Use user identifier as LiteTopic name to achieve per-user isolation
+String userId = "user_10086";
+
+final Message message = provider.newMessageBuilder()
+ // Set parent Topic
+ .setTopic(topic)
+ // Set LiteTopic for per-user isolation
+ .setLiteTopic(userId)
+ .setBody(body)
+ .build();
+
+try {
+ final SendReceipt sendReceipt = producer.send(message);
+ log.info("Message sent successfully, messageId={}",
sendReceipt.getMessageId());
+} catch (LiteTopicQuotaExceededException e) {
+ // LiteTopic count exceeds instance quota limit
+ log.error("LiteTopic quota exceeded, please upgrade instance", e);
+} catch (Throwable t) {
+ log.error("Failed to send message", t);
+}
+```
+
+**Key Notes**:
+
++ The parameter of `setLiteTopic()` is the LiteTopic name. It is recommended
to use business identifiers such as user ID or task type ID for easy matching
with rate limiting strategies.
++ When a LiteTopic receives its first message, the system automatically
creates the queue — no additional operations required.
++ If the LiteTopic count exceeds the instance quota, a
`LiteTopicQuotaExceededException` will be thrown, requiring an instance
specification upgrade.
+
+### Step 4: Consume Messages and Implement Rate Limiting
+The consuming side uses `LitePushConsumer` to subscribe to all LiteTopics
under the parent Topic, and applies rate limiting based on business strategies
within the message processing logic.
+
+```java
+String consumerGroup = "GID_rate_limit_consumer";
+String topic = "rate-limit-parent-topic";
+
+// Build LitePushConsumer instance
+LitePushConsumer litePushConsumer = provider.newLitePushConsumerBuilder()
+ .setClientConfiguration(clientConfiguration)
+ // Set consumer group
+ .setConsumerGroup(consumerGroup)
+ // Bind parent Topic
+ .bindTopic(topic)
+ // Set message listener
+ .setMessageListener(messageView -> {
+ // Get the LiteTopic the message belongs to (i.e., user identifier)
+ String liteTopic = messageView.getLiteTopic();
+
+ // Execute business logic (e.g., call downstream service)
+ boolean success = processMessage(messageView);
+
+ if (success) {
+ // Business processing successful
+ // Check if this user needs rate limiting
+ if (rateLimiter.shouldLimit(liteTopic)) {
+ // Return Suspend to pause pulling from this LiteTopic
+ // Parameter is the suspension duration; no new messages
+ // from this LiteTopic will be pulled during this period
+ return ConsumeResult.Suspend(Duration.ofMillis(500));
+ }
+ return ConsumeResult.SUCCESS;
+ } else {
+ // Business processing failed, message will be retried
+ return ConsumeResult.FAILURE;
+ }
+ })
+ .build();
+```
+
+**Key Notes**:
+
++ `ConsumeResult.Suspend(Duration)` is the core rate limiting mechanism
provided by LiteTopic: after returning this result, the Broker will pause
message pulling for that LiteTopic for the specified duration, without
affecting normal consumption of other LiteTopics.
++ The rate limiting strategy (`rateLimiter.shouldLimit()`) is implemented by
the business side and can be based on algorithms such as sliding window or
token bucket, controlling consumption rate on a per-user dimension.
+
+### Step 5: Implement Rate Limiting Strategy (Reference Example)
+Below is a simplified example of a fixed-window rate limiter that controls
consumption rate on a per-LiteTopic (i.e., per-user) dimension:
+
+```java
+import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
+import java.util.concurrent.atomic.AtomicInteger;
+
+public class LiteTopicRateLimiter {
+
+ // Rate limit configuration per LiteTopic: key = liteTopic, value = max
consumption per second
+ private final Map<String, Integer> rateLimitConfig;
+
+ // Fixed window counters
+ private final Map<String, AtomicInteger> windowCounters = new
ConcurrentHashMap<>();
+
+ /**
+ * Determine whether the specified LiteTopic needs rate limiting
+ * @param liteTopic LiteTopic name (user identifier)
+ * @return true if rate limiting is needed
+ */
+ public boolean shouldLimit(String liteTopic) {
+ Integer maxQps = rateLimitConfig.get(liteTopic);
+ if (maxQps == null) {
+ // No rate limiting strategy configured, no limiting applied
+ return false;
+ }
+
+ AtomicInteger counter = windowCounters.computeIfAbsent(
+ liteTopic, k -> new AtomicInteger(0));
+
+ return counter.incrementAndGet() > maxQps;
+ }
+
+ /**
+ * Periodically reset window counters (executed once per second)
+ */
+ @Scheduled(fixedRate = 1000)
+ public void resetWindow() {
+ windowCounters.values().forEach(c -> c.set(0));
+ }
+}
+```
+
+## Best Practices
+### LiteTopic Naming Conventions
+It is recommended to use naming rules with clear business semantics for easy
operations troubleshooting and rate limiting strategy matching.
+
++ Rate limiting by user: `{userId}`, e.g., `user_10086`
++ Rate limiting by user + business type: `{userId}_{bizType}`, e.g.,
`user_10086_premium`
++ Rate limiting by task type: `{taskType}_{taskId}`, e.g., `sms_task_001`
+
+### Choosing Suspend Duration
+Suspend duration directly affects rate limiting effectiveness and message
processing latency. It is recommended to set it appropriately based on business
scenarios:
+
++ **Light rate limiting** (reduce speed without blocking): 50-200 milliseconds
++ **Moderate rate limiting** (noticeably reduce consumption rate): 200-1000
milliseconds
++ **Heavy rate limiting** (near consumption pause): 1000-5000 milliseconds
+
+### Integration with Backend Elastic Scaling
+In backend service elastic scaling scenarios, it is recommended to combine the
Suspend mechanism for smooth traffic growth control:
+
+1. During the initial traffic burst, return a larger Suspend value (e.g., 2000
milliseconds) for users exceeding the threshold, significantly reducing
consumption rate.
+2. As backend scaling gradually completes, dynamically reduce the Suspend
value (e.g., from 2000 milliseconds down to 100 milliseconds), allowing traffic
to grow smoothly.
+3. After scaling is complete, remove the rate limiting strategy and restore
normal consumption rate.
+
+This strategy ensures the consumption traffic growth curve matches the backend
computing capacity scaling curve as closely as possible, minimizing service
unavailability caused by the scaling time window.
+
+## Related Documentation
++ [Apache RocketMQ Official Documentation](https://rocketmq.apache.org/docs/)
++ [RocketMQ 5.x Client SDK Guide](https://rocketmq.apache.org/docs/sdk/java/)
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/03session.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/03session.md
new file mode 100644
index 0000000000..51362ff62f
--- /dev/null
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/03session.md
@@ -0,0 +1,75 @@
+# Manage distributed session state with RocketMQ LiteTopic
+
+This document describes how to use the LiteTopic feature of Apache RocketMQ to
build a distributed, highly available session state management system.
+
+## Background and challenges
+
+When building modern AI applications, developers often face a difficult
challenge: how to maintain session continuity over unstable networks that rely
on long-lived connections, such as WebSocket or Server-Sent Events (SSE).
Traditional session management methods can easily lose context during node
failures or network reconnections, leading to wasted computing resources. The
primary challenges include:
+
+* **Long-running and multi-turn interactions**: The inference process for a
large language model (LLM) can take several seconds or longer. User-AI
interactions are often multi-turn conversations that are highly dependent on
context.
+
+* **High computing costs**: Each AI task consumes expensive GPU resources. If
a network disruption interrupts the connection and terminates the task, it
results in a significant waste of resources.
+
+* **Unstable long-lived connections**: AI applications typically use
technologies like SSE or WebSocket to push streaming results in real time.
However, in a production environment, disruptions such as gateway or service
node restarts, connection timeouts, and mobile network switching are
unavoidable.
+
+**Pain points of traditional architectures:** In a traditional monolithic or
simple distributed architecture, session state is often tied to a specific
application server node. If a user's long-lived connection drops and reconnects
to a different node, the new node cannot retrieve the previous session state.
This interrupts the conversation and results in a poor user experience.
+
+## Solution
+
+To address these challenges, we propose a distributed session state management
solution based on Apache RocketMQ. This solution uses the lightweight topic
(LiteTopic) feature as a transport channel for session messages and employs
stateless application server nodes to ensure high availability and session
continuity.
+
+### System architecture
+
+
+
+* **Application server (stateless)**: The application service can be
horizontally scaled across multiple nodes (Node 1, Node 2, and so on). These
nodes do not store session state and are only responsible for handling
connections and forwarding messages.
+
+* **RocketMQ LiteTopic**: A LiteTopic is used as a "channel" for each session.
Each session corresponds to a unique LiteTopic. We recommend the naming
convention `chat/{sessionID}`.
+
+* **Large model task scheduling component**: This component is responsible for
interacting with the LLM and sending the generated streaming data to the
corresponding LiteTopic.
+
+### Communication flow
+
+1. **Session establishment and initial connection**
+
+ 1. **User access**: Web client 2 sends a request to establish a long-lived
connection (for example, a WebSocket) with application server Node 1.
+
+ 2. **Session creation**: The system generates a unique sessionID, such as
Session2.
+
+ 3. **Channel subscription**: Application server Node 1 subscribes to the
corresponding LiteTopic in RocketMQ based on the sessionID (that is,
`LiteTopic2`, named `chat/Session2`).
+
+ 4. **Task scheduling**: After receiving the request, the large model task
scheduling component calls the LLM. It then sends the streaming data (tokens)
from the LLM as a series of messages to `LiteTopic2`.
+
+ 5. **Message push**: Node 1 receives the messages and pushes them in real
time to Web client 2 through the long-lived connection.
+
+2. **Failure handling and reconnection**
+
+ When a network fluctuation or node failure occurs, the system recovers as
follows:
+
+ 1. **Connection interruption**: Assume the connection between Web client 2
and Node 1 unexpectedly drops. Node 1 detects the closed connection and
unsubscribes from `LiteTopic2`.
+
+ 2. **Automatic reconnection**: The client logic for web client 2 triggers
an automatic reconnection. Because of load balancing, the reconnection request
is routed to application server node 2.
+
+ 3. **State takeover**:
+
+ 1. Node 2 receives the reconnection request and parses the sessionID
(Session2).
+
+ 2. Node 2 immediately subscribes to `LiteTopic2` in RocketMQ.
+
+ 4. **Message resumption**:
+
+ 1. RocketMQ provides message persistence and offset management. When
Node 2 subscribes to `LiteTopic2`, it pulls unconsumed messages starting from
the previous offset.
+
+ 2. The large model task scheduling component continues sending data to
`LiteTopic2`. Node 2 now receives the data and pushes it to Web client 2.
+
+### Benefits
+
+* **Session continuity**: Regardless of which node the client reconnects to,
it can seamlessly receive subsequent messages by subscribing to the same
LiteTopic. The process is transparent to the user.
+
+* **Resource protection**: Because the session state is managed in RocketMQ, a
connection interruption does not stop the background LLM task, which prevents
wasting expensive computing resources.
+
+* **Auto scaling**: The application servers are completely stateless, allowing
them to be scaled in or out based on traffic load. This eliminates concerns
about sticky sessions.
+
+### Summary
+
+The LiteTopic feature of Apache RocketMQ offers an effective solution to the
complex challenge of managing distributed sessions in AI applications. This
architecture makes application nodes stateless, improves the system's auto
scaling capabilities, and, most importantly, ensures a seamless user experience
and the efficient use of AI computing resources in complex network
environments. It is a proven best practice for building enterprise-grade,
highly available AI agent applications.
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/04multiagent.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/04multiagent.md
new file mode 100644
index 0000000000..7776b4055f
--- /dev/null
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/04multiagent.md
@@ -0,0 +1,59 @@
+# Asynchronous multi-agent communication with RocketMQ LiteTopic
+
+This article explains how to use Apache RocketMQ to build a highly concurrent
and scalable multi-agent system.
+
+## Background and challenges
+
+As AI applications become increasingly complex, single-agent architectures are
often insufficient, making multi-agent systems a growing trend. However, the
long-running nature of AI tasks poses challenges for traditional synchronous
calls, leading to thread blocking and scalability bottlenecks. This hands-on
tutorial demonstrates how to use the message queue and LiteTopic features of
RocketMQ to build a multi-agent system with asynchronous communication. This
approach resolves the blocki [...]
+
+## Solution
+
+### System architecture
+
+
+
+* **Web client**: The user interface for sending requests and receiving final
results.
+
+* **Supervisor Agent**: The core orchestrator of the system. It receives
requests from the web client, decomposes complex tasks into sub-tasks, and
dispatches them to appropriate worker agents. It also aggregates results from
the worker agents and returns the final output to the web client.
+
+* **Worker Agent**: Responsible for executing specific, specialized sub-tasks.
Each worker agent focuses on its area of expertise.
+
+### Communication workflow
+
+RocketMQ decouples the communication workflow, which consists of two phases:
request and response.
+
+1. **Request phase**:
+
+ 1. The Supervisor Agent receives a request from the web client and
decomposes the task.
+
+ 2. For each sub-task, it creates a request message and sends it to the
corresponding **request topic**. For example, it might send a message to "Topic
1 (Request)" for "Worker Agent 1" and to "Topic 2 (Request)" for "Worker Agent
2".
+
+ 3. Each worker agent subscribes to its designated request topic. When a new
message arrives, the agent immediately begins processing it.
+
+2. **Response phase**:
+
+ 1. While processing the request, the Supervisor Agent creates and
subscribes to a **response topic**. This is a special **lightweight topic**.
+
+ 2. After completing its sub-task, each worker agent sends its result to a
**LiteTopic** within the response topic. This LiteTopic can be named using a
unique Task ID or Session ID to ensure responses are routed correctly.
+
+ 3. By subscribing to the response topic, the Supervisor Agent receives the
results from all worker agents in real time.
+
+ 4. Finally, the Supervisor Agent aggregates the results from all sub-tasks
and pushes them to the web client via HTTP, enabling streaming responses.
+
+## Key technology: RocketMQ LiteTopic
+
+The **LiteTopic** feature of RocketMQ plays a crucial role in this solution.
+
+Traditional topics can be resource-intensive to create and manage. In
contrast, a LiteTopic is a lightweight topic that offers the following
advantages, making it ideal for the response phase in a multi-agent system:
+
+* **Dynamic creation and deletion**: You can dynamically create a dedicated
LiteTopic for each task, for example, by using the task ID as its name. The
LiteTopic is automatically deleted after its TTL expires. This approach avoids
pre-provisioning numerous static topics and significantly improves system
flexibility and resource utilization.
+
+* **Isolation**: A LiteTopic has lower creation and maintenance overhead than
standard topics, making it suitable for large-scale, high-concurrency scenarios
with short-lived messages.
+
+* **Precise subscription**: Within the same ConsumerGroup, each consumer can
subscribe to a different set of LiteTopics.
+
+* **Ordered messages**: Messages within a single LiteTopic are ordered. This
ensures that streaming responses are delivered in the correct sequence.
+
+## Summary
+
+This tutorial demonstrates how to use the LiteTopic feature of Apache RocketMQ
to build an efficient, decoupled multi-agent system with asynchronous
communication. This solution transitions long-running AI tasks from a
synchronous, blocking model to an asynchronous, non-blocking model. It resolves
the issue of thread blocking and enhances system stability and scalability by
using the buffering and peak-shaving capabilities of the message queue. This
architecture provides a robust model f [...]
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/02dledger.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/05dledger.md
similarity index 100%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/02dledger.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/05dledger.md
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/03access.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/06access.md
similarity index 99%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/03access.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/06access.md
index fad916e1dd..117cd79235 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/03access.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/06access.md
@@ -4,7 +4,7 @@
This document describes **Access Control 2.0 (ACL 2.0)**, applicable to
**RocketMQ 5.3.0** and above.
-- If you are using **RocketMQ 4.x, 5.0-5.2, or 5.3.0-5.3.2**, please refer to
[ACL 1.0 Documentation](07access-1.0)
+- If you are using **RocketMQ 4.x, 5.0-5.2, or 5.3.0-5.3.2**, please refer to
[ACL 1.0 Documentation](10access-1.0)
- **Starting from RocketMQ 5.3.3, ACL 1.0 is no longer supported**. It is
recommended to upgrade to ACL 2.0
- If you are migrating from ACL 1.0 to 2.0, please refer to the [ACL 1.0
Migration](#5-migrating-from-acl-10-to-acl-20) section
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/04JVMOS.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/07JVMOS.md
similarity index 100%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/04JVMOS.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/07JVMOS.md
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/05subscribe.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/08subscribe.md
similarity index 98%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/05subscribe.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/08subscribe.md
index 0c3b5b1a00..f6f0ffa996 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/05subscribe.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/08subscribe.md
@@ -2,7 +2,7 @@
## Introduction
-Subscription relationships are a very important part of the RocketMQ domain
model, used to express the control metadata for consumer consumption of
messages. For a complete concept, please refer to [Subscription Relationship
Model](../03-domainModel/09subscription.md).
+Subscription relationships are a very important part of the RocketMQ domain
model, used to express the control metadata for consumer consumption of
messages. For a complete concept, please refer to [Subscription Relationship
Model](../03-domainModel/10subscription.md).
Subscription relationships are consistent when all Consumer instances in the
same consumer group have exactly the same subscriptions to Topic and Tag. If
the subscription relationships (consumer group name-Topic-Tag) are not
consistent, it can lead to confusion in consuming messages and even loss of
messages.
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/06FAQ.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/09FAQ.md
similarity index 100%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/06FAQ.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/09FAQ.md
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/07access-1.0.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/10access-1.0.md
similarity index 99%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/07access-1.0.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/10access-1.0.md
index b28327e883..dd799d182b 100644
---
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/07access-1.0.md
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/06-bestPractice/10access-1.0.md
@@ -11,7 +11,7 @@ This document describes **RocketMQ ACL 1.0**, applicable to
**RocketMQ 4.x, 5.0-
**Starting from RocketMQ 5.3.3, ACL 1.0 has been removed and is no longer
supported.**
-If you are using **RocketMQ 5.3.0** or above, it is strongly recommended to
use [ACL 2.0 Documentation](03access.md), which provides more powerful and
flexible access control features.
+If you are using **RocketMQ 5.3.0** or above, it is strongly recommended to
use [ACL 2.0 Documentation](06access.md), which provides more powerful and
flexible access control features.
:::
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/09-streams/01RocketMQ
Streams Overview.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/09-streams/01RocketMQStreamsOverview.md
similarity index 100%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/09-streams/01RocketMQ
Streams Overview.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/09-streams/01RocketMQStreamsOverview.md
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/09-streams/02RocketMQ
Streams Concept.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/09-streams/02RocketMQStreamsConcept.md
similarity index 100%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/09-streams/02RocketMQ
Streams Concept.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/09-streams/02RocketMQStreamsConcept.md
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/09-streams/03RocketMQ
Streams Quick Start.md
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/09-streams/03RocketMQStreamsQuickStart.md
similarity index 100%
rename from
i18n/en/docusaurus-plugin-content-docs/version-5.0/09-streams/03RocketMQ
Streams Quick Start.md
rename to
i18n/en/docusaurus-plugin-content-docs/version-5.0/09-streams/03RocketMQStreamsQuickStart.md
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_domain_model.png
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_domain_model.png
new file mode 100644
index 0000000000..6eef3e8d66
Binary files /dev/null and
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_domain_model.png
differ
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_multiagent.png
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_multiagent.png
new file mode 100644
index 0000000000..0b02f2e010
Binary files /dev/null and
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_multiagent.png
differ
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_multiagent_practice.png
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_multiagent_practice.png
new file mode 100644
index 0000000000..0b02f2e010
Binary files /dev/null and
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_multiagent_practice.png
differ
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_multiagent_practice.svg
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_multiagent_practice.svg
new file mode 100644
index 0000000000..a2ed562552
--- /dev/null
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_multiagent_practice.svg
@@ -0,0 +1,3 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";>
+<svg xmlns="http://www.w3.org/2000/svg";
xmlns:xlink="http://www.w3.org/1999/xlink"; version="1.1" width="962px"
height="582px" viewBox="-0.5 -0.5 962 582"><defs /><g><rect x="0" y="200"
width="120" height="160" fill="#ffffff" stroke="#d9d9d9" pointer-events="all"
/><rect x="160" y="0" width="800.01" height="580.01" fill="#f0f0f0"
stroke="none" pointer-events="all" /><rect x="160" y="10" width="40"
height="20" fill="none" stroke="none" pointer-events="all" /><g
transform="translate(-0.5 -0 [...]
\ No newline at end of file
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_ratelimit_practice.svg
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_ratelimit_practice.svg
new file mode 100644
index 0000000000..73f8f7b86d
--- /dev/null
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_ratelimit_practice.svg
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Do not edit this file with editors other than draw.io -->
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";>
+<svg xmlns="http://www.w3.org/2000/svg"; style="background: transparent;
background-color: transparent; color-scheme: light dark;"
xmlns:xlink="http://www.w3.org/1999/xlink"; version="1.1" width="1344px"
height="451px" viewBox="-0.5 -0.5 1344 451" content="<mxfile
host="Electron" agent="Mozilla/5.0 (Macintosh; Intel Mac OS X
10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/27.0.9
Chrome/134.0.6998.205 Electron/35.4.0 Safari/537.36"
version="27.0.9"&g [...]
\ No newline at end of file
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_session.png
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_session.png
new file mode 100644
index 0000000000..0b02f2e010
Binary files /dev/null and
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_session.png
differ
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_session_practice.png
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_session_practice.png
new file mode 100644
index 0000000000..0b02f2e010
Binary files /dev/null and
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_session_practice.png
differ
diff --git
a/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_session_practice.svg
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_session_practice.svg
new file mode 100644
index 0000000000..82a102af86
--- /dev/null
+++
b/i18n/en/docusaurus-plugin-content-docs/version-5.0/picture/v5/litetopic_session_practice.svg
@@ -0,0 +1,3 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";>
+<svg xmlns="http://www.w3.org/2000/svg";
xmlns:xlink="http://www.w3.org/1999/xlink"; version="1.1" width="1066px"
height="403px" viewBox="-0.5 -0.5 1066 403"><defs /><g><rect x="577.01" y="0"
width="150" height="400" fill="rgb(255, 255, 255)" stroke="#d9d9d9"
pointer-events="all" /><rect x="584.51" y="20.88" width="135" height="20"
fill="none" stroke="none" pointer-events="all" /><g transform="translate(-0.5
-0.5)scale(1.00001)"><switch><foreignObject pointer-events="none" width="100%"
hei [...]
\ No newline at end of file
diff --git a/versioned_docs/version-5.0/01-introduction/02concepts.md
b/versioned_docs/version-5.0/01-introduction/02concepts.md
index 59ab60928b..5390a31c01 100644
--- a/versioned_docs/version-5.0/01-introduction/02concepts.md
+++ b/versioned_docs/version-5.0/01-introduction/02concepts.md
@@ -15,10 +15,10 @@ Apache RocketMQ 从5.0版本开始，支持强制校验消息类型，即每个
:::
## 消息队列（MessageQueue）
-队列是 Apache RocketMQ 中消息存储和传输的实际容器，也是消息的最小存储单元。 Apache RocketMQ
的所有主题都是由多个队列组成，以此实现队列数量的水平拆分和队列内部的流式存储。队列通过QueueId来做唯一标识和区分。更多信息，请参见[队列（MessageQueue）](../03-domainModel/03messagequeue.md)。
+队列是 Apache RocketMQ 中消息存储和传输的实际容器，也是消息的最小存储单元。 Apache RocketMQ
的所有主题都是由多个队列组成，以此实现队列数量的水平拆分和队列内部的流式存储。队列通过QueueId来做唯一标识和区分。更多信息，请参见[队列（MessageQueue）](../03-domainModel/04messagequeue.md)。
## 消息（Message）
-消息是 Apache RocketMQ
中的最小数据传输单元。生产者将业务数据的负载和拓展属性包装成消息发送到服务端，服务端按照相关语义将消息投递到消费端进行消费。更多信息，请参见[消息（Message）](../03-domainModel/04message.md)。
+消息是 Apache RocketMQ
中的最小数据传输单元。生产者将业务数据的负载和拓展属性包装成消息发送到服务端，服务端按照相关语义将消息投递到消费端进行消费。更多信息，请参见[消息（Message）](../03-domainModel/05message.md)。
## 消息视图（MessageView）
消息视图是 Apache RocketMQ
面向开发视角提供的一种消息只读接口。通过消息视图可以读取消息内部的多个属性和负载信息，但是不能对消息本身做任何修改。
@@ -36,7 +36,7 @@ Apache RocketMQ 从5.0版本开始，支持强制校验消息类型，即每个
消息索引是Apache RocketMQ 提供的面向消息的索引属性。通过设置的消息索引可以快速查找到对应的消息内容。
## 生产者（Producer）
-生产者是Apache RocketMQ
系统中用来构建并传输消息到服务端的运行实体。生产者通常被集成在业务系统中，将业务消息按照要求封装成消息并发送至服务端。更多信息，请参见[生产者（Producer）](../03-domainModel/04producer.md)。
+生产者是Apache RocketMQ
系统中用来构建并传输消息到服务端的运行实体。生产者通常被集成在业务系统中，将业务消息按照要求封装成消息并发送至服务端。更多信息，请参见[生产者（Producer）](../03-domainModel/05producer.md)。
## 事务检查器（TransactionChecker）
Apache RocketMQ
中生产者用来执行本地事务检查和异常事务恢复的监听器。事务检查器应该通过业务侧数据的状态来检查和判断事务消息的状态。更多信息，请参见[事务消息](../04-featureBehavior/04transactionmessage.md)。
@@ -45,16 +45,16 @@ Apache RocketMQ 中生产者用来执行本地事务检查和异常事务恢复
Apache RocketMQ
中事务消息发送过程中，事务提交的状态标识，服务端通过事务状态控制事务消息是否应该提交和投递。事务状态包括事务提交、事务回滚和事务未决。更多信息，请参见[事务消息](../04-featureBehavior/04transactionmessage.md)。
## 消费者分组（ConsumerGroup）
-消费者分组是Apache RocketMQ 系统中承载多个消费行为一致的消费者的负载均衡分组。和消费者不同，消费者分组并不是运行实体，而是一个逻辑资源。在
Apache RocketMQ
中，通过消费者分组内初始化多个消费者实现消费性能的水平扩展以及高可用容灾。更多信息，请参见[消费者分组（ConsumerGroup）](../03-domainModel/07consumergroup.md)。
+消费者分组是Apache RocketMQ 系统中承载多个消费行为一致的消费者的负载均衡分组。和消费者不同，消费者分组并不是运行实体，而是一个逻辑资源。在
Apache RocketMQ
中，通过消费者分组内初始化多个消费者实现消费性能的水平扩展以及高可用容灾。更多信息，请参见[消费者分组（ConsumerGroup）](../03-domainModel/08consumergroup.md)。
## 消费者（Consumer）
-消费者是Apache RocketMQ
中用来接收并处理消息的运行实体。消费者通常被集成在业务系统中，从服务端获取消息，并将消息转化成业务可理解的信息，供业务逻辑处理。更多信息，请参见[消费者（Consumer）](../03-domainModel/08consumer.md)。
+消费者是Apache RocketMQ
中用来接收并处理消息的运行实体。消费者通常被集成在业务系统中，从服务端获取消息，并将消息转化成业务可理解的信息，供业务逻辑处理。更多信息，请参见[消费者（Consumer）](../03-domainModel/09consumer.md)。
## 消费结果（ConsumeResult）
Apache RocketMQ
中PushConsumer消费监听器处理消息完成后返回的处理结果，用来标识本次消息是否正确处理。消费结果包含消费成功和消费失败。
## 订阅关系（Subscription）
-订阅关系是Apache RocketMQ
系统中消费者获取消息、处理消息的规则和状态配置。订阅关系由消费者分组动态注册到服务端系统，并在后续的消息传输中按照订阅关系定义的过滤规则进行消息匹配和消费进度维护。更多信息，请参见[订阅关系（Subscription）](../03-domainModel/09subscription.md)。
+订阅关系是Apache RocketMQ
系统中消费者获取消息、处理消息的规则和状态配置。订阅关系由消费者分组动态注册到服务端系统，并在后续的消息传输中按照订阅关系定义的过滤规则进行消息匹配和消费进度维护。更多信息，请参见[订阅关系（Subscription）](../03-domainModel/10subscription.md)。
## 消息过滤
消费者可以通过订阅指定消息标签（Tag）对消息进行过滤，确保最终只接收被过滤后的消息合集。过滤规则的计算和匹配在Apache RocketMQ
diff --git a/versioned_docs/version-5.0/03-domainModel/01main.md
b/versioned_docs/version-5.0/03-domainModel/01main.md
index 4ca751f193..044dc8a21a 100644
--- a/versioned_docs/version-5.0/03-domainModel/01main.md
+++ b/versioned_docs/version-5.0/03-domainModel/01main.md
@@ -15,7 +15,7 @@ Apache RocketMQ 产品具备异步通信的优势，系统拓扑简单、上下
**消息生产**
-[生产者（Producer）](../03-domainModel/04producer.md)：
+[生产者（Producer）](../03-domainModel/05producer.md)：
Apache RocketMQ 中用于产生消息的运行实体，一般集成于业务调用链路的上游。生产者是轻量级匿名无身份的。
@@ -25,11 +25,11 @@ Apache RocketMQ 中用于产生消息的运行实体，一般集成于业务调
Apache RocketMQ 消息传输和存储的分组容器，主题内部由多个队列组成，消息的存储和水平扩展实际是通过主题内的队列实现的。
-* [队列（MessageQueue）](../03-domainModel/03messagequeue.md)：
+* [队列（MessageQueue）](../03-domainModel/04messagequeue.md)：
Apache RocketMQ 消息传输和存储的实际单元容器，类比于其他消息队列中的分区。 Apache RocketMQ
通过流式特性的无限队列结构来存储消息，消息在队列内具备顺序性存储特征。
-* [消息（Message）](../03-domainModel/04message.md)：
+* [消息（Message）](../03-domainModel/05message.md)：
Apache RocketMQ 的最小传输单元。消息具备不可变性，在初始化发送和完成存储后即不可变。
@@ -38,15 +38,15 @@ Apache RocketMQ 中用于产生消息的运行实体，一般集成于业务调
**消息消费**
-* [消费者分组（ConsumerGroup）](../03-domainModel/07consumergroup.md)：
+* [消费者分组（ConsumerGroup）](../03-domainModel/08consumergroup.md)：
Apache RocketMQ
发布订阅模型中定义的独立的消费身份分组，用于统一管理底层运行的多个消费者（Consumer）。同一个消费组的多个消费者必须保持消费逻辑和配置一致，共同分担该消费组订阅的消息，实现消费能力的水平扩展。
-* [消费者（Consumer）](../03-domainModel/08consumer.md)：
+* [消费者（Consumer）](../03-domainModel/09consumer.md)：
Apache RocketMQ 消费消息的运行实体，一般集成在业务调用链路的下游。消费者必须被指定到某一个消费组中。
-* [订阅关系（Subscription）](../03-domainModel/09subscription.md)：
+* [订阅关系（Subscription）](../03-domainModel/10subscription.md)：
Apache RocketMQ
发布订阅模型中消息过滤、重试、消费进度的规则配置。订阅关系以消费组粒度进行管理，消费组通过定义订阅关系控制指定消费组下的消费者如何实现消息过滤、消费重试及消费进度恢复等。
diff --git a/versioned_docs/version-5.0/03-domainModel/02topic.md
b/versioned_docs/version-5.0/03-domainModel/02topic.md
index bda530572a..1d0f302aa9 100644
--- a/versioned_docs/version-5.0/03-domainModel/02topic.md
+++ b/versioned_docs/version-5.0/03-domainModel/02topic.md
@@ -37,7 +37,7 @@
**队列列表**
-*
定义：队列作为主题的组成单元，是消息存储的实际容器，一个主题内包含一个或多个队列，消息实际存储在主题的各队列内。更多信息，请参见[队列（MessageQueue）](../03-domainModel/03messagequeue.md)。
+*
定义：队列作为主题的组成单元，是消息存储的实际容器，一个主题内包含一个或多个队列，消息实际存储在主题的各队列内。更多信息，请参见[队列（MessageQueue）](../03-domainModel/04messagequeue.md)。
* 取值：系统根据队列数量给主题分配队列，队列数量创建主题时定义。
diff --git a/versioned_docs/version-5.0/03-domainModel/03litetopic.md
b/versioned_docs/version-5.0/03-domainModel/03litetopic.md
new file mode 100644
index 0000000000..f9bb79f489
--- /dev/null
+++ b/versioned_docs/version-5.0/03-domainModel/03litetopic.md
@@ -0,0 +1,70 @@
+# 轻量主题（LiteTopic）
+
+本文介绍Apache RocketMQ中轻量主题（LiteTopic）的定义、模型关系、内部属性、行为约束、版本兼容性及使用建议。
+
+## 定义
+
+轻量主题是Apache RocketMQ中消息传输和存储的二级容器，用于标识同一类业务逻辑下不同子类（例如不同会话、任务等粒度）的消息。
+
+轻量主题的作用主要如下：
+
+* 实现排他性消费，定义数据的二级隔离
+
+ 建议将不同子类的数据拆分到不同的轻量主题中管理，通过轻量主题实现更细致的存储隔离性和订阅隔离性。
+
+* 定义数据的身份和权限
+
+ 在基于主题的身份识别和权限管理基础上，可以通过轻量主题，进一步细分用户的身份与权限。
+
+## 模型关系
+
+在整个Apache RocketMQ的领域模型中，轻量主题所处的流程和位置如下：
+
+
+
+* 主题（Topic）是Apache
RocketMQ中消息传输和存储的顶层容器。当类型为Lite类型时，Topic下可创建轻量主题（LiteTopic），由Topic和LiteTopic共同唯一确认消息的存储容器。
+
+* 当类型为Lite类型时，每个存储容器默认由一个队列组成。
+
+## 内部属性
+
+### 轻量主题名称
+
+* 定义：轻量主题的名称，用于标识轻量主题，轻量主题名称在所属主题内全局唯一。
+
+* 取值：当主题类型为Lite时，用户对message进行了setLiteTopic，如对应的轻量主题不存在，系统会自动创建。
+
+* 约束：请参见[参数限制](../01-introduction/03limits.md)。
+
+### 过期时间
+
+* 定义：轻量主题的过期时间，当轻量主题距离最近一次消息写入时间超过过期时间后，该轻量主题会被自动删除。删除是指释放轻量主题占用的个数，即占用总数-1。
+
+* 取值：当创建主题类型为Lite时，可以设置过期时间 expiration 值。
+
+* 约束：请参见[参数限制](../01-introduction/03limits.md)。
+
+## 版本兼容性
+
+* 服务端版本：5.5.0 版本及以上
+
+* 客户端版本：RocketMQ gRPC 5.1.0 版本及以上
+
+## 轻量类型和普通类型主题的差异
+
+| **场景** | **对比项** | **轻量类型主题** | **普通类型主题** |
+|--------|--------|------------|------------|
+| 消息存储 | 一级主题 | 相同。都需要预先创建主题资源。 | 相同。都需要预先创建主题资源。 |
+| 消息存储 | 二级主题 | 可以在Topic下创建百万量级的二级主题资源LiteTopic，该二级资源有许多新特性。 | 无二级主题资源。 |
+| 消息存储 | 自动化生命周期管理 |
二级主题LiteTopic的生命周期可以自动化管理：自动创建（发送或订阅时如不存在则自动创建）；自动删除（设置expiration时间，持续无新消息发送后会自动删除）。
| 无 |
+| 消息存储 | 顺序性 | 每个LiteTopic只创建一个队列，同一个队列中的消息存储是顺序的。 | 会创建多个队列，只有分区顺序Topic |
+| 消息存储 | 收发并发TPS上限 |
由于只有一个队列，每个LiteTopic的TPS上限是有限的。但Topic下可以创建百万量级的LiteTopic，总TPS的上限是可以根据LiteTopic的增加而增加。
| Topic的TPS可以根据队列数量和集群机器节点数量横向扩容。 |
+| 消息消费 | 订阅关系一致性 | 可以不一致。同一Group下，每个消费者可订阅不同的LiteTopic集合，Group的限制弱化。 |
需要一致。同一Group下，每个消费者的订阅关系需要保持一致，共享目标主题下的消息。 |
+| 消息消费 | 顺序性 | 顺序消费，一个LiteTopic下的消息只能被一个消费者线程处理。 | 可选择并发消费或顺序消费。 |
+| 消息消费 | 动态订阅 | 每个消费者可以动态增加或删除指定某个LiteTopic的订阅 | 无 |
+| 消息消费 | 单个消费者可以订阅的LiteTopic的数量 | 每个消费者可以订阅千量级的LiteTopic | 无 |
+| 可观测 | Metrics指标数据 | 有消息堆积量指标，无消息处理滞后时间指标 | 有消息堆积量指标，有消息处理滞后时间指标 |
+| 可观测 | 消息轨迹 | 相同 | 相同 |
+
+
+
diff --git a/versioned_docs/version-5.0/03-domainModel/03messagequeue.md
b/versioned_docs/version-5.0/03-domainModel/04messagequeue.md
similarity index 100%
rename from versioned_docs/version-5.0/03-domainModel/03messagequeue.md
rename to versioned_docs/version-5.0/03-domainModel/04messagequeue.md
diff --git a/versioned_docs/version-5.0/03-domainModel/04message.md
b/versioned_docs/version-5.0/03-domainModel/05message.md
similarity index 99%
rename from versioned_docs/version-5.0/03-domainModel/04message.md
rename to versioned_docs/version-5.0/03-domainModel/05message.md
index 6ea68d9988..de5d664d53 100644
--- a/versioned_docs/version-5.0/03-domainModel/04message.md
+++ b/versioned_docs/version-5.0/03-domainModel/05message.md
@@ -70,7 +70,7 @@ Apache RocketMQ 的消息模型具备如下特点：
**消息队列**
-* 定义：实际存储当前消息的队列。更多信息，请参见[队列（MessageQueue）](./03messagequeue.md)。
+* 定义：实际存储当前消息的队列。更多信息，请参见[队列（MessageQueue）](./04messagequeue.md)。
* 取值：由服务端指定并填充。
diff --git a/versioned_docs/version-5.0/03-domainModel/04producer.md
b/versioned_docs/version-5.0/03-domainModel/05producer.md
similarity index 98%
rename from versioned_docs/version-5.0/03-domainModel/04producer.md
rename to versioned_docs/version-5.0/03-domainModel/05producer.md
index 67d3bfc089..dd2febe98d 100644
--- a/versioned_docs/version-5.0/03-domainModel/04producer.md
+++ b/versioned_docs/version-5.0/03-domainModel/05producer.md
@@ -6,7 +6,7 @@
生产者是 Apache RocketMQ 系统中用来构建并传输消息到服务端的运行实体。
-生产者通常被集成在业务系统中，将业务消息按照要求封装成 Apache RocketMQ
的[消息（Message）](./04message.md)并发送至服务端。
+生产者通常被集成在业务系统中，将业务消息按照要求封装成 Apache RocketMQ
的[消息（Message）](./05message.md)并发送至服务端。
在消息生产者中，可以定义如下传输行为：
diff --git a/versioned_docs/version-5.0/03-domainModel/07consumergroup.md
b/versioned_docs/version-5.0/03-domainModel/08consumergroup.md
similarity index 98%
rename from versioned_docs/version-5.0/03-domainModel/07consumergroup.md
rename to versioned_docs/version-5.0/03-domainModel/08consumergroup.md
index 1888b3ba6b..d777882530 100644
--- a/versioned_docs/version-5.0/03-domainModel/07consumergroup.md
+++ b/versioned_docs/version-5.0/03-domainModel/08consumergroup.md
@@ -11,7 +11,7 @@
在消费者分组中，统一定义以下消费行为，同一分组下的多个消费者将按照分组内统一的消费行为和负载均衡策略消费消息。
-* 订阅关系：Apache RocketMQ
以消费者分组的粒度管理订阅关系，实现订阅关系的管理和追溯。具体信息，请参见[订阅关系（Subscription）](./09subscription.md)。
+* 订阅关系：Apache RocketMQ
以消费者分组的粒度管理订阅关系，实现订阅关系的管理和追溯。具体信息，请参见[订阅关系（Subscription）](./10subscription.md)。
* 投递顺序性：Apache RocketMQ
的服务端将消息投递给消费者消费时，支持顺序投递和并发投递，投递方式在消费者分组中统一配置。具体信息，请参见[顺序消息](../04-featureBehavior/03fifomessage.md)。
@@ -72,7 +72,7 @@
**订阅关系**
-* 定义：当前消费者分组关联的订阅关系集合。包括消费者订阅的主题，以及消息的过滤规则等。订阅关系由消费者动态注册到消费者分组中，Apache
RocketMQ
服务端会持久化订阅关系并匹配消息的消费进度。更多信息，请参见[订阅关系（Subscription）](./09subscription.md)。
+* 定义：当前消费者分组关联的订阅关系集合。包括消费者订阅的主题，以及消息的过滤规则等。订阅关系由消费者动态注册到消费者分组中，Apache
RocketMQ
服务端会持久化订阅关系并匹配消息的消费进度。更多信息，请参见[订阅关系（Subscription）](./10subscription.md)。
## 行为约束
diff --git a/versioned_docs/version-5.0/03-domainModel/08consumer.md
b/versioned_docs/version-5.0/03-domainModel/09consumer.md
similarity index 99%
rename from versioned_docs/version-5.0/03-domainModel/08consumer.md
rename to versioned_docs/version-5.0/03-domainModel/09consumer.md
index ba3f6060b5..fe3b57f61a 100644
--- a/versioned_docs/version-5.0/03-domainModel/08consumer.md
+++ b/versioned_docs/version-5.0/03-domainModel/09consumer.md
@@ -36,7 +36,7 @@
**消费者分组名称**
-*
定义：当前消费者关联的消费者分组名称，消费者必须关联到指定的消费者分组，通过消费者分组获取消费行为。更多信息，请参见[消费者分组（ConsumerGroup）](./07consumergroup.md)。
+*
定义：当前消费者关联的消费者分组名称，消费者必须关联到指定的消费者分组，通过消费者分组获取消费行为。更多信息，请参见[消费者分组（ConsumerGroup）](./08consumergroup.md)。
* 取值：消费者分组为Apache RocketMQ
的逻辑资源，需要您提前通过控制台或OpenAPI创建。具体命名格式，请参见[使用限制](../01-introduction/03limits.md)。
diff --git a/versioned_docs/version-5.0/03-domainModel/09subscription.md
b/versioned_docs/version-5.0/03-domainModel/10subscription.md
similarity index 100%
rename from versioned_docs/version-5.0/03-domainModel/09subscription.md
rename to versioned_docs/version-5.0/03-domainModel/10subscription.md
diff --git a/versioned_docs/version-5.0/04-featureBehavior/07messagefilter.md
b/versioned_docs/version-5.0/04-featureBehavior/07messagefilter.md
index d7b42fe6fa..70a9f8f65c 100644
--- a/versioned_docs/version-5.0/04-featureBehavior/07messagefilter.md
+++ b/versioned_docs/version-5.0/04-featureBehavior/07messagefilter.md
@@ -45,7 +45,7 @@ Apache RocketMQ 支持Tag标签过滤和SQL属性过滤，这两种过滤方式
## 订阅关系一致性
-过滤表达式属于订阅关系的一部分，Apache RocketMQ
的领域模型规定，同一消费者分组内的多个消费者的订阅关系包括过滤表达式，必须保持一致，否则可能会导致部分消息消费不到。更多信息，请参见[订阅关系（Subscription）](../03-domainModel/09subscription.md)。
+过滤表达式属于订阅关系的一部分，Apache RocketMQ
的领域模型规定，同一消费者分组内的多个消费者的订阅关系包括过滤表达式，必须保持一致，否则可能会导致部分消息消费不到。更多信息，请参见[订阅关系（Subscription）](../03-domainModel/10subscription.md)。
## Tag标签过滤
diff --git
a/versioned_docs/version-5.0/04-featureBehavior/09consumerprogress.md
b/versioned_docs/version-5.0/04-featureBehavior/09consumerprogress.md
index 80dfb99d62..bae4a767af 100644
--- a/versioned_docs/version-5.0/04-featureBehavior/09consumerprogress.md
+++ b/versioned_docs/version-5.0/04-featureBehavior/09consumerprogress.md
@@ -21,7 +21,7 @@ Apache RocketMQ 的生产者和消费者在进行消息收发时，必然会涉
**消息位点（Offset）**
-参考 Apache RocketMQ
[主题](../03-domainModel/02topic.md)和[队列](../03-domainModel/03messagequeue.md)的定义，消息是按到达服务端的先后顺序存储在指定主题的多个队列中，每条消息在队列中都有一个唯一的Long类型坐标，这个坐标被定义为消息位点。
+参考 Apache RocketMQ
[主题](../03-domainModel/02topic.md)和[队列](../03-domainModel/04messagequeue.md)的定义，消息是按到达服务端的先后顺序存储在指定主题的多个队列中，每条消息在队列中都有一个唯一的Long类型坐标，这个坐标被定义为消息位点。
任意一个消息队列在逻辑上都是无限存储，即消息位点会从0到Long.MAX无限增加。通过主题、队列和位点就可以定位任意一条消息的位置，具体关系如下图所示：
diff --git
a/versioned_docs/version-5.0/04-featureBehavior/10consumerretrypolicy.md
b/versioned_docs/version-5.0/04-featureBehavior/10consumerretrypolicy.md
index 2674bd298c..c0d2b09a2b 100644
--- a/versioned_docs/version-5.0/04-featureBehavior/10consumerretrypolicy.md
+++ b/versioned_docs/version-5.0/04-featureBehavior/10consumerretrypolicy.md
@@ -87,7 +87,7 @@ PushConsumer消费消息时，消息的几个主要状态如下：。
+PushConsumer的最大重试次数由消费者分组创建时的元数据控制，具体参数，请参见[消费者分组](../03-domainModel/08consumergroup.md)。
例如，最大重试次数为3次，则该消息最多可被投递4次，1次为原始消息，3次为重试投递次数。
@@ -163,7 +163,7 @@ SimpleConsumer消费消息时，消息的几个主要状态如下：。
+SimpleConsumer的最大重试次数由消费者分组创建时的元数据控制，具体参数，请参见[消费者分组](../03-domainModel/08consumergroup.md)。
**消息重试间隔**
diff --git
a/versioned_docs/version-5.0/04-featureBehavior/11messagestorepolicy.md
b/versioned_docs/version-5.0/04-featureBehavior/11messagestorepolicy.md
index f55a339171..c0e290196e 100644
--- a/versioned_docs/version-5.0/04-featureBehavior/11messagestorepolicy.md
+++ b/versioned_docs/version-5.0/04-featureBehavior/11messagestorepolicy.md
@@ -4,7 +4,7 @@
## 背景信息
-参考 Apache RocketMQ
中[队列](../03-domainModel/03messagequeue.md)的定义，消息按照达到服务器的先后顺序被存储到队列中，理论上每个队列都支持无限存储。
+参考 Apache RocketMQ
中[队列](../03-domainModel/04messagequeue.md)的定义，消息按照达到服务器的先后顺序被存储到队列中，理论上每个队列都支持无限存储。
但是在实际部署场景中，服务端节点的物理存储空间有限，消息无法做到永久存储。因此，在实际使用中需要考虑以下问题，消息在服务端中的存储以什么维度为判定条件？消息存储以什么粒度进行管理？消息存储超过限制后如何处理？这些问题都是由消息存储和过期清理机制来定义的。
diff --git a/versioned_docs/version-5.0/06-bestPractice/02ratelimit.md
b/versioned_docs/version-5.0/06-bestPractice/02ratelimit.md
new file mode 100644
index 0000000000..6147022f38
--- /dev/null
+++ b/versioned_docs/version-5.0/06-bestPractice/02ratelimit.md
@@ -0,0 +1,217 @@
+# 基于 RocketMQ LiteTopic 实现任务细粒度隔离和限流
+
+本文档详细介绍了如何利用 Apache RocketMQ 的 **LiteTopic** 特性，构建一套通用的、支持海量任务细粒度隔离和限流动态管理系统。
+
+## 背景与挑战
+在 AI 推理和业务处理场景中（如图片生成、视频渲染、大规模计算等），后端服务通常依赖 GPU
等高成本计算资源。作为平台服务提供方，在算力资源有限的前提下，需要优先保障重要用户或关键任务类型的服务质量。
+
+在确保高优算力资源合理分配的同时，平台还需应对以下典型挑战：
+
++ **资源隔离**：重要客户或关键任务的请求需独占处理资源池，避免与其他流量混用。
++ **流量互不干扰**：同等优先级的客户之间应相互隔离，防止单一客户的突发流量挤占资源，导致其他客户的请求长期排队。
++ **动态订阅管理**：用户 ID 列表或任务类型列表实时变化，下游消费者需动态调整订阅关系，新增或移除订阅目标。
++ **细粒度限流**：当某一类型或某一用户的请求量超过最大处理能力时，需针对该维度单独暂停消费，进行退避处理，而不影响其他维度。
++ **集群级流量治理**：当集群整体处理能力达到上限时，需识别并暂停 Top 流量队列的消费，待集群完成扩缩容后再逐步恢复。
++ **削峰填谷**：平滑波动较大的请求流量，保障后端服务的稳定性和可用性。
+
+### 传统方案的局限性
+#### 方案一：基于 RocketMQ 普通 Topic 隔离
+为每个用户 ID 或任务类型创建独立的 Topic 和 ConsumerGroup，并为每个 ConsumerGroup
启动对应的消费者实例。该方案存在以下问题：
+
++ Topic 和 ConsumerGroup 属于重资源，创建后生产者和消费者需完成连接初始化等资源准备，影响消息发送和消费的平滑性。
++ 下游消费者需主动感知上游生产者侧用户或任务类型列表的变化，动态增删订阅关系，无法实现真正的生产者与消费者解耦。
+
+#### 方案二：基于 Kafka 隔离
+Kafka 与 RocketMQ 普通 Topic 方案面临相同的重资源问题。若尝试通过 Kafka Topic 的 Partition
来映射不同用户或任务类型，单个 Topic 分区数过多会导致 Broker 资源消耗和性能开销急剧上升，引入稳定性风险。
+
+## 解决方案
+### 核心架构：基于LiteTopic的细粒度隔离和限流
+
+
+
+本文采用 Apache RocketMQ 的 **LiteTopic（轻量级主题）** 特性，构建了一套全新的细粒度隔离与动态限流架构：
+
++ **消息发送端**：根据业务维度（如用户 ID、模型 ID、任务类型）将消息路由至对应的 LiteTopic。
++ **消息消费端**：消费者统一订阅父 Topic（即所有 LiteTopic），当 LiteTopic
动态新增或移除时，消费者无需调整订阅关系，只要消费集群容量充足即可持续工作。
+
+### LiteTopic 的核心优势
++ **轻量级与海量支持**：单个实例内可支持百万级 LiteTopic，可为每个用户或任务类型创建专属的轻量级队列，满足大规模细粒度隔离需求。
++ **资源解耦与高效复用**：LiteTopic 无需预先创建，消息写入时按需自动生成，不影响发送耗时；空闲后按内置 TTL
策略自动清理，实现全自动化生命周期管理。
++ **精准流控能力**：消费端支持返回 Suspend 状态，可精确挂起指定 LiteTopic 暂停消费，实现毫秒级精细化限流，且仅影响目标
LiteTopic，不干扰其他队列的正常消费。
++ **物理隔离与逻辑统一**：每个用户或业务维度拥有独立的 LiteTopic，实现数据层面的隔离；同时所有消费实例归属同一
ConsumerGroup，共享线程池等资源，兼顾隔离性与资源利用率。
+
+## 操作步骤
+### 步骤一：创建父 Topic
+在 Apache RocketMQ 控制台或通过 API 创建一个父 Topic，用于承载所有 LiteTopic。所有限流对象共享同一个父
Topic，无需为每个用户单独创建。
+
+示例配置：
+
++ Topic 名称：`rate-limit-parent-topic`
++ 消息类型：普通消息
+
+> **说明**：父 Topic 是 LiteTopic 的载体，一个父 Topic 下可承载百万级 LiteTopic。
+
+### 步骤二：创建 Consumer Group
+创建一个统一的 Consumer Group，所有消费机器共用该 Group。
+
+示例配置：
+
++ Group 名称：`GID_rate_limit_consumer`
++ 消费模式：**集群消费**
+
+### 步骤三：发送消息到 LiteTopic
+在消息发送端，根据用户标识将消息写入对应的 LiteTopic。LiteTopic 无需预先创建，首次发送时自动生成。
+
+```java
+// 父 Topic 名称
+String topic = "rate-limit-parent-topic";
+
+// 获取 Producer 实例
+final Producer producer = ProducerSingleton.getInstance(topic);
+
+// 构造消息体
+byte[] body = "your message content".getBytes(StandardCharsets.UTF_8);
+
+// 以用户标识作为 LiteTopic 名称，实现按用户隔离
+String userId = "user_10086";
+
+final Message message = provider.newMessageBuilder()
+ // 设置父 Topic
+ .setTopic(topic)
+ // 设置 LiteTopic，按用户维度隔离
+ .setLiteTopic(userId)
+ .setBody(body)
+ .build();
+
+try {
+ final SendReceipt sendReceipt = producer.send(message);
+ log.info("Message sent successfully, messageId={}",
sendReceipt.getMessageId());
+} catch (LiteTopicQuotaExceededException e) {
+ // LiteTopic 数量超过实例配额限制
+ log.error("LiteTopic quota exceeded, please upgrade instance", e);
+} catch (Throwable t) {
+ log.error("Failed to send message", t);
+}
+```
+
+**关键说明**：
+
++ `setLiteTopic()` 的参数为 LiteTopic 名称，建议使用用户 ID、任务类型 ID 等业务标识，便于后续限流策略匹配。
++ 当 LiteTopic 首次被写入消息时，系统自动创建该队列，无需额外操作。
++ 若 LiteTopic 数量超过实例配额，将抛出 `LiteTopicQuotaExceededException`，此时需升级实例规格。
+
+### 步骤四：消费消息并实施限流
+消费端使用 `LitePushConsumer` 订阅父 Topic 下的全部 LiteTopic，并在消息处理逻辑中根据业务限流策略进行流控。
+
+```java
+String consumerGroup = "GID_rate_limit_consumer";
+String topic = "rate-limit-parent-topic";
+
+// 构建 LitePushConsumer 实例
+LitePushConsumer litePushConsumer = provider.newLitePushConsumerBuilder()
+ .setClientConfiguration(clientConfiguration)
+ // 设置消费者组
+ .setConsumerGroup(consumerGroup)
+ // 绑定父 Topic
+ .bindTopic(topic)
+ // 设置消息监听器
+ .setMessageListener(messageView -> {
+ // 获取消息所属的 LiteTopic（即用户标识）
+ String liteTopic = messageView.getLiteTopic();
+
+ // 执行业务逻辑（如调用下游服务）
+ boolean success = processMessage(messageView);
+
+ if (success) {
+ // 业务处理成功
+ // 检查该用户是否需要限流
+ if (rateLimiter.shouldLimit(liteTopic)) {
+ // 返回 Suspend，暂停该 LiteTopic 的拉取
+ // 参数为暂停时长，期间不会拉取该 LiteTopic 的新消息
+ return ConsumeResult.Suspend(Duration.ofMillis(500));
+ }
+ return ConsumeResult.SUCCESS;
+ } else {
+ // 业务处理失败，消息将被重试
+ return ConsumeResult.FAILURE;
+ }
+ })
+ .build();
+```
+
+**关键说明**：
+
++ `ConsumeResult.Suspend(Duration)` 是 LiteTopic 提供的核心限流机制：返回该结果后，Broker
将在指定时间内暂停对该 LiteTopic 的消息拉取，但不影响其他 LiteTopic 的正常消费。
++ 限流策略（`rateLimiter.shouldLimit()`）由业务侧自行实现，可基于滑动窗口、令牌桶等算法，按用户维度控制消费速率。
+
+### 步骤五：实现限流策略（参考示例）
+以下是一个基于固定窗口的限流器简化示例，按 LiteTopic（即用户）维度控制消费速率：
+
+```java
+import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
+import java.util.concurrent.atomic.AtomicInteger;
+
+public class LiteTopicRateLimiter {
+
+ // 每个 LiteTopic 的速率限制配置：key = liteTopic, value = 每秒允许的最大消费数
+ private final Map<String, Integer> rateLimitConfig;
+
+ // 固定窗口计数器
+ private final Map<String, AtomicInteger> windowCounters = new
ConcurrentHashMap<>();
+
+ /**
+ * 判断指定 LiteTopic 是否需要限流
+ * @param liteTopic LiteTopic 名称（用户标识）
+ * @return true 表示需要限流
+ */
+ public boolean shouldLimit(String liteTopic) {
+ Integer maxQps = rateLimitConfig.get(liteTopic);
+ if (maxQps == null) {
+ // 未配置限流策略，不限流
+ return false;
+ }
+
+ AtomicInteger counter = windowCounters.computeIfAbsent(
+ liteTopic, k -> new AtomicInteger(0));
+
+ return counter.incrementAndGet() > maxQps;
+ }
+
+ /**
+ * 定时重置窗口计数器（每秒执行一次）
+ */
+ @Scheduled(fixedRate = 1000)
+ public void resetWindow() {
+ windowCounters.values().forEach(c -> c.set(0));
+ }
+}
+```
+
+## 最佳实践
+### LiteTopic 命名规范
+建议使用业务语义明确的命名规则，便于运维排查和限流策略匹配。
+
++ 按用户限流：`{userId}`，例如 `user_10086`
++ 按用户 + 业务类型限流：`{userId}_{bizType}`，例如 `user_10086_premium`
++ 按任务类型限流：`{taskType}_{taskId}`，例如 `sms_task_001`
+
+### Suspend 时长选择
+Suspend 时长直接影响限流效果和消息处理延迟，建议根据业务场景合理设置：
+
++ **轻度限流**（降速但不阻塞）：50~200 毫秒
++ **中度限流**（明显降低消费速率）：200~1000 毫秒
++ **重度限流**（接近暂停消费）：1000~5000 毫秒
+
+### 与后端弹性扩容配合
+在后端服务弹性扩容场景中，建议结合 Suspend 机制实现平滑的流量增长控制：
+
+1. 流量突发初期，对超出阈值的用户返回较大的 Suspend 值（如 2000 毫秒），大幅降低消费速率。
+2. 随着后端扩容逐步完成，动态减小 Suspend 值（如从 2000 毫秒逐步降至 100 毫秒），使流量平滑增长。
+3. 扩容完成后，取消限流策略，恢复正常消费速率。
+
+该策略可使消费流量增长曲线尽可能匹配后端算力扩容曲线，最小化因扩容时间窗口导致的服务不可用问题。
+
+## 相关文档
++ [Apache RocketMQ 官方文档](https://rocketmq.apache.org/docs/)
++ [RocketMQ 5.x 客户端 SDK 接入指南](https://rocketmq.apache.org/docs/sdk/java/)
diff --git a/versioned_docs/version-5.0/06-bestPractice/03session.md
b/versioned_docs/version-5.0/06-bestPractice/03session.md
new file mode 100644
index 0000000000..b38641b4ed
--- /dev/null
+++ b/versioned_docs/version-5.0/06-bestPractice/03session.md
@@ -0,0 +1,75 @@
+# 基于 RocketMQ LiteTopic 解决分布式会话状态管理难题
+
+本文档详细介绍了如何利用Apache RocketMQ的LiteTopic特性，构建一个分布式的、高可用的会话状态管理系统。
+
+## 背景与挑战
+
+在构建现代AI应用时，开发者经常面临一个棘手的难题：如何在长连接（如WebSocket或SSE）不稳定的网络环境中保证会话的连续性。传统的会话管理方式在节点故障或网络重连时容易导致上下文丢失和算力浪费，主要体现在以下几个方面：
+
+* **长耗时与多轮次**：大语言模型（LLM）的推理过程通常需要数秒甚至更久，且用户与AI的交互往往是多轮对话，上下文依赖极强。
+
+* **高算力成本**：每一次AI任务的执行都消耗昂贵的GPU资源。如果因为网络波动导致连接中断，进而导致任务作废，将造成巨大的资源浪费。
+
+*
**长连接的不稳定性**：AI应用通常使用SSE或WebSocket等长连接技术来实时推送流式结果。然而，在实际生产环境中，网关或服务节点重启、连接超时、移动端网络切换等异常情况不可避免。
+
+**传统架构的痛点：**
在传统的单体或简单的分布式架构中，会话状态往往绑定在特定的应用服务节点上。一旦用户的长连接断开并重连到另一个节点，新的节点无法获取之前的会话状态，导致对话中断，用户体验极差。
+
+## 解决方案
+
+为了解决上述痛点，我们提出了一种基于Apache
RocketMQ的分布式会话状态管理方案。该方案利用RocketMQ的轻量级主题（LiteTopic）作为会话消息的传输通道，将应用服务节点设计为无状态，从而实现会话的高可用和连续性。
+
+### 系统架构
+
+
+
+* **应用服务端（无状态）**：应用服务可以横向扩展为多个节点（节点1、节点2...）。它们不存储会话状态，只负责处理连接和消息转发。
+
+* **RocketMQ
LiteTopic**：利用LiteTopic作为会话的"管道"。每个会话（Session）对应一个唯一的LiteTopic，命名规则建议为`chat/{sessionID}`。
+
+* **大模型任务调度组件**：负责与LLM交互，并将生成的流式数据发送到对应的LiteTopic中。
+
+### 通信流程
+
+1. **会话建立与初始连接**
+
+ 1. **用户接入**：Web端2发起请求，与应用服务端节点1建立长连接（如WebSocket）。
+
+ 2. **会话创建**：系统生成唯一的SessionID（例如Session2）。
+
+ 3.
**订阅通道**：应用服务端节点1根据SessionID，订阅RocketMQ中对应的LiteTopic（即`LiteTopic2`，命名为`chat/SessionID2`）。
+
+ 4. **任务调度**：大模型任务调度组件接收到请求后，开始调用LLM，并将LLM返回的流式数据（Token）逐条发送到`LiteTopic2`。
+
+ 5. **消息推送**：节点1接收到消息后，通过长连接实时推送给Web端2。
+
+2. **异常处理与断线重连**
+
+ 当网络波动或节点故障发生时，系统展现出强大的恢复能力：
+
+ 1. **连接中断**：假设Web端2与节点1之间的连接意外断开。此时，节点1会检测到连接关闭，并取消对`LiteTopic2`的订阅。
+
+ 2. **自动重连**：Web端2的客户端逻辑触发自动重连机制。由于负载均衡的存在，这次重连请求被分发到了应用服务端节点2。
+
+ 3. **状态接管**：
+
+ 1. 节点2接收到重连请求，解析出SessionID（Session2）。
+
+ 2. 节点2立即向RocketMQ发起订阅请求，订阅`LiteTopic2`。
+
+ 4. **消息续传**：
+
+ 1.
RocketMQ具有消息持久化和消费进度管理能力。当节点2订阅`LiteTopic2`时，它会根据LiteTopic的消费进度（Offset），从断点处继续拉取后续未消费的消息。
+
+ 2. 大模型任务调度组件继续向`LiteTopic2`发送数据，这些数据现在被节点2接收并推送给Web端2。
+
+### 方案优势
+
+* **会话连续性**：无论重连到哪个节点，都能通过订阅同一个LiteTopic无缝获取后续消息，用户无感知。
+
+* **资源保护**：由于会话状态保存在RocketMQ中，连接中断不会导致后台的大模型任务停止，避免了昂贵的算力浪费。
+
+* **弹性伸缩**：应用服务端完全无状态，可以根据流量负载随意扩缩容，无需担心会话粘滞（Session Sticky）问题。
+
+### 总结
+
+通过引入Apache
RocketMQ的LiteTopic，我们成功解决了AI应用中棘手的分布式会话管理问题。这种架构不仅实现了应用节点的无状态化，提升了系统的弹性伸缩能力，更重要的是保证了在复杂网络环境下用户体验的连续性和AI算力资源的高效利用。对于构建企业级、高可用的AI
Agent应用，这是一套经过验证的最佳实践方案。
diff --git a/versioned_docs/version-5.0/06-bestPractice/04multiagent.md
b/versioned_docs/version-5.0/06-bestPractice/04multiagent.md
new file mode 100644
index 0000000000..31ace18f49
--- /dev/null
+++ b/versioned_docs/version-5.0/06-bestPractice/04multiagent.md
@@ -0,0 +1,59 @@
+# 基于 RocketMQ LiteTopic 实现多智能体的异步通信
+
+本文档详细介绍了如何利用Apache RocketMQ实现高并发、可扩展的Multi-Agent系统。
+
+## 背景与挑战
+
+随着AI应用场景的日益复杂，单Agent架构已难以满足需求，Multi-Agent系统成为发展趋势。然而，AI任务的长耗时特性使得传统的同步调用方式面临线程阻塞和扩展性问题。本文通过实践教程的形式，展示了如何使用RocketMQ的消息队列和LiteTopic特性，构建一个异步通信的Multi-Agent系统，有效解决长耗时调用阻塞痛点，并提升系统的整体性能和可扩展性。
+
+## 解决方案
+
+### 系统架构
+
+
+
+* **Web端**：用户交互界面，向系统发起请求并接收最终结果。
+
+* **Supervisor
Agent（监管Agent）**：系统的核心调度者。它负责接收Web端的请求，将复杂任务拆解为多个子任务，并分发给相应的子Agent。同时，它也负责收集子Agent的处理结果，进行汇总后返回给Web端。
+
+* **子Agent（Worker Agent）**：负责执行具体的、专业化的子任务。每个子Agent专注于自己擅长的领域。
+
+### 通信流程
+
+整个通信流程分为请求和响应两个阶段，均通过RocketMQ进行异步解耦：
+
+1. **请求阶段**：
+
+ 1. Supervisor Agent接收到Web端的请求后，将任务进行拆解。
+
+ 2. 为每个子任务创建一个请求消息，并发送到对应的**请求主题（Request Topic）**。例如，可以为"子Agent 1"创建"Topic 1
(Request)"，为"子Agent 2"创建"Topic 2 (Request)"。
+
+ 3. 子Agent各自订阅自己负责的请求主题，一旦有新消息到达，便立即开始处理。
+
+2. **响应阶段**：
+
+ 1. Supervisor Agent在处理请求的同时，会创建一个**响应主题（Response
Topic）**，并订阅该主题。这个响应主题是一个特殊的**轻量类型的Topic**。
+
+ 2. 子 Agent 处理将每个任务的响应结果发送到Topic (Response)
的**LiteTopic**中。这个LiteTopic可以用唯一的TaskID或 SessionID 来命名，确保结果能够被正确路由。
+
+ 3. Supervisor Agent通过订阅响应主题，可以实时接收到各个子Agent返回的结果。
+
+ 4. 最后，Supervisor Agent将所有子任务的结果进行汇总，并通过 HTTP 协议实时推送给Web端，实现流式响应。
+
+## 关键技术：RocketMQ LiteTopic
+
+在本方案中，RocketMQ的**LiteTopic**特性扮演了至关重要的角色。
+
+传统的消息队列主题（Topic）在创建和管理上可能涉及较多的资源和配置，LiteTopic是一种轻量级的主题，它具有以下优势，非常适用于Multi-Agent的响应场景：
+
+*
**动态创建与销毁**：可以为每一个任务动态创建一个专属的LiteTopic（例如，以任务ID命名），TTL到期后可以自动销毁，无需预先配置大量的主题，极大地提升了系统的灵活性和资源利用率。
+
+*
**隔离性**：每个会话或任务都有专属的LiteTopic，相比于普通Topic，LiteTopic的创建和维护成本更低，适合大规模、高并发的短生命周期消息场景。
+
+* **精准订阅**：在同一个ConsumerGroup下，每个Consumer可以订阅不同的LiteTopic集合。
+
+* **顺序消息**：同一个LiteTopic下的消息是顺序的，可以保障流式响应结果的正确性。
+
+## 总结
+
+本教程展示了如何利用Apache
RocketMQ，特别是其LiteTopic特性，构建一个高效、解耦的Multi-Agent异步通信系统。该方案成功地将长耗时的AI任务调用从同步阻塞模式转变为异步非阻塞模式，不仅解决了线程阻塞的痛点，还通过消息队列的缓冲和削峰填谷能力，极大地提升了系统的稳定性和可扩展性。这种架构模式为构建复杂、专业的AI应用提供了坚实的基础。
diff --git a/versioned_docs/version-5.0/06-bestPractice/02dledger.md
b/versioned_docs/version-5.0/06-bestPractice/05dledger.md
similarity index 100%
rename from versioned_docs/version-5.0/06-bestPractice/02dledger.md
rename to versioned_docs/version-5.0/06-bestPractice/05dledger.md
diff --git a/versioned_docs/version-5.0/06-bestPractice/03access.md
b/versioned_docs/version-5.0/06-bestPractice/06access.md
similarity index 99%
rename from versioned_docs/version-5.0/06-bestPractice/03access.md
rename to versioned_docs/version-5.0/06-bestPractice/06access.md
index c101c97944..4d55fd46f8 100644
--- a/versioned_docs/version-5.0/06-bestPractice/03access.md
+++ b/versioned_docs/version-5.0/06-bestPractice/06access.md
@@ -4,7 +4,7 @@
本文档介绍的是 **访问控制 2.0（ACL 2.0）**，适用于 **RocketMQ 5.3.0** 及以上版本。
-- 如果您使用的是 **RocketMQ 4.x、5.0-5.2 或 5.3.0-5.3.2** 版本，请参考 [ACL 1.0
文档](07access-1.0)
+- 如果您使用的是 **RocketMQ 4.x、5.0-5.2 或 5.3.0-5.3.2** 版本，请参考 [ACL 1.0
文档](10access-1.0)
- **从 RocketMQ 5.3.3 开始，ACL 1.0 已不再支持**，建议升级到 ACL 2.0
- 如果您正在从 ACL 1.0 迁移到 2.0，请查看本文档的 [ACL 1.0 迁移](#5-acl-10迁移到acl-20) 章节
diff --git a/versioned_docs/version-5.0/06-bestPractice/04JVMOS.md
b/versioned_docs/version-5.0/06-bestPractice/07JVMOS.md
similarity index 100%
rename from versioned_docs/version-5.0/06-bestPractice/04JVMOS.md
rename to versioned_docs/version-5.0/06-bestPractice/07JVMOS.md
diff --git a/versioned_docs/version-5.0/06-bestPractice/05subscribe.md
b/versioned_docs/version-5.0/06-bestPractice/08subscribe.md
similarity index 98%
rename from versioned_docs/version-5.0/06-bestPractice/05subscribe.md
rename to versioned_docs/version-5.0/06-bestPractice/08subscribe.md
index 7f87ad03a0..7337da11fd 100644
--- a/versioned_docs/version-5.0/06-bestPractice/05subscribe.md
+++ b/versioned_docs/version-5.0/06-bestPractice/08subscribe.md
@@ -2,7 +2,7 @@
## 前言
-订阅关系是 RocketMQ
领域模型中非常重要的环节，用于表达消费者消费消息的控制元数据，完整的概念请参考[订阅关系模型](../03-domainModel/09subscription.md)。
+订阅关系是 RocketMQ
领域模型中非常重要的环节，用于表达消费者消费消息的控制元数据，完整的概念请参考[订阅关系模型](../03-domainModel/10subscription.md)。
订阅关系一致是指，同一个消费者组下所有消费者实例所订阅的Topic、Tag必须完全一致。如果订阅关系（消费者分组名-Topic-Tag）不一致，会导致消费消息紊乱，甚至消息丢失。
diff --git a/versioned_docs/version-5.0/06-bestPractice/06FAQ.md
b/versioned_docs/version-5.0/06-bestPractice/09FAQ.md
similarity index 100%
rename from versioned_docs/version-5.0/06-bestPractice/06FAQ.md
rename to versioned_docs/version-5.0/06-bestPractice/09FAQ.md
diff --git a/versioned_docs/version-5.0/06-bestPractice/07access-1.0.md
b/versioned_docs/version-5.0/06-bestPractice/10access-1.0.md
similarity index 98%
rename from versioned_docs/version-5.0/06-bestPractice/07access-1.0.md
rename to versioned_docs/version-5.0/06-bestPractice/10access-1.0.md
index 2254b5e168..932a7a9013 100644
--- a/versioned_docs/version-5.0/06-bestPractice/07access-1.0.md
+++ b/versioned_docs/version-5.0/06-bestPractice/10access-1.0.md
@@ -11,7 +11,7 @@ custom_edit_url: null
**从 RocketMQ 5.3.3 开始，ACL 1.0 已被移除，不再支持。**
-如果您使用的是 **RocketMQ 5.3.0** 及以上版本，强烈建议使用 [ACL 2.0
文档](03access.md)，它提供了更强大和灵活的权限控制功能。
+如果您使用的是 **RocketMQ 5.3.0** 及以上版本，强烈建议使用 [ACL 2.0
文档](06access.md)，它提供了更强大和灵活的权限控制功能。
:::
diff --git a/versioned_docs/version-5.0/09-streams/01RocketMQ Streams
Overview.md b/versioned_docs/version-5.0/09-streams/01RocketMQ Streams
Overview.md
deleted file mode 100644
index 617516c82a..0000000000
--- a/versioned_docs/version-5.0/09-streams/01RocketMQ Streams Overview.md
+++ /dev/null
@@ -1,38 +0,0 @@
-# RocketMQ Streams 概览
-RocketMQ Streams是基于RocketMQ的轻量级流计算引擎。能以SDK方式被应用依赖，无须部署复杂的流计算服务端即可获得流计算能力。
-因此具有资源消耗少、扩展性好、支持流计算算子丰富的特点。
-
-## 整体架构
-
-
-数据从RocketMQ中被RocketMQ-streams消费，经过处理最终被写回到RocketMQ。
-
-
-
-数据被RocketMQ
Consumer消费，进入处理拓扑被算子处理，如果流处理任务中含有算子keyBy，则需要将数据按照Key进行分组，将分组数据写入shuffle
topic。后续算子从
-shuffle topic消费。如果还涉及count之类有状态算子，那么计算时需要读写state topic，计算结束后，将结果写回到RocketMQ中。
-
-
-## 消费模型
-
-
-
-计算实例实质上是依赖了Rocket-streams SDK的client，因此，计算实例消费的MQ依赖RocketMQ rebalance分配，
-计算实例总个数也不能大于消费总MQ个数，否则将有部分计算实例处于等待状态，消费不到数据。
-
-一个计算实例可以消费多个MQ，一个实例内也只有一张计算拓扑图。
-
-## 状态
-
-
-对于有状态算子，比如count，需要先对count算子进行分组，然后才能求和。分组算子keyBy会将数据按照分组的key重新写回RocketMQ，并且使相同key写入同一分区（这一过程称作shuffle），
-保证这个含有相同key的数据被同一个消费者消费。 状态本地依赖RocksDB加速读取，远程依赖RocketMQ做持久化。
-
-
-## 扩缩容
-
-
-
-当计算实例从3个缩容到2个，借助于RocketMQ集群消费模式下的rebalance功能，被消费的分片MQ会在计算实例之间重新分配。Instance1上消费的MQ2和MQ3被分配到Instance2和Instance3上，
-这两个MQ的状态数据也需要迁移到Instance2和Instance3上，这也暗示，状态数据是根据源数据分片MQ保存的；扩容则是刚好相反的过程。
-
diff --git a/docs/09-streams/01RocketMQ Streams Overview.md
b/versioned_docs/version-5.0/09-streams/01RocketMQStreamsOverview.md
similarity index 100%
rename from docs/09-streams/01RocketMQ Streams Overview.md
rename to versioned_docs/version-5.0/09-streams/01RocketMQStreamsOverview.md
diff --git a/versioned_docs/version-5.0/09-streams/02RocketMQ Streams
Concept.md b/versioned_docs/version-5.0/09-streams/02RocketMQ Streams Concept.md
deleted file mode 100644
index 26e8afdd7d..0000000000
--- a/versioned_docs/version-5.0/09-streams/02RocketMQ Streams Concept.md
+++ /dev/null
@@ -1,65 +0,0 @@
-# RocketMQ Streams 核心概念
-
-## 领域模型
-
-### StreamBuilder
-
-
-* 一个StreamBuilder实例，有1到N个pipeline，pipeline表示一个数据处理路径；
-* 一个pipeline可以含有1到N个处理节点GroupNode；
-* 一个StreamBuilder实例，有一个TopologyBuilder，TopologyBuilder可构建出数据处理器processor；
-* 一个JobId对应一个StreamBuilder实例。
-
-### RocketMQStream
-
-
-* 一个RocketMQStream实例，有一个拓扑构建器TopologyBuilder；
-* 一个RocketMQStream实例，可实例化1到N个worker线程;
-* 每个线程WorkerThread实例，包含一个engine；
-* 一个engine包含执行数据处理的所有逻辑，包含一个consumer实例、一个producer实例、一个StateStore实例;
-
-### 流处理实例
-流处理实例表示一个运行RocketMQ Streams的进程；
-
-* 一个流处理实例包含一个StreamBuilder，一个RocketMQStream，一个拓扑图，一到多个pipeline；
-
-
-## StreamBuilder
-+ ```StreamBuilder(jobId)``` 构建实例；
-+ ```<OUT> RStream<OUT> source(topicName, deserializer) ``` 定义source topic
和反序列化方式；
-
-
-## RStream
-+ ```<K> GroupedStream<K, T> keyBy(selectAction)``` 按照特定字段分组；
-+ ```<O> RStream<O> map(mapperAction)``` 对数据进行一对一转化；
-+ ```RStream<T> filter(predictor)``` 对数据进行过滤
-+ ```<VR> RStream<T> flatMap(mapper)```对数据进行一对多转化；
-+ ```<T2> JoinedStream<T, T2> join(rightStream)``` 双流Join；
-+ ```sink(topicName, serializer)``` 将结果输出到特定topic；
-
-
-## GroupedStream
-对含有相同Key的数据进行操作
-+ ```<OUT> GroupedStream<K, Integer> count(selectAction)``` 统计含有某个字段数据的个数；
-+ ```GroupedStream<K, V> min(selectAction)``` 对某个字段统计最小值；
-+ ```GroupedStream<K, V> max(selectAction)``` 对某个字段统计最大值；
-+ ```GroupedStream<K, ? extends Number> sum(selectAction)``` 对某个字段统计和；
-+ ```GroupedStream<K, V> filter(predictor)``` 对某个字段进行过滤；
-+ ```<OUT> GroupedStream<K, OUT> map(valueMapperAction)``` 对数据进行一对一转化；
-+ ```<OUT> GroupedStream<K, OUT> aggregate(accumulator)```
对数据进行聚合操作，且聚合支持二阶聚合，例如在窗口未触发时添加数据，在窗口触发时计算结果这类算子；
-+ ```WindowStream<K, V> window(windowInfo)``` 对窗口划定window；
-+ ```GroupedStream<K, V> addGraphNode(name, supplier)``` 底层接口，向流处理拓扑中增加自定义算子；
-+ ```RStream<V> toRStream()``` 转化为RStream，只是在接口形式上转化，对数据无任何操作；
-+ ```sink(topicName, serializer)``` 按照自定义序列化形式将结果写出到topic；
-
-
-## WindowStream
-对被划分window的数据进行操作
-+ ```WindowStream<K, Integer> count()``` 统计窗口内数据个数；
-+ ```WindowStream<K, V> filter(predictor)``` 过滤窗口内数据；
-+ ```<OUT> WindowStream<K, OUT> map(mapperAction)``` 对窗口内数据一对一转化；
-+ ```<OUT> WindowStream<K, OUT> aggregate(aggregateAction)``` 对窗口内数据多对一转化；
-+ ```<OUT> WindowStream<K, OUT> aggregate(accumulator)```
对数据进行聚合操作，且聚合支持二阶聚合，例如在窗口未触发时添加数据，在窗口触发时计算结果这类算子；
-+ ```void sink(topicName, serializer)``` 按照自定义序列化形式将结果写出到topic；
-
-
diff --git a/docs/09-streams/02RocketMQ Streams Concept.md
b/versioned_docs/version-5.0/09-streams/02RocketMQStreamsConcept.md
similarity index 100%
rename from docs/09-streams/02RocketMQ Streams Concept.md
rename to versioned_docs/version-5.0/09-streams/02RocketMQStreamsConcept.md
diff --git a/versioned_docs/version-5.0/09-streams/03RocketMQ Streams Quick
Start.md b/versioned_docs/version-5.0/09-streams/03RocketMQ Streams Quick
Start.md
deleted file mode 100644
index d258e35966..0000000000
--- a/versioned_docs/version-5.0/09-streams/03RocketMQ Streams Quick Start.md
+++ /dev/null
@@ -1,162 +0,0 @@
-# RocketMQ Streams 快速开始
-
-## RocketMQ Streams工程中运行
-参考RocketMQ Streams工程rocketmq-streams-examples模块下程序可以直接运行；运行example步骤：
-* 本地启动RocketMQ 5.0及以上版本;
-* 使用mqAdmin创建example中数据源topic；
-* 启动example中例子；
-* 向RocketMQ的源topic中写入合适数据（依据示例而定）；
-
-## RocketMQ Streams以SDK方式被应用依赖
-### 环境准备
-- 64bit JDK 1.8及以上
-- Maven 3.2及以上
-- 本地启动RocketMQ，[启动文档](https://rocketmq.apache.org/docs/quick-start/)
-
-### 构建RocketMQ Streams
-
-
-### 添加pom依赖
-
-```xml
- <dependencies>
- <dependency>
- <groupId>org.apache.rocketmq</groupId>
- <artifactId>rocketmq-streams</artifactId>
- <!-- 根据需要修改 -->
- <version>1.1.0</version>
- </dependency>
-</dependencies>
-```
-
-### 编写流计算程序
-```java
-public class WordCount {
- public static void main(String[] args) {
- StreamBuilder builder = new StreamBuilder("wordCount");
-
- builder.source("sourceTopic", total -> {
- String value = new String(total, StandardCharsets.UTF_8);
- return new Pair<>(null, value);
- })
- .flatMap((ValueMapperAction<String, List<String>>) value -> {
- String[] splits = value.toLowerCase().split("\\W+");
- return Arrays.asList(splits);
- })
- .keyBy(value -> value)
- .count()
- .toRStream()
- .print();
-
- TopologyBuilder topologyBuilder = builder.build();
-
- Properties properties = new Properties();
- properties.put(MixAll.NAMESRV_ADDR_PROPERTY, "127.0.0.1:9876");
-
- RocketMQStream rocketMQStream = new RocketMQStream(topologyBuilder,
properties);
-
- final CountDownLatch latch = new CountDownLatch(1);
-
- Runtime.getRuntime().addShutdownHook(new
Thread("wordcount-shutdown-hook") {
- @Override
- public void run() {
- rocketMQStream.stop();
- latch.countDown();
- }
- });
-
- try {
- rocketMQStream.start();
- latch.await();
- } catch (final Throwable e) {
- System.exit(1);
- }
- System.exit(0);
- }
-}
-```
-
-### 向RocketMQ sourceTopic中写入数据并观察结果
-如果向sourceTopic中写入的数据如下：每行数据作为一个消息发送；
-```xml
-"To be, or not to be,--that is the question:--",
-"Whether 'tis nobler in the mind to suffer",
-"The slings and arrows of outrageous fortune",
-"Or to take arms against a sea of troubles,",
-"And by opposing end them?--To die,--to sleep,--",
-"No more; and by a sleep to say we end",
-"The heartache, and the thousand natural shocks",
-"That flesh is heir to,--'tis a consummation",
-```
-统计单词出现频率，计算结果如下：
-```xml
-(key=to, value=1)
-(key=be, value=1)
-(key=or, value=1)
-(key=not, value=1)
-(key=to, value=2)
-(key=be, value=2)
-(key=that, value=1)
-(key=is, value=1)
-(key=the, value=1)
-(key=whether, value=1)
-(key=tis, value=1)
-(key=nobler, value=1)
-(key=mind, value=1)
-(key=against, value=1)
-(key=troubles, value=1)
-(key=slings, value=1)
-(key=die, value=1)
-(key=natural, value=1)
-(key=flesh, value=1)
-(key=sea, value=1)
-(key=fortune, value=1)
-(key=shocks, value=1)
-(key=consummation, value=1)
-(key=to, value=3)
-(key=to, value=4)
-(key=to, value=5)
-(key=say, value=1)
-(key=end, value=1)
-(key=end, value=2)
-(key=to, value=6)
-(key=to, value=7)
-(key=to, value=8)
-(key=or, value=2)
-(key=them, value=1)
-(key=take, value=1)
-(key=arms, value=1)
-(key=of, value=1)
-(key=and, value=1)
-(key=of, value=2)
-(key=and, value=2)
-(key=by, value=1)
-(key=sleep, value=1)
-(key=and, value=3)
-(key=by, value=2)
-(key=sleep, value=2)
-(key=and, value=4)
-(key=that, value=2)
-(key=arrows, value=1)
-(key=heir, value=1)
-(key=question, value=1)
-(key=is, value=2)
-(key=the, value=2)
-(key=suffer, value=1)
-(key=a, value=1)
-(key=the, value=3)
-(key=no, value=1)
-(key=a, value=2)
-(key=opposing, value=1)
-(key=the, value=4)
-(key=the, value=5)
-(key=a, value=3)
-(key=in, value=1)
-(key=more, value=1)
-(key=heartache, value=1)
-(key=outrageous, value=1)
-(key=we, value=1)
-(key=thousand, value=1)
-(key=tis, value=2)
-```
-
diff --git a/docs/09-streams/03RocketMQ Streams Quick Start.md
b/versioned_docs/version-5.0/09-streams/03RocketMQStreamsQuickStart.md
similarity index 100%
rename from docs/09-streams/03RocketMQ Streams Quick Start.md
rename to versioned_docs/version-5.0/09-streams/03RocketMQStreamsQuickStart.md
diff --git a/versioned_docs/version-5.0/picture/v5/litetopic_domain_model.png
b/versioned_docs/version-5.0/picture/v5/litetopic_domain_model.png
new file mode 100644
index 0000000000..bf5d3580ab
Binary files /dev/null and
b/versioned_docs/version-5.0/picture/v5/litetopic_domain_model.png differ
diff --git a/versioned_docs/version-5.0/picture/v5/litetopic_multiagent.png
b/versioned_docs/version-5.0/picture/v5/litetopic_multiagent.png
new file mode 100644
index 0000000000..0b02f2e010
Binary files /dev/null and
b/versioned_docs/version-5.0/picture/v5/litetopic_multiagent.png differ
diff --git
a/versioned_docs/version-5.0/picture/v5/litetopic_multiagent_practice.png
b/versioned_docs/version-5.0/picture/v5/litetopic_multiagent_practice.png
new file mode 100644
index 0000000000..0b02f2e010
Binary files /dev/null and
b/versioned_docs/version-5.0/picture/v5/litetopic_multiagent_practice.png differ
diff --git
a/versioned_docs/version-5.0/picture/v5/litetopic_multiagent_practice.svg
b/versioned_docs/version-5.0/picture/v5/litetopic_multiagent_practice.svg
new file mode 100644
index 0000000000..f482a31af7
--- /dev/null
+++ b/versioned_docs/version-5.0/picture/v5/litetopic_multiagent_practice.svg
@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg"; version="1.1" data-width="963"
data-height="583" class="icms-hetu-svg" width="963px" height="583px"><defs /><g
transform="translate(0.5,0.5)"><rect x="1" y="201" width="120" height="160"
fill="#ffffff" stroke="#d9d9d9" pointer-events="none" /><rect x="161" y="1"
width="800" height="580" fill="#f0f0f0" stroke="none" pointer-events="none"
/><g><switch><foreignObject style="overflow: visible; text-align: left;"
pointer-events="none" width="100%" heigh [...]
\ No newline at end of file
diff --git
a/versioned_docs/version-5.0/picture/v5/litetopic_ratelimit_practice.svg
b/versioned_docs/version-5.0/picture/v5/litetopic_ratelimit_practice.svg
new file mode 100644
index 0000000000..3906437afd
--- /dev/null
+++ b/versioned_docs/version-5.0/picture/v5/litetopic_ratelimit_practice.svg
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Do not edit this file with editors other than draw.io -->
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";>
+<svg xmlns="http://www.w3.org/2000/svg"; style="background: transparent;
background-color: transparent; color-scheme: light dark;"
xmlns:xlink="http://www.w3.org/1999/xlink"; version="1.1" width="1353px"
height="451px" viewBox="-0.5 -0.5 1353 451" content="<mxfile
host="Electron" agent="Mozilla/5.0 (Macintosh; Intel Mac OS X
10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/27.0.9
Chrome/134.0.6998.205 Electron/35.4.0 Safari/537.36"
version="27.0.9"&g [...]
\ No newline at end of file
diff --git a/versioned_docs/version-5.0/picture/v5/litetopic_session.png
b/versioned_docs/version-5.0/picture/v5/litetopic_session.png
new file mode 100644
index 0000000000..0b02f2e010
Binary files /dev/null and
b/versioned_docs/version-5.0/picture/v5/litetopic_session.png differ
diff --git
a/versioned_docs/version-5.0/picture/v5/litetopic_session_practice.png
b/versioned_docs/version-5.0/picture/v5/litetopic_session_practice.png
new file mode 100644
index 0000000000..0b02f2e010
Binary files /dev/null and
b/versioned_docs/version-5.0/picture/v5/litetopic_session_practice.png differ
diff --git
a/versioned_docs/version-5.0/picture/v5/litetopic_session_practice.svg
b/versioned_docs/version-5.0/picture/v5/litetopic_session_practice.svg
new file mode 100644
index 0000000000..c50997897b
--- /dev/null
+++ b/versioned_docs/version-5.0/picture/v5/litetopic_session_practice.svg
@@ -0,0 +1 @@
+<svg xmlns="http://www.w3.org/2000/svg"; version="1.1" data-width="1067"
data-height="403" class="icms-hetu-svg" width="1067px" height="403px"><defs
/><g transform="translate(0.5,0.5)"><rect x="578" y="1" width="150"
height="400" fill="#ffffff" stroke="#d9d9d9" pointer-events="none"
/><g><switch><foreignObject style="overflow: visible; text-align: left;"
pointer-events="none" width="100%" height="100%"
requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility";><div
xmlns="http:// [...]
\ No newline at end of file
