You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@shardingsphere.apache.org by du...@apache.org on 2022/06/28 01:53:42 UTC
[shardingsphere] branch master updated: update read-write-split doc (#18641)
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 <ch...@qq.com>
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)