This is an automated email from the ASF dual-hosted git repository.
gosonzhang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-inlong-website.git
The following commit(s) were added to refs/heads/master by this push:
new a8cdfd8 [INLONG-178]Modify part of the description in the office-web
document (#179)
a8cdfd8 is described below
commit a8cdfd89553196e0e1cd0e7462a30315f6697bcf
Author: healchow <[email protected]>
AuthorDate: Sun Nov 7 09:08:15 2021 +0800
[INLONG-178]Modify part of the description in the office-web document (#179)
Co-authored-by: healchow <[email protected]>
---
docs/modules/dataproxy-sdk/architecture.md | 2 +-
docs/modules/dataproxy/architecture.md | 2 +-
docs/modules/tubemq/architecture.md | 34 +++++++++----
docs/user_guide/user_manual.md | 11 ++---
.../current/modules/dataproxy/architecture.md | 10 ++--
.../current/modules/tubemq/architecture.md | 4 +-
.../current/modules/tubemq/clients_java.md | 57 +++++++---------------
.../current/modules/tubemq/error_code.md | 4 +-
.../current/user_guide/user_manual.md | 4 +-
9 files changed, 59 insertions(+), 69 deletions(-)
diff --git a/docs/modules/dataproxy-sdk/architecture.md
b/docs/modules/dataproxy-sdk/architecture.md
index aa48200..591163c 100644
--- a/docs/modules/dataproxy-sdk/architecture.md
+++ b/docs/modules/dataproxy-sdk/architecture.md
@@ -19,7 +19,7 @@ The original intention of API design is to simplify user
access and assume some
| Maintain proxy list| Get the proxy list every five minutes to detect whether
there is a proxy machine on the operation and maintenance side; automatically
remove unavailable connections every 20s to ensure that the connected proxy can
operate normally |
| Indicator statistics (new)| Increase the indicator of business minute-level
sending volume (interface level)|
| Load balancing (new)| Use the new strategy to load balance the sent data
among multiple proxies, instead of relying on simple random + polling mechanism
to ensure|
-| proxy list persistence (new)| Persist the proxy list according to the
business id to prevent the configuration center from failing to send data when
the program starts
+| proxy list persistence (new)| Persist the proxy list according to the
business group id to prevent the configuration center from failing to send data
when the program starts
## 2.2 Data transmission function description
diff --git a/docs/modules/dataproxy/architecture.md
b/docs/modules/dataproxy/architecture.md
index 239f217..a7d72f5 100644
--- a/docs/modules/dataproxy/architecture.md
+++ b/docs/modules/dataproxy/architecture.md
@@ -4,7 +4,7 @@ title: Architecture
# 1、intro
Inlong-dataProxy belongs to the inlong proxy layer and is used for data
collection, reception and forwarding. Through format conversion, the data is
converted into TDMsg1 format that can be cached and processed by the cache layer
- InLong-dataProxy acts as a bridge from the InLong collection end to the
InLong buffer end. Dataproxy pulls the relationship between the business id and
the corresponding topic name from the manager module, and internally manages
the producers of multiple topics
+ InLong-dataProxy acts as a bridge from the InLong collection end to the
InLong buffer end. Dataproxy pulls the relationship between the business group
id and the corresponding topic name from the manager module, and internally
manages the producers of multiple topics
The overall architecture of inlong-dataproxy is based on Apache Flume. On
the basis of this project, inlong-bus expands the source layer and sink layer,
and optimizes disaster tolerance forwarding, which improves the stability of
the system.
diff --git a/docs/modules/tubemq/architecture.md
b/docs/modules/tubemq/architecture.md
index 7c8b881..d81a6ee 100644
--- a/docs/modules/tubemq/architecture.md
+++ b/docs/modules/tubemq/architecture.md
@@ -3,18 +3,32 @@ title: Architecture
---
## 1. TubeMQ Architecture:
-After years of evolution, the TubeMQ cluster is divided into the following 5
parts:
+After years of evolution, the TubeMQ cluster is divided into the following 5
parts:
-- **Portal：** The Portal part responsible for external interaction and
maintenance operations, including API and Web. The API connects to the
management system outside the cluster. The Web is a page encapsulation of daily
operation and maintenance functions based on the API;
-
-- **Master：** It is responsible for the Control part of the cluster. This part
is composed of one or more Master nodes. Master HA performs heartbeat
keep-alive and real-time hot standby switching between master nodes (This is
the reason why everyone needs to fill in the addresses of all Master nodes
corresponding to the cluster when using TubeMQ Lib). The main master is
responsible for managing the status of the entire cluster, resource scheduling,
permission checking, metadata query, etc;
-
-- **Broker：** The Store part responsible for data storage. This part is
composed of independent Broker nodes. Each Broker node manages the Topic set in
this node, including the addition, deletion, modification, and inquiring about
Topics. It is also responsible for message storage, consumption, aging,
partition expansion, data consumption offset records, etc. on the topic, and
the external capabilities of the cluster, including the number of topics,
throughput, and capacity, are complete [...]
-
-- **Client：** The Client part responsible for data production and consumption.
We provide this part in the form of Lib. The most commonly used is the
consumer. Compared with the previous, the consumer now supports Push and Pull
data pull modes, data consumption behavior support both order and filtered
consumption. For the Pull consumption mode, the service supports resetting the
precise offset through the client to support the business extract-once
consumption. At the same time, the cons [...]
-
-- **Zookeeper：** Responsible for the Zookeeper part of the offset storage.
This part of the function has been weakened to only the persistent storage of
the offset. Considering the next multi-node copy function, this module is
temporarily reserved;
+- **Portal：** The Portal part responsible for external interaction and
maintenance operations, including API and Web.
+ The API connects to the management system outside the cluster. The Web is a
page encapsulation of daily operation
+ and maintenance functions based on the API;
+
+- **Master：** It is responsible for the Control part of the cluster. This part
is composed of one or more Master nodes.
+ Master HA performs heartbeat keep-alive and real-time hot standby switching
between master nodes (This is the reason
+ why everyone needs to fill in the addresses of all Master nodes
corresponding to the cluster when using TubeMQ Lib).
+ The main master is responsible for managing the status of the entire
cluster, resource scheduling, permission
+ checking, metadata query, etc.;
+
+- **Broker：** The Store part responsible for data storage. This part is
composed of independent Broker nodes.
+ Each Broker node manages the Topic set in this node, including the addition,
deletion, modification, and inquiring
+ about Topics. It is also responsible for message storage, consumption,
aging, partition expansion, data consumption
+ offset records, etc. On the topic, and the external capabilities of the
cluster, including the number of topics,
+ throughput, and capacity, are completed by horizontally expanding the broker
node;
+
+- **Client：** The Client part responsible for data production and consumption.
We provide this part in the form of Lib.
+ The most commonly used is the consumer. Compared with the previous, the
consumer now supports Push and Pull data pull
+ modes, data consumption behavior support both order and filtered
consumption. For the Pull consumption mode, the
+ service supports resetting the precise offset through the client to support
the business extract-once consumption.
+ At the same time, the consumer has launched a new cross-cluster switch-free
Consumer client;
+
+- **ZooKeeper：** Responsible for the ZooKeeper part of the offset storage.
This part of the function has been weakened to only the persistent storage of
the offset. Considering the next multi-node copy function, this module is
temporarily reserved;
## 2. Broker File Storage Scheme Improvement:
Systems that use disks as data persistence media are faced with various system
performance problems caused by disk problems. The TubeMQ system is no
exception, the performance improvement is largely to solve the problem of how
to read, write and store message data. In this regard TubeMQ has made many
improvements: storage instances is as the smallest Topic data management unit;
each storage instance includes a file storage block and a memory cache block;
each Topic can be assigned multip [...]
diff --git a/docs/user_guide/user_manual.md b/docs/user_guide/user_manual.md
index 2ba7b4f..83bdf33 100644
--- a/docs/user_guide/user_manual.md
+++ b/docs/user_guide/user_manual.md
@@ -63,10 +63,9 @@ You are required to fill in the basic information of the
data stream in the acce
-- Data stream ID: The prefix is automatically generated according to the
product/project, the unique identifier of the
- data in the business, the unique identifier defined by a certain business,
the data stream ID in the data source, and
- the entry in the Hive information table The data stream ID is the same
-- Data stream name: interface information description, the length is limited
to varchar (64), 32 Chinese
+- InLong stream id: The prefix is automatically generated according to the
product/project, which is unique in a
+ specific business group and is consistent with the stream id in the data
source and the storage table
+- Data stream name: interface information description, the length is limited
to 64 characters (32 Chinese characters)
- Data stream owner: The data stream owner can view and modify data stream
information, add and modify all access
configuration items
- Introduction to data flow: simple text introduction to data flow
@@ -183,8 +182,8 @@ the information filling module
name based on the abbreviation splicing
- Consumer Responsible Person: At least 2 persons are required to choose the
responsible person; the responsible person
can view and modify the consumption information
-- Consumer target business ID: you need to select the business ID of the
consumer data, you can click [Query] and select
- the appropriate business ID in the pop-up window
+- Consumer target business group id: you need to select the business group id
of the consumer data, you can click [Query] and
+ select the appropriate business group id in the pop-up window
- Data usage: select data usage usage
- Data usage description: The applicant needs to briefly explain the items
used and the purpose of the data according to
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/dataproxy/architecture.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/dataproxy/architecture.md
index 27357fe..9c63de0 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/dataproxy/architecture.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/dataproxy/architecture.md
@@ -3,9 +3,9 @@ title: 架构介绍
---
# 一、说明
- InLong-dataProxy属于inlong
proxy层，用于数据的汇集接收以及转发。通过格式转换，将数据转为cache层可以缓存处理的TDMsg1格式
+ InLong-dataProxy属于inlong
proxy层，用于数据的汇集接收以及转发。通过格式转换，将数据转为cache层可以缓存处理的TDMsg1格式
InLong-dataProxy充当了InLong采集端到InLong缓冲端的桥梁，dataproxy从manager模块拉取业务id与对应topic名称的关系，内部管理多个topic的生产者
- 当dataproxy收到消息时，会首先缓存到本地的Channel中，并使用本地的producer往后端即cache层发送数据
+ 当dataproxy收到消息时，会首先缓存到本地的Channel中，并使用本地的producer往后端即cache层发送数据
InLong-dataProxy整体架构基于Apache
Flume。inlong-dataproxy在该项目的基础上，扩展了source层和sink层，并对容灾转发做了优化处理，提升了系统的稳定性。
@@ -13,9 +13,9 @@ title: 架构介绍
- 1.Source层开启端口监听，通过netty server实现。解码之后的数据发到channel层
- 2.channel层有一个selector，用于选择走哪种类型的channel，如果memory最终满了，会对数据做落地处理
- 3.channel层的数据会通过sink层做转发，这里主要是将数据转为TDMsg1的格式，并推送到cache层（这里用的比较多的是tube）
+ 1.Source层开启端口监听，通过netty server实现。解码之后的数据发到channel层
+ 2.channel层有一个selector，用于选择走哪种类型的channel，如果memory最终满了，会对数据做落地处理
+ 3.channel层的数据会通过sink层做转发，这里主要是将数据转为TDMsg1的格式，并推送到cache层（这里用的比较多的是tube）
# 三、DataProxy功能配置说明
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/architecture.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/architecture.md
index 3067b8f..f2e65da 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/architecture.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/architecture.md
@@ -12,9 +12,9 @@ title: 架构介绍
- **Broker**：
负责实际数据存储的Store部分，该部分由相互之间独立的Broker节点组成，每个Broker节点对本节点内的Topic集合进行管理，包括Topic的增、删、改、查，Topic内的消息存储、消费、老化、分区扩容、数据消费的offset记录等，集群对外能力，包括Topic数目、吞吐量、容量等，通过水平扩展Broker节点来完成；
-- **Client**：
负责数据生产和消费的Client部分，该部分我们以Lib形式对外提供，大家用得最多的是消费端，相比之前，消费端现支持Push、Pull两种数据拉取模式，数据消费行为支持顺序和过滤消费两种。对于Pull消费模式，支持业务通过客户端重置精确offset以支持业务exactly-once消费，同时，消费端新推出跨集群切换免重启的BidConsumer客户端；
+- **Client**：
负责数据生产和消费的Client部分，该部分我们以Lib形式对外提供，大家用得最多的是消费端，相比之前，消费端现支持Push、Pull两种数据拉取模式，数据消费行为支持顺序和过滤消费两种。对于Pull消费模式，支持业务通过客户端重置精确offset以支持业务exactly-once消费，同时，消费端新推出跨集群切换免重启的Consumer客户端；
-- **Zookeeper**： 负责offset存储的zk部分，该部分功能已弱化到仅做offset的持久化存储，考虑到接下来的多节点副本功能该模块暂时保留。
+- **ZooKeeper**：
负责offset存储的ZooKeeper部分，该部分功能已弱化到仅做offset的持久化存储，考虑到接下来的多节点副本功能该模块暂时保留。
## 2 Apache InLong TubeMQ模块的系统特点
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/clients_java.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/clients_java.md
index 35e7714..66fb611 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/clients_java.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/clients_java.md
@@ -81,8 +81,7 @@ TubeMQ开源包org.apache.inlong.tubemq.example里提供了生产和消费的具
```java
public final class MessageConsumerExample {
- private static final Logger logger =
- LoggerFactory.getLogger(MessageConsumerExample.class);
+ private static final Logger logger =
LoggerFactory.getLogger(MessageConsumerExample.class);
private static final MsgRecvStats msgRecvStats = new MsgRecvStats();
private final String masterHostAndPort;
private final String localHost;
@@ -90,15 +89,12 @@ public final class MessageConsumerExample {
private PushMessageConsumer messageConsumer;
private MessageSessionFactory messageSessionFactory;
- public MessageConsumerExample(String localHost,
- String masterHostAndPort,
- String group,
- int fetchCount) throws Exception {
+ public MessageConsumerExample(String localHost, String masterHostAndPort,
String group, int fetchCount)
+ throws Exception {
this.localHost = localHost;
this.masterHostAndPort = masterHostAndPort;
this.group = group;
- ConsumerConfig consumerConfig =
- new ConsumerConfig(this.localHost,this.masterHostAndPort,
this.group);
+ ConsumerConfig consumerConfig = new
ConsumerConfig(this.localHost,this.masterHostAndPort, this.group);
consumerConfig.setConsumeModel(0);
if (fetchCount > 0) {
consumerConfig.setPushFetchThreadCnt(fetchCount);
@@ -110,18 +106,15 @@ public final class MessageConsumerExample {
```
-
#### 2.2.2 订阅Topic：
我们没有采用指定Offset消费的模式进行订阅，也没有过滤需求，因而我们在如下代码里只做了Topic的指定，对应的过滤项集合我们传的是null值，同时，对于不同的Topic，我们可以传递不同的消息回调处理函数；我们这里订阅了3个topic，topic_1，topic_2，topic_3，每个topic分别调用subscribe函数进行对应参数设置：
```java
-public void subscribe(final Map<String, TreeSet<String>> topicTidsMap)
- throws TubeClientException {
- for (Map.Entry<String, TreeSet<String>> entry : topicTidsMap.entrySet()) {
- this.messageConsumer.subscribe(entry.getKey(),
- entry.getValue(),
- new
DefaultMessageListener(entry.getKey()));
+public void subscribe(final Map<String, TreeSet<String>> topicStreamIdMap)
throws TubeClientException {
+ for (Map.Entry<String, TreeSet<String>> entry :
topicStreamIdMap.entrySet()) {
+ this.messageConsumer.subscribe(entry.getKey(), entry.getValue(),
+ new DefaultMessageListener(entry.getKey()));
}
messageConsumer.completeSubscribe();
}
@@ -141,8 +134,7 @@ public class DefaultMessageListener implements
MessageListener {
this.topic = topic;
}
- public void receiveMessages(PeerInfo peerInfo, final List<Message>
messages) throws InterruptedException
- {
+ public void receiveMessages(PeerInfo peerInfo, final List<Message>
messages) throws InterruptedException {
if (messages != null && !messages.isEmpty()) {
msgRecvStats.addMsgCount(this.topic, messages.size());
}
@@ -158,7 +150,6 @@ public class DefaultMessageListener implements
MessageListener {
```
-
### 3 创建Producer：
现网环境中业务的数据都是通过代理层来做接收汇聚，包装了比较多的异常处理，大部分的业务都没有也不会接触到TubeSDK的Producer类，考虑到业务自己搭建集群使用TubeMQ进行使用的场景，这里提供对应的使用demo，见包org.apache.inlong.tubemq.example.MessageProducerExample类文件供参考，**需要注意**的是，业务除非使用数据平台的TubeMQ集群做MQ服务，否则仍要按照现网的接入流程使用代理层来进行数据生产：
@@ -170,23 +161,20 @@ public class DefaultMessageListener implements
MessageListener {
```java
public final class MessageProducerExample {
- private static final Logger logger =
- LoggerFactory.getLogger(MessageProducerExample.class);
- private static final ConcurrentHashMap<String, AtomicLong> counterMap =
- new ConcurrentHashMap<String, AtomicLong>();
+ private static final Logger logger =
LoggerFactory.getLogger(MessageProducerExample.class);
+ private static final ConcurrentHashMap<String, AtomicLong> counterMap =
+ new ConcurrentHashMap<String, AtomicLong>();
String[] arrayKey = {"aaa", "bbb", "ac", "dd", "eee", "fff", "gggg",
"hhhh"};
private MessageProducer messageProducer;
- private TreeSet<String> filters = new TreeSet<String>();
+ private TreeSet<String> filters = new TreeSet<>();
private int keyCount = 0;
private int sentCount = 0;
private MessageSessionFactory messageSessionFactory;
- public MessageProducerExample(final String localHost, final String
masterHostAndPort)
- throws Exception {
+ public MessageProducerExample(final String localHost, final String
masterHostAndPort) throws Exception {
filters.add("aaa");
filters.add("bbb");
- TubeClientConfig clientConfig =
- new TubeClientConfig(localHost, masterHostAndPort);
+ TubeClientConfig clientConfig = new TubeClientConfig(localHost,
masterHostAndPort);
this.messageSessionFactory = new
TubeSingleSessionFactory(clientConfig);
this.messageProducer = this.messageSessionFactory.createProducer();
}
@@ -194,7 +182,6 @@ public final class MessageProducerExample {
```
-
#### 3.2 发布Topic：
```java
@@ -204,15 +191,12 @@ public void publishTopics(List<String> topicList) throws
TubeClientException {
```
-
#### 3.3 进行数据生产：
如下所示，则为具体的数据构造和发送逻辑，构造一个Message对象后调用sendMessage()函数发送即可，有同步接口和异步接口选择，依照业务要求选择不同接口；需要注意的是该业务根据不同消息调用message.putSystemHeader()函数设置消息的过滤属性和发送时间，便于系统进行消息过滤消费，以及指标统计用。完成这些，一条消息即被发送出去，如果返回结果为成功，则消息被成功的接纳并且进行消息处理，如果返回失败，则业务根据具体错误码及错误提示进行判断处理，相关错误详情见《TubeMQ错误信息介绍.xlsx》：
```java
-public void sendMessageAsync(int id, long currtime,
- String topic, byte[] body,
- MessageSentCallback callback) {
+public void sendMessageAsync(int id, long currtime, String topic, byte[] body,
MessageSentCallback callback) {
Message message = new Message(topic, body);
SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddHHmm");
long currTimeMillis = System.currentTimeMillis();
@@ -234,21 +218,14 @@ public void sendMessageAsync(int id, long currtime,
```
-
#### 3.5 Producer不同类MAMessageProducerExample关注点：
该类初始化与MessageProducerExample类不同，采用的是TubeMultiSessionFactory多会话工厂类进行的连接初始化，该demo提供了如何使用多会话工厂类的特性，可以用于通过多个物理连接提升系统吞吐量的场景（TubeMQ通过连接复用模式来减少物理连接资源的使用），恰当使用可以提升系统的生产性能。在Consumer侧也可以通过多会话工厂进行初始化，但考虑到消费是长时间过程处理，对连接资源的占用比较小，消费场景不推荐使用。
-
-自此，整个生产和消费的示例已经介绍完，大家可以直接下载对应的代码编译跑一边，看看是不是就是这么简单😊
+至此，整个生产和消费的示例已经介绍完，你可以下载代码并编译运行，看看是不是这么简单😊
---
<a href="#top">Back to top</a>
-
-
-
-
-
\ No newline at end of file
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/error_code.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/error_code.md
index 5b23ee5..cc7def2 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/error_code.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/modules/tubemq/error_code.md
@@ -28,7 +28,7 @@ title: 错误码定义
| 客户端错误| 419 | SERVER_RECEIVE_OVERFLOW |
服务器接收overflow，需要重试处理 |
如果长期的overflow，需要联系管理员扩容存储实例，或者扩大内存缓存大小 |
|
| 客户端错误| 450 | CONSUME_GROUP_FORBIDDEN | 消费组被纳入黑名单
| 联系管理员处理
| |
| 客户端错误| 452 | SERVER_CONSUME_SPEED_LIMIT | 消费被限速
| 联系管理员处理，解除限速
| |
-| 客户端错误| 455 | CONSUME_CONTENT_FORBIDDEN |
消费内容拒绝，包括消费组禁止过滤消费，过滤的tid集合与允许的tid集合不一致等 | 对齐过滤消费的设置确认没有问题后，再联系管理员处理
| |
+| 客户端错误| 455 | CONSUME_CONTENT_FORBIDDEN |
消费内容拒绝，包括消费组禁止过滤消费，过滤的数据流ID集合与允许的ID集合不一致等 | 对齐过滤消费的设置确认没有问题后，再联系管理员处理
| |
| 服务器侧异常 | 500 | INTERNAL_SERVER_ERROR
| 内部服务器错误
| 需要结合错误信息，联系管理员确定问题原因后重试 |
| 服务器侧异常| 503 | SERVICE_UNAVILABLE | 业务临时禁读或者禁写
| 继续重试处理，如果持续的出现该类错误，需要联系管理员处理 |
|
| 服务器侧异常| 510 | INTERNAL_SERVER_ERROR_MSGSET_NULL | 读取不到消息集合
| 继续重试处理，如果持续的出现该类错误，需要联系管理员处理 |
|
@@ -95,7 +95,7 @@ title: 错误码定义
| 56 | Parameter error: Offset must over or equal zero of partOffsetMap
key XXX, value is YYY | 参数不合规，offset值必须是大于等于0 |
|
| 57 | Duplicated completeSubscribe call! |
重复调用completeSubscribe()函数 |
|
| 58 | Register to master failed! ConsumeGroup forbidden, XXX |
注册Master失败，消费组被禁止 | 服务端主动禁止行为，联系系统管理员处理
|
-| 59 | Register to master failed! Restricted consume content, XXX |
注册Master失败，消费内容受限 | 过滤消费的tid集合不在申请的集合范围内
|
+| 59 | Register to master failed! Restricted consume content, XXX |
注册Master失败，消费内容受限 | 过滤消费的数据流ID集合不在申请的集合范围内
|
| 60 | Register to master failed! please check and retry later. |
注册Master失败，请重试 |
这种情况需要查看客户端日志，确认问题原因，在核实没有异常日志，同时master地址填写正确，联系系统管理员处理。 |
| 61 | Get message error, reason is XXX |
因为XXX原因拉取消息失败 |
确定下问题原因，将相关错误信息提交给相关的业务负责人处理，需要根据具体错误信息对齐原因 |
| 62 | Get message null |
获取到的消息为null | 重试
|
diff --git
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/user_guide/user_manual.md
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/user_guide/user_manual.md
index 08e4f4d..4613300 100644
---
a/i18n/zh-CN/docusaurus-plugin-content-docs/current/user_guide/user_manual.md
+++
b/i18n/zh-CN/docusaurus-plugin-content-docs/current/user_guide/user_manual.md
@@ -58,8 +58,8 @@ sidebar_position: 2
--
数据流ID：前缀根据BG/产品/项目自动生成，数据在业务中的唯一标识，InLong中某个业务数据定义的唯一标识，跟数据源中的数据流ID、入库信息表中的数据流ID一致
-- 数据流名称：接口信息说明,长度限制为varchar(64)，32个中文
+- 数据流ID：前缀根据产品/项目自动生成，这在某个具体的接入中是唯一的，与数据源和入库的表中的数据流ID保持一致
+- 数据流名称：接口信息说明，长度限制为64个英文字符（对应32个中文字符）
- 数据流责任人：数据流责任人可查看、修改数据流信息，新增和修改所有接入配置项
- 数据流介绍：数据流简单文本介绍
