Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

diff 4.x and 5.x docs and sync some typos or description #703

Open
wants to merge 1 commit into
base: new-official-website
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 7 additions & 7 deletions docs/07-eventbridge/02RocketMQEventBridgeOverview.md
Original file line number Diff line number Diff line change
Expand Up @@ -35,7 +35,7 @@ Event,则是明确已经发生的事情。比如

### 2、无期望
```text
事件是客观的描述一个事物的状态或属性值的变化,但对于如何处理事件本身并没有做任何期望。 相比之下,Command和Query则都是有期望的,他们希望系统做出改变或则返回结果,但是Event只是客观描述系统的一个变化。
事件是客观的描述一个事物的状态或属性值的变化,但对于如何处理事件本身并没有做任何期望。 相比之下,Command和Query则都是有期望的,他们希望系统做出改变或者返回结果,但是Event只是客观描述系统的一个变化。
```
举个例子: 交通信号灯,从绿灯变成黄灯,只是描述了一个客观事实,本身并没有客观期望。在不同国家地区,对这个事件赋予了不同的期望。 比如,在日本黄灯等于红灯,而在俄罗斯闯黄灯是被默许的。

Expand All @@ -62,7 +62,7 @@ Event,则是明确已经发生的事情。比如
对比我们常见的消息,因为上下游一般是确定的,常常为了性能和传输效率,则会做到尽可能的精简,只要满足“计划经济”指定安排的消费者需求即可。
## RocketMQ EventBridge 的典型应用场景
### 场景1:事件通知
微服务中,我们常常会遇到需要把一个微服务中生产的消息,通知给其他消费者。这里我们对比三种方式:
微服务中,我们常常会遇到需要把一个微服务中生产的消息,通知给其他消费者的场景。这里我们对比三种方式:

A:强依赖方式

Expand All @@ -74,7 +74,7 @@ B:半解耦方式

B:完全解耦方式

这种方式下,消费者不需要引入SDK订阅Broker,只需要按照自己的业务领域模型设计API,消息服务会将上游的事件,过滤并转换成API需要的事件格式。既没有调用链路上的依赖,也没有业务上的依赖。当上游生产者的事件数据格式发生变化时,消息服务会做兼容性校验,可以拒绝生产者发送事件或则进行告警
这种方式下,消费者不需要引入SDK订阅Broker,只需要按照自己的业务领域模型设计API,消息服务会将上游的事件,过滤并转换成API需要的事件格式。既没有调用链路上的依赖,也没有业务上的依赖。当上游生产者的事件数据格式发生变化时,消息服务会做兼容性校验,可以拒绝生产者发送事件或者进行告警


![image](../picture/07eventbridge/ThreeStages.png)
Expand All @@ -85,7 +85,7 @@ B:完全解耦方式
![image](../picture/07eventbridge/EventCenter.png)

## RocketMQ EventBridge 是如何工作的?
为了解决上述两个应用场景中提到的问题,EventBridge从5个方便入手
为了解决上述两个应用场景中提到的问题,EventBridge从以下5个方面入手

**第1. 确定事件标准:**
因为事件不是给自己看的,而是给所有人看的。它没有明确的消费者,所有都是潜在的消费者。所以,我们需要规范化事件的定义,让所有人都能看得懂,一目了然。目前CNCF旗下的CloudEvent,以逐渐成为广泛的事实标准,因此,我们选取了CloudEvent 作为我们的EventBridge的事件标准。
Expand All @@ -97,9 +97,9 @@ B:完全解耦方式
事件格式用来描述事件的具体内容。这相当于市场经济的一个买卖契约。生产者发送的事件格式是什么,得确定下来,不能总是变;消费者以什么格式接收事件也得确定下来,不然整个市场就乱套了。

**第4. 订阅"规则":**
我们得给消费者一个,把投递事件到目标端的能力,并且投递前可以对事件进行过滤和转换,让它可以适配目标端API接收参数的格式,我们把这个过程叫做创建订阅规则。
我们得给消费者一个,把事件投递到目标端的能力,并且投递前可以对事件进行过滤和转换,让它可以适配目标端API接收参数的格式,我们把这个过程叫做创建订阅规则。

**第5. 事件总线:**
最后我们还得有一个存储事件的地方,就是最图中最中间的事件总线
最后我们还得有一个存储事件的地方,就是下图中最中间的事件总线

![image](../picture/07eventbridge/HowEventBridgeWork.png)
![image](../picture/07eventbridge/HowEventBridgeWork.png)
13 changes: 10 additions & 3 deletions docs/08-mqtt/02RocketMQMQTTQuickStart.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,12 +21,12 @@ git clone https://github.com/apache/rocketmq-mqtt
cd rocketmq-mqtt
mvn -Prelease-all -DskipTests clean install -U
cd distribution/target/
cd bin
sh mqtt.sh start
```

## 配置说明

源码构建完成后,编辑conf/service.conf,完成MQTT相关配置,如下

```text
username=xxx // 权限验证账户配置
secretKey=xxx // 权限验证账户配置
Expand All @@ -35,7 +35,14 @@ eventNotifyRetryTopic=xx //notify重试topic,提前创建
clientRetryTopic=xx //客户端消息重试topic,提前创建
```

其他启动配置参考项目[README.md](https://github.com/apache/rocketmq-mqtt/blob/main/README.md)
还有其他更详细的配置和前置步骤参考 [README.md](https://github.com/apache/rocketmq-mqtt/blob/main/README.md)

最后先启动meta服务(MQTT的元数据中心),再启动mqtt broker 。进入distribution/target/bin 目录,启动进程。

```text
sh meta.sh start
sh mqtt.sh start
```

## 示例说明

Expand Down
14 changes: 7 additions & 7 deletions docs/10-connect/01RocketMQ Connect Overview.md
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
# RocketMQ Connect 概览

RocketMQ Connect是RocketMQ数据集成重要组件,可将各种系统中的数据通过高效,可靠,流的方式,流入流出到RocketMQ,它是独立于RocketMQ的一个单独的分布式,可扩展可容错系统,
它具备低延时,高可靠性,高性能,低代码,扩展性强等特点,可以实现各种异构数据系统的连接,构建数据管道,ETL,CDC,数据湖等能力。
RocketMQ Connect是RocketMQ数据集成重要组件,可将各种系统中的数据通过高效,可靠,流的方式,流入流出到RocketMQ,它是独立于RocketMQ的,一个单独的分布式、可扩展可容错系统,
它具备低延时,高可靠性,高性能,低代码,扩展性强等特点,可以实现各种异构数据系统的连接,以及构建数据管道,ETL,CDC,数据湖等能力。


![RocketMQ Connect Overview](../picture/32rocketmq-connect/overview.png)
Expand All @@ -16,24 +16,24 @@ RocketMQ Connect是一个独立的的分布式,可伸缩,容错的系统,

![RocketMQ Connect使用场景](../picture/32rocketmq-connect/scene.png)

在业务系统中,利用MySQL完善的事务支持,处理数据的增删改,使用ElasticSearch,Solr等实现强大的搜索能力,或者将产生的业务数据同步到数据分析系统,数据湖中(例如hudi),对数据进一步处理从而让数据产生更高的价值。使用RocketMQ Connect很容易实现这样的数据管道的能力,只需要配置3个任务,第一个从MySQL获取数据的任务,第二,三个是从RocketMQ消费数据到ElasticSearch,Hudi的任务,配置3个任务就实现了从MySQL到ElasticSearch,MySQL到hudi的两条数据管道,既可以满足业务中事务的需求,搜索的需求,又可以构建数据湖
在业务系统中,利用MySQL完善的事务支持,处理数据的增删改,使用ElasticSearch,Solr等实现强大的搜索能力,或者将产生的业务数据同步到数据分析系统,数据湖中(例如hudi),对数据进一步处理从而让数据产生更高的价值。使用RocketMQ Connect很容易实现这样的数据管道的能力,只需要配置3个任务,第一个是从MySQL获取数据的任务,第二,三个是从RocketMQ消费数据到ElasticSearch,Hudi的任务,配置3个任务就实现了从MySQL到ElasticSearch,MySQL到hudi的两条数据管道,既可以满足业务对事务、搜索的需求,也可以用于构建数据湖

##### CDC

CDC作为ETL模式之一,可以通过近乎实时的增量捕获数据库的 INSERT、UPDATE,DELETE变化,RocketMQ Connect流试数据传输,具备高可用,低延时等特性,通过Connector很容易实现CDC。
CDC作为ETL模式之一,可以近乎实时的捕获增量数据库INSERT、UPDATE,DELETE变化,RocketMQ Connect流式数据传输,具备高可用,低延时等特性,通过Connector很容易实现CDC。

### Connector 部署

在创建Connector时,一般是通过配置完成的,Connector一般包含逻辑的Connector连接器和执行数据复制的Task即物理线程,如下图所示,两个Connector连接器和它们对应的运行Task任务。
创建Connector,一般通过配置即可完成,Connector包含逻辑的Connector连接器和执行数据复制的Task(即物理线程),如下图所示,两个Connector连接器和它们对应的运行Task任务。

![RocketMQ Connect任务模型1](../picture/32rocketmq-connect/deploy1.png)

一个Connector也可以同时运行多个任务,提高Connector的并行度,例如下图所示的Hudi Sink Connector有2个任务,每个任务处理不同的分片数据,从而Connector的并行度,进而提高处理性能。
一个Connector也可以同时运行多个任务,提高Connector的并行度,例如下图所示的Hudi Sink Connector有2个任务,每个任务处理不同的分片数据,从而提高Connector的并行度,进而提高处理性能。

![RocketMQ Connect任务模型2](../picture/32rocketmq-connect/deploy2.png)

RocketMQ Connect Worker支持两种运行模式,集群和单机
集群模式,顾名思义,有多个Worker节点组成,推荐最少有2个Worker节点,组成高可用集群。集群间的配置信息,offset信息,status信息通过指定RocketMQ Topic存储,新增Worker节点也会获取到集群中的这些配置,offset,status信息,并且触发负载均衡,重新分配集群中的任务,使集群达到均衡的状态,减少Woker节点或者Worker宕机也会触发负载均衡,从而保障集群中所有的任务都可以均衡的在集群中存活的节点中正常运行。
集群模式,顾名思义,由多个Worker节点组成,推荐最少有2个Worker节点,组成高可用集群。集群间的配置信息,offset信息,status信息则通过指定的RocketMQ Topic进行存储,新增Worker节点也会获取到集群中的这些配置,offset,status信息,并且触发负载均衡,重新分配集群中的任务,使集群达到均衡的状态,减少Woker节点或者Worker宕机也会触发负载均衡,从而保障集群中所有的任务都可以均衡的在集群中存活的节点中正常运行。

![RocketMQ Connect部署模型集群](../picture/32rocketmq-connect/deploy3.png)

Expand Down
4 changes: 2 additions & 2 deletions docs/11-contributionGuide/02code-guidelines.md
Original file line number Diff line number Diff line change
Expand Up @@ -18,9 +18,9 @@

1. 文件位置:源码 ```rocketmq/style``` 目录下 ```rmq_codeStyle.xml```

2. Apple OS 导入:```IntelliJ IDEA > Settings > Code Style ``` 。进入 ```Code Style``` 标签页,依次选择 ```Manage > Import``` ,导入文件并命名 ```Scheme```
2. Apple OS 导入:```IntelliJ IDEA > Settings > Editor > Code Style ``` 。进入 ```Code Style``` 标签页,依次选择 ```Manage > Import``` ,导入文件并命名 ```Scheme```

3. Windows OS 导入:```IntelliJ IDEA > Settings > Code Style > Import Scheme```
3. Windows OS 导入:```IntelliJ IDEA > Settings > Editor > Code Style > Import Scheme```

![1656682140788](../picture/02code-guidelines/1_codestyle.png)

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -14,7 +14,7 @@
| 集群 | 集群分布,broker 配置、运行信息 |
| 主题 | 搜索、筛选、删除、更新/新增主题,消息路由,发送消息,重置消费位点 |
| 消费者 | 搜索、删除、新增/更新消费者组,终端,消费详情,配置 |
| 消息 | 消息记录,私信消息,消息轨迹等消息详情 |
| 消息 | 消息记录,死信消息,消息轨迹等消息详情 |

操作面板:

Expand Down
10 changes: 5 additions & 5 deletions versioned_docs/version-5.0/05-deploymentOperations/05Exporter.md
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,7 @@ rocketmq-expoter 项目启动后,会获取 rocketmq 的各项 metrics 收集

浏览器通过访问 ip:5557/metrics,会调用 RMQMetricsController 类下的 metrics 方法,其中 ip 为 rocketmq-expoter 项目运行的主机 ip

```javascript
```java
private void metrics(HttpServletResponse response) throws IOException {
StringWriter writer = new StringWriter();
metricsService.metrics(writer);
Expand Down Expand Up @@ -64,7 +64,7 @@ MetricCollectTask 类中有 5 个定时任务,分别为 collectTopicOffset、c
1. 首先初始化TopicList对象,通过mqAdminExt.fetchAllTopicList()方法获取到集群的所有topic信息。


```javascript
```java
TopicList topicList = null;
try { topicList = mqAdminExt.fetchAllTopicList();
} catch (Exception ex) {
Expand All @@ -76,7 +76,7 @@ MetricCollectTask 类中有 5 个定时任务,分别为 collectTopicOffset、c

2. 将 topic 加入到 topicSet 中,循环遍历每一个 topic,通过 mqAdminExt.examineTopicStats(topic)函数来检查 topic 状态。

```javascript
```java
Set < String > topicSet = topicList != null ? topicList.getTopicList() : null;
for (String topic: topicSet) {
TopicStatsTable topicStats = null;
Expand All @@ -91,7 +91,7 @@ MetricCollectTask 类中有 5 个定时任务,分别为 collectTopicOffset、c

3. 初始化 topic 状态 set,用于用于按 broker 划分的 topic 信息位点的 hash 表 brokerOffsetMap,以及一个用于按 broker 名字为 key 的用于存储更新时间戳的 hash 表 brokerUpdateTimestampMap。

```javascript
```java
Set<Map.Entry<MessageQueue, TopicOffset>> topicStatusEntries = topicStats.getOffsetTable().entrySet();
HashMap<String, Long> brokerOffsetMap = new HashMap<>();
HashMap<String, Long> brokerUpdateTimestampMap = new HashMap<>();
Expand All @@ -117,7 +117,7 @@ MetricCollectTask 类中有 5 个定时任务,分别为 collectTopicOffset、c

4. 最后通过遍历 brokerOffsetMap 中的每一项,通过调用 metricsService 获取到 metricCollector 对象,调用 RMQMetricsCollector 类中的 addTopicOffsetMetric 方法,将相应的值添加到 RMQMetricsCollector 类中 87 个指标对应的其中一个指标的 cache 中。

```javascript
```java
Set<Map.Entry<String, Long>> brokerOffsetEntries = brokerOffsetMap.entrySet();
for (Map.Entry<String, Long> brokerOffsetEntry : brokerOffsetEntries) {
metricsService.getCollector().addTopicOffsetMetric(clusterName, brokerOffsetEntry.getKey(), topic,
Expand Down
Loading