diff --git "a/pangu-website/docs/advanced-guide/\346\225\260\346\215\256\346\262\273\347\220\206\344\271\213\346\225\260\346\215\256\345\210\206\347\211\207.md" "b/pangu-website/docs/advanced-guide/\346\225\260\346\215\256\346\262\273\347\220\206\344\271\213\346\225\260\346\215\256\345\210\206\347\211\207.md"
index d39b2de57ed913877d301e33c327942b00b62a89..42c0417839ded51c9619f261c242f8af34fb1c9f 100644
--- "a/pangu-website/docs/advanced-guide/\346\225\260\346\215\256\346\262\273\347\220\206\344\271\213\346\225\260\346\215\256\345\210\206\347\211\207.md"
+++ "b/pangu-website/docs/advanced-guide/\346\225\260\346\215\256\346\262\273\347\220\206\344\271\213\346\225\260\346\215\256\345\210\206\347\211\207.md"
@@ -22,26 +22,34 @@ import TabItem from '@theme/TabItem';
因此，通过数据分片将存放在单一库中的数据分散至多个库或表中以达到提升性能、提高可用性和降低运维成本的效果。数据分片的有效手段是对数据库进行分库和分表。分库和分表均可以有效的避免由数据量超过可承受阈值而产生的查询瓶颈，同时也是应对高并发和海量数据系统的有效手段。
### 数据分片类型
-数据分片可分为垂直分片和水平分片。如下图所示。
+数据分片可分为垂直分片和水平分片。
-.default})
-
#### 垂直分片
-垂直分片是按照业务域将数据库纵向切分为不同业务专门使用的相对小库。如电商系统的用户库、订单库、会员库、仓储库、账户库等。垂直拆分可以一定程度缓解数据量和并发量带来的问题，但无法根治。如果垂直拆分之后，表中的数据量依然超过单节点所能承载的阈值，则需要水平分片来进一步处理。
+垂直分片是按照业务域将数据库纵向切分为不同的数据库。如电商系统的用户库、订单库、会员库、仓储库、账户库等。垂直拆分可以缩库但无法缩表，即可以减小单节点下数据库数据量，但每个数据表里面的数据量是没有变化的；垂直拆分可以一定程度降低单节点数据库的负载，但是每个数据表的并发压力依旧没变。
#### 水平分片
-水平分片又称为横向拆分。相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或多个表中。例如：根据主键分片，偶数主键的记录放入 db_0（或 table_0），奇数主键的记录放入 db_1（或table_1）。
+水平分片又称为横向拆分。相对于垂直分片，它不再将数据根据业务逻辑分类，而是通过某个字段（或某几个字段），根据某种规则将数据分散至多个库或多个表中。水平分片从理论上突破了单机数据量处理的瓶颈，并且扩展相对自由，是数据分片的标准解决方案。水平分片从具体实现上又可以分为3种：**只分表**、**只分库**、**分库分表**。如下图所示。
+.default})
### 数据分片后面临的问题
-对于一般的简单理解，读写分离就是 DQL 请求走从库，DML 请求走主库。但对于开发人员而言，在实际开发中还需要考虑如下问题。
-- **主从数据同步延迟问题**
-因为我们主从同步是异步复制的，不可避免的会有延迟。因此有可能出现 mastre 节点已经写入，但是从 slave 节点读取不到数据的问题。解决方法见后续章节：[读操作强制走主库](#读操作强制走主库) 和 [事务方法里的所有读写操作都自动走主库](#事务方法里的所有读写操作都自动走主库)。
+虽然数据分片解决了性能、可用性以及单点备份恢复等问题，但分布式的架构在获得了收益的同时，也引入了新的问题。
+
+- 面对如此散乱的分片之后的数据，应用开发工程师和数据库管理员对数据库的操作变得异常繁重就是其中的重要挑战之一。他们需要明确知道数据从哪写入，从哪读取。
+- 数据分片后势必会带来分布式事务的处理。能够优雅的处理好分布式事务，这对开发而言也是一个全新的挑战。（分布式事务处理跨参考：[盘古框架分布式事务最佳实践](/docs/advanced-guide/distributed-transaction)）
+- 数据库请求路由至多数据节点的时候，部分SQL支持不完整或性能损耗较大的问题。
-- **事务问题**
-如果一个事务方法里既包含有 DML 请求也有 DQL 请求，如果读请求走从库写请求走主库的话，则势必会带来分布式事务的问题。但对于大部分读写分离场景而言，很显然我们并不希望为了读写分离而去处理分布式事务的问题。因此对于读写分离，恰当的做法是将事务方法中的所有 SQL 请求统一都走主库，将跨库的分布式事务转为本地事务来处理。见后续章节：[事务方法里的所有读写操作都自动走主库](#事务方法里的所有读写操作都自动走主库)。（如果对于分布式场景下的分布式事务问题的处理感兴趣，可以参考：[盘古框架分布式事务最佳实践](/docs/advanced-guide/distributed-transaction)）
+### 数据分片的几个原则
+- 需综合权衡业务场景、客观估算数据分片性价比，不要盲目分片。数据分片在获得收益的同时，也引入了新的问题。
+- 分片参考临界值：一般来讲 MySQL单表记录控制在 1000 万以内、数据库单实例数据大小控制在 1 TB 以内是比较合理的范围。
+- 分表不分库仅涉及本地事务，垂直分片和水平分片的分库分表均会带来分布式事务。设计过程应考虑不要人为扩大没必要的分布式事务使用边界。
+- 分片键的规划尤为重要，需要结合业务特点来精心设计。
+- 以尽量单表查询的原则设计分片逻辑。
+- 对于大型应用来说，垂直分片和水平分片一定是联合使用的。但对于一些中小型应用而言，可以只采用水平分片（分库分表或只分表）。
+
+总之，采用什么样的数据架构需要结合**性能诉求**、**可用性**、**运维成本**、**开发成本**、**项目背景**和**业务场景**等方面来做权衡选择。上述仅为一些孤立的参考原则。
### 相关专业术语
@@ -49,6 +57,8 @@ import TabItem from '@theme/TabItem';
- **从库**：数据 DQL 读操作（select）使用的数据库。可支持多从库。
- **主从同步**：将主库数据同步到从库的操作。依赖数据库自身的同步机制，比如：MySQL 基于 binlog 的异步复制。
+
+
## 读写分离实现原理
实现读写分离大致有 3 种方案。如下图所示。