当数据库性能呈现瓶颈时就须要通过扩大来晋升性能，对于扩展性来说要么增强机器自身的性能，要么把工作散发到不同的机器上。对于数据库来说通过强悍的机器解决老本是很大的，如 Oracle。通过多个便宜的机器实现程度扩大是古代的支流解决方案，如 Mysql。
数据库程度扩大的外围是把数据拆分成不同的单元并放在不同的独立的实例上，这样就做到了负载平衡。拆分分为逻辑和物理拆分，逻辑拆分是对物理上不可分割的实例进行逻辑上的宰割，物理拆分是拆分成多个独立的实例：
-
逻辑拆分
- 分区（Partition）
- 分表
-
物理拆分
- 读写拆散
- 垂直拆分（分库）
- 程度拆分（分表）
1. 逻辑拆分
1.1 分区
我了解的逻辑分区：举个例子，操作系统中的分区，是将硬盘依据大小进行逻辑分区，就是咱们看到的 C、D、E、F 盘，逻辑分区还是在同一个操作系统中。数据库产品的 Partition 分区也是一样的情理，将数据进行逻辑分区，对数据划分界线。
MySql 反对 Range，List，Hash，Key。最罕用的是 Range。_留神不同的版本对分区类型的反对有些不同！_
Range：范畴
CREATE TABLE employees (
id INT NOT NULL,
fname VARCHAR(30),
lname VARCHAR(30),
hired DATE NOT NULL DEFAULT '1970-01-01',
separated DATE NOT NULL DEFAULT '9999-12-31',
job_code INT NOT NULL,
store_id INT NOT NULL
)
PARTITION BY RANGE (store_id) (PARTITION p0 VALUES LESS THAN (6),
PARTITION p1 VALUES LESS THAN (11),
PARTITION p2 VALUES LESS THAN (16),
PARTITION p3 VALUES LESS THAN (21)
);
LIST：列表
CREATE TABLE employees (
id INT NOT NULL,
fname VARCHAR(30),
lname VARCHAR(30),
hired DATE NOT NULL DEFAULT '1970-01-01',
separated DATE NOT NULL DEFAULT '9999-12-31',
job_code INT,
store_id INT
)
PARTITION BY LIST(store_id) (PARTITION pNorth VALUES IN (3,5,6,9,17),
PARTITION pEast VALUES IN (1,2,10,11,19,20),
PARTITION pWest VALUES IN (4,12,13,14,18),
PARTITION pCentral VALUES IN (7,8,15,16)
);
Key：键
CREATE TABLE k1 (
id INT NOT NULL,
name VARCHAR(20),
UNIQUE KEY (id)
)
PARTITION BY KEY()
PARTITIONS 2;
HASH：哈希
CREATE TABLE employees (
id INT NOT NULL,
fname VARCHAR(30),
lname VARCHAR(30),
hired DATE NOT NULL DEFAULT '1970-01-01',
separated DATE NOT NULL DEFAULT '9999-12-31',
job_code INT,
store_id INT
)
PARTITION BY HASH(YEAR(hired) )
PARTITIONS 4;
例子：
数据：新闻表，2010 开始记录，假如 10 年到 15 年每年的数据为 200W，总数 1000W；
条件：查问 15 年 7 月所有的新闻数据；
未分区：须要把表遍历，1000W 条数据，查问性能就不用说了；
分区：依照年份分区，当要查问 15 年数据，只会遍历 15 年的数据 200W 条，放慢了查问；
1.2 分表
当单表数据行数超过一定量级时，读 / 写 会变慢，查问须要检索更多数据，DML 操作须要更多工夫创立 / 更新索引；咱们能够通过把这些数据扩散到多个表中来提高效率，这样只波及到局部数据而不是所有，最罕用的分表算法是哈希算法。哈希函数应用除留余数法，即取余的形式。
建设所须要的 N 个表，表名：user_0 … user_N-1，通过对 ID 取余运算间接路由到所在的表
- user_0：5%5
- user_1：1%5 / 6%5
- user_2：2%5
- user_3：3%5
- user_4：4%5
小结：逻辑分区是数据库提供的性能，不必对利用和业务做任何扭转就能实现。哈希分表实现简略，只须要批改大量代码就能实现。对单表进行分表后，可能大大提高咱们读写的效率。
2. 物理拆分
2.1 读写拆散（主从复制）
读写拆散的外围是把读 / 写操作路由的不同实例上，实例之间要的数据要保障统一（通过复制实现），路由能够本人辨认 Insert/Update/Delete/Selete 做路由，也能够应用代理 (mysql proxy) 或中间件。
个别站点的读操作比写操作更加密集，查问量暴增的时候单台服务器无奈解决这么多读操作，咱们须要减少额定的服务器来撑持，应用主从形式，主做写操作，从做读操作，通过主从复制达到数据一致性，这样读操作压力会被扩散。mysql 应用单线程把主机数据复制到从机上实现数据一致性，所以须要对主从进行配置。
在下面的主从架构中，如果从库有很多个可能会呈现复制提早过大景象，起因是因为 mysql 复制须要在 slave 和 master 建设长连贯，并且 master 须要开启 binlog dump 线程进行数据推送，过多的 slave 会导致复制提早过大。能够 减少复制源 和开启 半同步复制 解决。
1. 减少复制源：
2. 开启半同步复制：主库提交事务时，将事件写入它的二进制日志，而从库在准备就绪时申请它们。主库无需期待从库的 ACK 回复，间接提交事务并返回客户端。异步复制不确保所有事件都能达到从库，无奈保障数据完整性
2.2 垂直拆分（分库）
读写拆散不能解决写操作频繁带来的性能瓶颈，比方主库写操作占 80%，这时须要把写操作拆分到独立的实例上，垂直拆分 是依照业务相关度把数据拆分到不同的 DB 上，这样写操作天然就被拆分开来。
拆分了之后还能够持续做读写拆散进一步晋升性能，但 垂直拆分也带来了问题，本来在一个事务中的数据操作，在拆分之后就无奈在同一个事务中实现，这使得咱们业务利用须要额定的老本去解决，如通过引入分布式事务 或 最终统一来解决。
2.3 程度拆分（分表）
对数据库做了垂直切分和读写拆散能够解决大部分站点的问题，然而在体量微小的利用中主数据库写操作压力仍然会达到极限，这时须要对表进行程度拆分并散布在不同机器下面。
程度拆分最简略的形式就是用哈希算法，一个表只能依据一个字段 sharding。上面列举了一些罕用的拆分办法：
1. 简略 hash 算法
建设所须要的 N 个表，表名：user_0 … user_N-1，通过对 ID 取余运算间接路由到所在的表：
- user_0：5%5
- user_1：1%5 / 6%5
- user_2：2%5
- user_3：3%5
- user_4：4%5
长处：
- 查问分片地位的工夫复杂度为 O(1)，简略无效。
毛病：
- 动静扩容有局限：当容量有余须要减少分片数量来扩容，哈希值会产生扭转，波及全量数据迁徙。
- 热点数据集中：沉闷用户分到了同一个片上，这个实例压力十分大可能会过载。
2. 一致性 hash 算法
在扩容时简略 hash 算法须要全量数据迁徙老本和危险很高，一致性 hash 算法对该算法进行了优化，通过对固定值 2^32- 1 进行取余保障 hash 后果不变，再通过范畴把环拆分成 N 份，减少节点时只影响新节点到逆时针第一个节点之间的数据。
整体扩容 ：如果分片数量有余须要扩容，因为要保障数据分布平均，所以受影响的节点会 占总量的一半。
部分扩容：一致性 hash 通过在部分减少节点实现灵便扩容，而不用每次都翻倍扩容，能够对 热点数据表进行再拆分，只影响新节点到逆时针第一个节点之间的数据，然而须要额定再保护映射表保障其余节点还映射到旧表。
长处：
- 能够灵便抉择部分还是整体扩容，部分扩容能够对某个热点数据的节点再拆分而不影响其余节点。
毛病：
- 在节点过多的状况下查问效率较低，表映射实现简单。
3. 动静映射
热点数据集中 可能是因为某个 ID 产生的数据过多造成的，通过配置指定到具体的分片上能够过热问题。
长处：能够做部分扩容解决热点数据问题。
毛病：实现比较复杂，每次都须要查问获取对应分片性能比简答 hash 差，会影响查问效率。
2.4 拆分带来的问题
物理拆分带来益处的同时也带来的一些问题：
-
跨库事务
- 通过分布式事务 或 最终统一解决
-
跨库 Join
- 把 Join 操作拆分成屡次查问并在利用中做聚合
- 应用搜索引擎做数据聚合和查问
- 应用 CQRS 做数据聚合
-
跨表分页和排序：
- 由中间件去所有分片聚合数据，再做分页和排序
接下来讲一下 CQRS 是怎么做的。
CQRS 是对利用做读写职责拆散，每次写操作都会以相似日志的模式记录在 Event Store 中，并不是间接批改字段值到期望值，再由 Event Bus 把事件同步到读服务，读服务对读库数据进行批改，所有查问都会走读服务。在该架构模式中读服务能够把想要的业务数据聚合到读库中，其实就是通过冗余数据的形式防止利用去多库中查问和聚合数据，以空间换工夫。