Optimization 01RocketMQConnectOverview.md and 02RocketMQEventBridgeOv…

…erview.md description (#601) * Update 01RocketMQ Connect Overview.md 优化文档内容 * Update 01RocketMQ Connect Overview.md * Update 01RocketMQ Connect Overview.md * update 02RocketMQEventBridgeOverview.md 优化不通顺的地方、以及打错的部分
apache · Nov 16, 2023 · 5816f96 · 5816f96
1 parent 39d5fd2
commit 5816f96
Show file tree

Hide file tree

Showing 2 changed files with 10 additions and 10 deletions.
diff --git a/versioned_docs/version-5.0/07-eventbridge/02RocketMQEventBridgeOverview.md b/versioned_docs/version-5.0/07-eventbridge/02RocketMQEventBridgeOverview.md
@@ -35,7 +35,7 @@ Event，则是明确已经发生的事情。比如
 
 ### 2、无期望
 ```text
-事件是客观的描述一个事物的状态或属性值的变化，但对于如何处理事件本身并没有做任何期望。 相比之下，Command和Query则都是有期望的，他们希望系统做出改变或则返回结果，但是Event只是客观描述系统的一个变化。
+事件是客观的描述一个事物的状态或属性值的变化，但对于如何处理事件本身并没有做任何期望。 相比之下，Command和Query则都是有期望的，他们希望系统做出改变或者返回结果，但是Event只是客观描述系统的一个变化。
 ```
 举个例子： 交通信号灯，从绿灯变成黄灯，只是描述了一个客观事实，本身并没有客观期望。在不同国家地区，对这个事件赋予了不同的期望。 比如，在日本黄灯等于红灯，而在俄罗斯闯黄灯是被默许的。
 
@@ -62,7 +62,7 @@ Event，则是明确已经发生的事情。比如
 对比我们常见的消息，因为上下游一般是确定的，常常为了性能和传输效率，则会做到尽可能的精简，只要满足“计划经济”指定安排的消费者需求即可。
 ## RocketMQ EventBridge 的典型应用场景
 ### 场景1：事件通知
-微服务中，我们常常会遇到需要把一个微服务中生产的消息，通知给其他消费者。这里我们对比三种方式：
+微服务中，我们常常会遇到需要把一个微服务中生产的消息，通知给其他消费者的场景。这里我们对比三种方式：
 
 A：强依赖方式
 
@@ -74,7 +74,7 @@ B：半解耦方式
 
 B：完全解耦方式
 
-这种方式下，消费者不需要引入SDK订阅Broker，只需要按照自己的业务领域模型设计API，消息服务会将上游的事件，过滤并转换成API需要的事件格式。既没有调用链路上的依赖，也没有业务上的依赖。当上游生产者的事件数据格式发生变化时，消息服务会做兼容性校验，可以拒绝生产者发送事件或则进行告警。
+这种方式下，消费者不需要引入SDK订阅Broker，只需要按照自己的业务领域模型设计API，消息服务会将上游的事件，过滤并转换成API需要的事件格式。既没有调用链路上的依赖，也没有业务上的依赖。当上游生产者的事件数据格式发生变化时，消息服务会做兼容性校验，可以拒绝生产者发送事件或者进行告警。
 
 
 ![image](../picture/07eventbridge/ThreeStages.png)
@@ -85,7 +85,7 @@ B：完全解耦方式
 ![image](../picture/07eventbridge/EventCenter.png)
 
 ## RocketMQ EventBridge 是如何工作的？
-为了解决上述两个应用场景中提到的问题，EventBridge从5个方便入手：
+为了解决上述两个应用场景中提到的问题，EventBridge从以下5个方面入手：
 
 **第1. 确定事件标准：**
 因为事件不是给自己看的，而是给所有人看的。它没有明确的消费者，所有都是潜在的消费者。所以，我们需要规范化事件的定义，让所有人都能看得懂，一目了然。目前CNCF旗下的CloudEvent,以逐渐成为广泛的事实标准，因此，我们选取了CloudEvent 作为我们的EventBridge的事件标准。

diff --git a/versioned_docs/version-5.0/10-connect/01RocketMQ Connect Overview.md b/versioned_docs/version-5.0/10-connect/01RocketMQ Connect Overview.md
@@ -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)
@@ -16,15 +16,15 @@ 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)
 
@@ -33,7 +33,7 @@ CDC作为ETL模式之一，可以通过近乎实时的增量捕获数据库的 I
 ![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)