This is an automated email from the ASF dual-hosted git repository.
duanzhengqiang pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/shardingsphere.git
The following commit(s) were added to refs/heads/master by this push:
new 9a49ab895d5 update read-write-split doc (#18641)
9a49ab895d5 is described below
commit 9a49ab895d5159a94c8463e7d0ec524e80cec77e
Author: Chuxin Chen <[email protected]>
AuthorDate: Tue Jun 28 09:53:36 2022 +0800
update read-write-split doc (#18641)
---
.../features/readwrite-splitting/_index.cn.md | 44 +++++++++++-------
.../features/readwrite-splitting/_index.en.md | 52 +++++++++++++---------
.../features/readwrite-splitting/concept.cn.md | 43 ------------------
.../features/readwrite-splitting/concept.en.md | 48 --------------------
4 files changed, 59 insertions(+), 128 deletions(-)
diff --git a/docs/document/content/features/readwrite-splitting/_index.cn.md
b/docs/document/content/features/readwrite-splitting/_index.cn.md
index 9525f428afb..7705a5bd117 100644
--- a/docs/document/content/features/readwrite-splitting/_index.cn.md
+++ b/docs/document/content/features/readwrite-splitting/_index.cn.md
@@ -5,31 +5,41 @@ weight = 6
chapter = true
+++
-## 背景
+## 定义
-面对日益增加的系统访问量，数据库的吞吐量面临着巨大瓶颈。
-对于同一时刻有大量并发读操作和较少写操作类型的应用系统来说，将数据库拆分为主库和从库，主库负责处理事务性的增删改操作，从库负责处理查询操作，能够有效的避免由数据更新导致的行锁，使得整个系统的查询性能得到极大的改善。
+读写分离也就是将数据库拆分为主库和从库，即主库负责处理事务性的增删改操作，从库负责处理查询操作的数据库架构。
-通过一主多从的配置方式，可以将查询请求均匀的分散到多个数据副本，能够进一步的提升系统的处理能力。
-使用多主多从的方式，不但能够提升系统的吞吐量，还能够提升系统的可用性，可以达到在任何一个数据库宕机，甚至磁盘物理损坏的情况下仍然不影响系统的正常运行。
+## 相关概念
-与将数据根据分片键打散至各个数据节点的水平分片不同，读写分离则是根据 SQL 语义的分析，将读操作和写操作分别路由至主库与从库。
+### 主库
+添加、更新以及删除数据操作所使用的数据库，目前仅支持单主库。
-
+### 从库
+查询数据操作所使用的数据库，可支持多从库。
-读写分离的数据节点中的数据内容是一致的，而水平分片的每个数据节点的数据内容却并不相同。将水平分片和读写分离联合使用，能够更加有效的提升系统性能。
+### 主从同步
+将主库的数据异步的同步到从库的操作。 由于主从同步的异步性，从库与主库的数据会短时间内不一致。
-## 挑战
+### 负载均衡策略
+通过负载均衡策略将查询请求疏导至不同从库。
-读写分离虽然可以提升系统的吞吐量和可用性，但同时也带来了数据不一致的问题。
-这包括多个主库之间的数据一致性，以及主库与从库之间的数据一致性的问题。
-并且，读写分离也带来了与数据分片同样的问题，它同样会使得应用开发和运维人员对数据库的操作和运维变得更加复杂。
-下图展现了将数据分片与读写分离一同使用时，应用程序与数据库集群之间的复杂拓扑关系。
+## 对系统的影响
+用户的系统中可能存在着复杂的主从关系数据库集群，因此应用程序需要接入多个数据源，这种方式就增加了系统维护的成本和业务开发的难度。ShardingSphere
通过读写分离功能，可以让用户像使用一个数据库一样去使用数据库集群，透明化读写分离带来的影响。
-
+## 使用限制
+* 不处理主库和从库的数据同步
+* 不处理主库和从库的数据同步延迟导致的数据不一致
+* 不支持主库多写
+* 不处理主从库间的事务一致性。主从模型中，事务中的数据读写均用主库。
-## 目标
+## 原理介绍
+ShardingSphere 的读写分离主要依赖内核的相关功能。包括解析引擎和路由引擎。解析引擎将用户的 SQL 转化为 ShardingSphere
可以识别的 Statement 信息，路由引擎根据 SQL 的读写类型以及事务的状态来做 SQL 的路由。
+在从库的路由中支持多种负载均衡算法，包括轮询算法、随机访问算法、权重访问算法等，用户也可以依据 SPI
机制自行扩展所需算法。如下图所示，ShardingSphere 识别到读操作和写操作，分别会路由至不同的数据库实例。
-**透明化读写分离所带来的影响，让使用方尽量像使用一个数据库一样使用主从数据库集群，是 Apache ShardingSphere
读写分离模块的主要设计目标。**
+
-**源码：https://github.com/apache/shardingsphere/tree/master/shardingsphere-features/shardingsphere-readwrite-splitting**
+## 相关参考
+[Java
API](/cn/user-manual/shardingsphere-jdbc/java-api/rules/readwrite-splitting)\
+[YAML
配置](/cn/user-manual/shardingsphere-jdbc/yaml-config/rules/readwrite-splitting)\
+[Spring Boot
Starter](/cn/user-manual/shardingsphere-jdbc/spring-boot-starter/rules/readwrite-splitting)\
+[Spring
命名空间](/cn/user-manual/shardingsphere-jdbc/spring-namespace/rules/readwrite-splitting)
diff --git a/docs/document/content/features/readwrite-splitting/_index.en.md
b/docs/document/content/features/readwrite-splitting/_index.en.md
index 8d2b31a4d82..44f91f6e000 100644
--- a/docs/document/content/features/readwrite-splitting/_index.en.md
+++ b/docs/document/content/features/readwrite-splitting/_index.en.md
@@ -5,34 +5,46 @@ weight = 6
chapter = true
+++
-## Background
+## Definition
-Database throughput has faced the bottleneck with increasing TPS.
-For the application with massive concurrence read but less write in the same
time, we can divide the database into a primary database and a replica database.
-The primary database is responsible for the insert, delete and update of
transactions, while the replica database is responsible for queries.
-It can significantly improve the query performance of the whole system by
effectively avoiding row locks.
+Read/write splitting is to split the database into primary and secondary
databases. The primary database is responsible for handling transactional
operations including additions, deletions and changes.
+And the secondary database is responsible for the query operation of database
architecture.
-One primary database with multiple replica databases can further enhance
processing capacity by distributing queries evenly into multiple data replicas.
-Multiple primary databases with multiple replica databases can enhance not
only throughput but also availability.
-Therefore, the system can still run normally, even though any database is down
or physical disk destroyed.
+## Related Concepts
-Different from the sharding that separates data to all nodes according to
sharding keys, readwrite-splitting routes read and write separately to primary
database and replica databases according SQL analysis.
+### Primary database
+The primary database is used to add, update, and delete data operations.
Currently, only single primary database is supported.
-
+### Secondary database
+The secondary database is used to query data operations and multi-secondary
databases are supported.
-Data in readwrite-splitting nodes are consistent, whereas that in shards is
not.
-The combined use of sharding and readwrite-splitting will effectively enhance
the system performance.
+### Primary-Secondary synchronization
+It refers to the operation of asynchronously synchronizing data from a primary
database to a secondary database. Due to the asynchronism of primary-secondary
synchronization,
+data from the primary and secondary databases may be inconsistent for a short
time.
-## Challenges
+### Load balancer policy
+Channel query requests to different secondary databases through load balancer
policy.
-Though readwrite-splitting can enhance system throughput and availability, it
also brings inconsistent data, including that among multiple primary databases
and among primary databases and replica databases.
-What's more, it also brings the same problem as data sharding, complicating
developer and operator's maintenance and operation.
-The following diagram has shown the complex topological relations between
applications and database groups when sharding used together with
readwrite-splitting.
+## Impact on the System
+There may be complex primary-secondary relational database clusters in users'
systems, so applications need to access multiple data sources, which increases
the cost of system maintenance and the
+difficulty of business development. ShardingSphere enables users to use
database clusters like a database through read/write splitting function, and
the impact of read/write splitting will be transparent to users.
-
+## Limitations
+* Data synchronization of primary and secondary databases is not supported.
+* Data inconsistency resulting from data synchronization delays between
primary and secondary databases is not supported.
+* Multi-write of primary database is not supported.
+* Transactional consistency between primary and secondary databases is not
supported. In the primary-secondary model, both data reads and writes in
transactions use the primary database.
-## Goal
+## How it works
+ShardingSphere's read/write splitting mainly relies on the related functions
of its kernel, including a parsing engine and a routing engine.
+The parsing engine converts the user's SQL into Statement information that can
be identified by ShardingSphere, and the routing engine performs SQL routing
according to the read/write type of SQL and transactional status.
+The routing from the secondary database supports a variety of load balancing
algorithms, including polling algorithm, random access algorithm, weight access
algorithm, etc.
+Users can also expand the required algorithm according to the SPI mechanism.
As shown in the figure below, ShardingSphere identifies read and write
operations and routes them to different database instances respectively.
-**The main design goal of readwrite-splitting of Apache ShardingSphere is to
try to reduce the influence of readwrite-splitting, in order to let users use
primary-replica database group like one database.**
+
-**Source Codes:
https://github.com/apache/shardingsphere/tree/master/shardingsphere-features/shardingsphere-readwrite-splitting**
+## 相关参考
+[Java
API](/en/user-manual/shardingsphere-jdbc/java-api/rules/readwrite-splitting)\
+[YAML
Configuration](/cn/user-manual/shardingsphere-jdbc/yaml-config/rules/readwrite-splitting)\
+[Spring Boot
Starter](/cn/user-manual/shardingsphere-jdbc/spring-boot-starter/rules/readwrite-splitting)\
+[Spring
Namespace](/cn/user-manual/shardingsphere-jdbc/spring-namespace/rules/readwrite-splitting)
diff --git a/docs/document/content/features/readwrite-splitting/concept.cn.md
b/docs/document/content/features/readwrite-splitting/concept.cn.md
deleted file mode 100644
index 7a81cd5bc1e..00000000000
--- a/docs/document/content/features/readwrite-splitting/concept.cn.md
+++ /dev/null
@@ -1,43 +0,0 @@
-+++
-title = "核心特性"
-weight = 1
-+++
-
-## 定义
-
-读写分离也就是将数据库拆分为主库和从库，即主库负责处理事务性的增删改操作，从库负责处理查询操作的数据库架构。
-
-## 相关概念
-
-### 主库
-添加、更新以及删除数据操作所使用的数据库，目前仅支持单主库。
-
-### 从库
-查询数据操作所使用的数据库，可支持多从库。
-
-### 主从同步
-将主库的数据异步的同步到从库的操作。 由于主从同步的异步性，从库与主库的数据会短时间内不一致。
-
-### 负载均衡策略
-通过负载均衡策略将查询请求疏导至不同从库。
-
-## 对系统的影响
-用户的系统中可能存在着复杂的主从关系数据库集群，因此应用程序需要接入多个数据源，这种方式就增加了系统维护的成本和业务开发的难度。ShardingSphere
通过读写分离功能，可以让用户像使用一个数据库一样去使用数据库集群，透明化读写分离带来的影响。
-
-## 使用限制
-* 不处理主库和从库的数据同步
-* 不处理主库和从库的数据同步延迟导致的数据不一致
-* 不支持主库多写
-* 不处理主从库间的事务一致性。主从模型中，事务中的数据读写均用主库。
-
-## 原理介绍
-ShardingSphere 的读写分离主要依赖内核的相关功能。包括解析引擎和路由引擎。解析引擎将用户的 SQL 转化为 ShardingSphere
可以识别的 Statement 信息，路由引擎根据 SQL 的读写类型以及事务的状态来做 SQL 的路由。
-在从库的路由中支持多种负载均衡算法，包括轮询算法、随机访问算法、权重访问算法等，用户也可以依据 SPI
机制自行扩展所需算法。如下图所示，ShardingSphere 识别到读操作和写操作，分别会路由至不同的数据库实例。
-
-
-
-## 相关参考
-[Java
API](/cn/user-manual/shardingsphere-jdbc/java-api/rules/readwrite-splitting)\
-[YAML
配置](/cn/user-manual/shardingsphere-jdbc/yaml-config/rules/readwrite-splitting)\
-[Spring Boot
Starter](/cn/user-manual/shardingsphere-jdbc/spring-boot-starter/rules/readwrite-splitting)\
-[Spring
命名空间](/cn/user-manual/shardingsphere-jdbc/spring-namespace/rules/readwrite-splitting)
diff --git a/docs/document/content/features/readwrite-splitting/concept.en.md
b/docs/document/content/features/readwrite-splitting/concept.en.md
deleted file mode 100644
index adb979c23f6..00000000000
--- a/docs/document/content/features/readwrite-splitting/concept.en.md
+++ /dev/null
@@ -1,48 +0,0 @@
-+++
-title = "Core Feature"
-weight = 1
-+++
-
-## Definition
-
-Read/write splitting is to split the database into primary and secondary
databases. The primary database is responsible for handling transactional
operations including additions, deletions and changes.
-And the secondary database is responsible for the query operation of database
architecture.
-
-## Related Concepts
-
-### Primary database
-The primary database is used to add, update, and delete data operations.
Currently, only single primary database is supported.
-
-### Secondary database
-The secondary database is used to query data operations and multi-secondary
databases are supported.
-
-### Primary-Secondary synchronization
-It refers to the operation of asynchronously synchronizing data from a primary
database to a secondary database. Due to the asynchronism of primary-secondary
synchronization,
-data from the primary and secondary databases may be inconsistent for a short
time.
-
-### Load balancer policy
-Channel query requests to different secondary databases through load balancer
policy.
-
-## Impact on the System
-There may be complex primary-secondary relational database clusters in users'
systems, so applications need to access multiple data sources, which increases
the cost of system maintenance and the
-difficulty of business development. ShardingSphere enables users to use
database clusters like a database through read/write splitting function, and
the impact of read/write splitting will be transparent to users.
-
-## Limitations
-* Data synchronization of primary and secondary databases is not supported.
-* Data inconsistency resulting from data synchronization delays between
primary and secondary databases is not supported.
-* Multi-write of primary database is not supported.
-* Transactional consistency between primary and secondary databases is not
supported. In the primary-secondary model, both data reads and writes in
transactions use the primary database.
-
-## How it works
-ShardingSphere's read/write splitting mainly relies on the related functions
of its kernel, including a parsing engine and a routing engine.
-The parsing engine converts the user's SQL into Statement information that can
be identified by ShardingSphere, and the routing engine performs SQL routing
according to the read/write type of SQL and transactional status.
-The routing from the secondary database supports a variety of load balancing
algorithms, including polling algorithm, random access algorithm, weight access
algorithm, etc.
-Users can also expand the required algorithm according to the SPI mechanism.
As shown in the figure below, ShardingSphere identifies read and write
operations and routes them to different database instances respectively.
-
-
-
-## 相关参考
-[Java
API](/en/user-manual/shardingsphere-jdbc/java-api/rules/readwrite-splitting)\
-[YAML
Configuration](/cn/user-manual/shardingsphere-jdbc/yaml-config/rules/readwrite-splitting)\
-[Spring Boot
Starter](/cn/user-manual/shardingsphere-jdbc/spring-boot-starter/rules/readwrite-splitting)\
-[Spring
Namespace](/cn/user-manual/shardingsphere-jdbc/spring-namespace/rules/readwrite-splitting)
