数据裂变，数据库高可用架构设计实践

★ 针对常见的互联网业务场景进行数据库架构设计总结

1 先导

我们的系统会随着业务的膨胀而越发的复杂，数据基数也会越变得越来越大。

如何在数据变为巨量数据之后，依然保持强有力的稳定性和高效的性能，是系统架构的一个重要的目标，下面我们按照数据架构的演进来阐述变化过程。

2 演进

2.1 单体

一般是产品设计之初，或者试运行阶段。

最常见的架构设计如上：

1. Service：服务层，对调用者提供优质的Rset或者RPC接口，同时能获取数据库数据
2. DB：数据层，一般是单库，负责数据存储

2.2 冷热分离架构

历史数据访问频率比较低，可以放在独立的表或者库中。比如你的去年之前的朋友圈，当有需要的时候才回去翻阅。

但是最近一周内的朋友圈信息（无论是你的还是你朋友发的图文，都是热数据），为了性能，为了你的活跃数据的表更轻便一点，必然要做隔离。

架构如上：

1. Service：服务层，对调用者提供良好的Rset或者RPC接口，同时能获取数据库数据
2. DB-Cool：冷数据库，一般存放历史比较久远的数据，数据量庞大，能够忍受加载效率慢
3. DB-Hot：热数据库，一般存近期活跃数据，数据量不会很庞大，加载效率高

2.3 读写分离架构

多读少些的场景已经形成了，大量的读操作影响到写数据的性能和稳定性了，为了解决【数据库读写高并发】 的问题而设计。

当然可引入缓存、消息队列等中间件支撑，咱们这边不提。

如上，这是最常见的1主N从，读写分离的数据库模式：

1. Service：服务层，对调用者提供良好的Rset或者RPC接口，同时能获取数据库数据
2. DB-M(master)：主库，提供数据库写服务
3. DB-R(replicate)：从库，提供数据库读服务

它有如下特点：

1. 1主n从，线性提升读的性能，当然n不是越多越好，也会有复制压力
2. 主从之间通过binlog来进行写操作的replay，实现数据复制
3. 主从之前的数据结构和数据结果完全一直，即使会有同步延迟，最终还是要一致的
4. 注意写依然是单点，那是因为互联网业务中，高频写的热数据占比一般都是很低的

2.4 数据分片架构

典型sharding（水平拆分）方案。

水平拆分又分为库内分表和分库分表，来解决单表中数据量增长出现的压力，这些数据库中的表结构完全相同，我们这边按照分库分表来介绍。

架构如上：

1. Service：服务层，对调用者提供良好的Rset或者RPC接口，同时能获取数据库数据
2. DB-0、DB-2：数据按照分片进行还分，这边的例子每1KW存一个分片

水平分区的数据可以按照这5种策略隔离：

2.4.1 Hash（哈希）

这种策略是通过对表的一个或多个列的Hash Key进行计算，最后通过这个Hash码不同数值对应的数据区域进行分区。例如我们可以建立一个对表的日期的年份进行分区的策略，这样每个年份都会被聚集在一个区间。

PARTITION BY HASH(YEAR(createtime))
PARTITIONS 10

2.4.2 Range（范围）

这种策略是将数据划分不同范围。例如我们可以将一个千万级别的表通过id划分成4个分区，每个分区大约250W的数据，超过750W后的数据统一放在第4个分区。

PARTITION BY RANGE(id) (
PARTITIONP0 VALUES LESS THAN(2500001),
PARTITIONP1 VALUES LESS THAN(5000001),
PARTITIONp2 VALUES LESS THAN(7500001),
PARTITIONp3 VALUES LESS THAN MAXVALUE
)

还有 Key（键值） 、List（预定义列表）、Composite（复合模式） ，请翻开我的这两篇文章：

《MySQL从零到有28：分库分表》

《MySQL从零到有29：分库分表之Partition功能详解》

2.4.3 解决什么问题？

1. 数据库/数据表瘦身，提升读写性能
2. 缩小故障影响范围（故障爆炸半径）

3 总结

1. 产品发展初期，使用单库模式
2. 部分数据写固化，读频率降低，使用冷热隔离架构
3. 业务量扩大，多读少些占比重，使用读写分离的主从架构
4. 数据基量膨胀，让检索不堪重负，使用分片（分库分表）架构