「转」数据库软件架构，到底要设计些什么（收藏）

一、基本概念

概念一：单库

概念二：分片

分片解决“数据量太大”这一问题，也就是通常说的“水平切分”。

一旦引入分片，势必面临“数据路由”的新问题，数据到底要访问哪个库。路由规则通常有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服务号称写高可用，是如何实现的呢？

他们采用的就是类似于“双主同步”的方式（不再有从库了）。