数据库软件架构，到底要设计些什么？ _软件架构

一、基本概念
概念一：单库

文章插图

概念二：分片

文章插图

分片解决“数据量太大”这一问题，也就是通常说的“水平切分” 。
一旦引入分片，势必面临“数据路由”的新问题，数据到底要访问哪个库。路由规则通常有 3 种方法：
（1）范围： range
优点：简单，容易扩展。
缺点：各库压力不均（新号段更活跃）。
（2）哈希： hash
优点：简单，数据均衡，负载均匀。
缺点：迁移麻烦（2库扩3库数据要迁移）。
（3）统一路由服务： router-config-server
优点：灵活性强，业务与路由算法解耦。
缺点：每次访问数据库前多一次查询。
大部分互联网公司采用的方案二：哈希路由。
概念三：分组

文章插图

分组解决“可用性，性能提升”这一问题，分组通常通过主从复制的方式实现。
互联网公司数据库实际软件架构是“ 既分片，又分组”：

文章插图

数据库软件架构，究竟设计些什么呢，至少要考虑以下四点：

如何保证数据可用性
如何提高数据库读性能（大部分应用读多写少，读会先成为瓶颈）
如何保证一致性
如何提高扩展性

文章插图

二、如何保证数据的可用性？
解决可用性问题的思路是：冗余。
如何保证站点的可用性？冗余站点。
如何保证服务的可用性？冗余服务。
如何保证数据的可用性？冗余数据。
数据的冗余，会带来一个副作用：一致性问题。
如何保证数据库“读”高可用？
冗余读库。

文章插图

冗余读库带来什么副作用？
读写有延时，数据可能不一致。
上图是很多互联网公司MySQL的架构，写仍然是单点，不能保证写高可用。
如何保证数据库“写”高可用？
冗余写库。

文章插图

采用双主互备的方式，可以冗余写库。
冗余写库带来什么副作用？
双写同步，数据可能冲突（例如“自增id”同步冲突）。
如何解决同步冲突，有两种常见解决方案：
（1）两个写库使用不同的初始值，相同的步长来增加id ：1写库的id为0,2,4,6...；2写库的id为1,3,5,7…；
（2）不使用数据的id，业务层自己生成唯一的id ，保证数据不冲突；
阿里云的RDS服务号称写高可用，是如何实现的呢？
他们采用的就是类似于“双主同步”的方式（不再有从库了）。