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

1、基本概念

概念一：单库

概念二：分片

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

一旦引入分片，势必面临“数据路由”的新问题，数据到底要访问哪一个库。路由规则一般有3种方法：算法

（1）范围：range

优势：简单，容易扩展。
缺点：各库压力不均（新号段更活跃）。
sql

（2）哈希：hash

优势：简单，数据均衡，负载均匀。
缺点：迁移麻烦（2库扩3库数据要迁移）。
数据库

（3）统一路由服务：router-config-server

优势：灵活性强，业务与路由算法解耦。
缺点：每次访问数据库前多一次查询。
缓存

大部分互联网公司采用的方案二：哈希路由。架构

概念三：分组

分组解决“可用性，性能提高”这一问题，分组一般经过主从复制的方式实现。
ide

互联网公司数据库实际软件架构是“既分片，又分组”：

工具

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

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

2、如何保证数据的可用性？

解决可用性问题的思路是：冗余。优化

如何保证站点的可用性？冗余站点。
如何保证服务的可用性？冗余服务。
如何保证数据的可用性？冗余数据。

数据的冗余，会带来一个反作用：一致性问题。

如何保证数据库“读”高可用？

冗余读库。

冗余读库带来什么反作用？
读写有延时，数据可能不一致。
上图是不少互联网公司mysql的架构，写仍然是单点，不能保证写高可用。

如何保证数据库“写”高可用？

冗余写库。

采用双主互备的方式，能够冗余写库。

冗余写库带来什么反作用？
双写同步，数据可能冲突（例如“自增id”同步冲突）。

如何解决同步冲突，有两种常看法决方案：
（1）两个写库使用不一样的初始值，相同的步长来增长id：1写库的id为0,2,4,6...；2写库的id为1,3,5,7…；
（2）不使用数据的id，业务层本身生成惟一的id，保证数据不冲突；

阿里云的RDS服务号称写高可用，是如何实现的呢？
他们采用的就是相似于“双主同步”的方式（再也不有从库了）。

还是双主，但只有一个主提供读写服务，另外一个主是“shadow-master”，只用来保证高可用，平时不提供服务。

master挂了，shadow-master顶上，虚IP漂移，对业务层透明，不须要人工介入。

这种方式的好处：
（1）读写没有延时，无一致性问题；
（2）读写高可用；

不足是：
（1）不能经过加从库的方式扩展读性能；
（2）资源利用率为50%，一台冗余主没有提供服务；
画外音：因此，高可用RDS还挺贵的。

3、如何扩展读性能？

提升读性能的方式大体有三种，第一种是增长索引。

这种方式不展开，要提到的一点是，不一样的库能够创建不一样的索引。

如上图：
（1）写库不创建索引；
（2）线上读库创建线上访问索引，例如uid；
（3）线下读库创建线下访问索引，例如time；

第二种扩充读性能的方式是，增长从库。

这种方法你们用的比较多，存在两个缺点：
（1）从库越多，同步越慢；
（2）同步越慢，数据不一致窗口越大；

第三种增长系统读性能的方式是，增长缓存。

常见的缓存架构以下：

（1）上游是业务应用；
（2）下游是主库，从库（读写分离），缓存；

若是系统架构实施了服务化：
（1）上游是业务应用；
（2）中间是服务；
（3）下游是主库，从库，缓存；

业务层不直接面向db和cache，服务层屏蔽了底层db、cache的复杂性。

无论采用主从的方式扩展读性能，仍是缓存的方式扩展读性能，数据都要复制多份（主+从，db+cache），必定会引起一致性问题。

4、如何保证一致性？

主从数据库的一致性，一般有两种解决方案：

（1）中间件

若是某一个key有写操做，在不一致时间窗口内，中间件会将这个key的读操做也路由到主库上。

（2）强制读主

“双主高可用”的架构，主从一致性的问题可以大大缓解。

第二类不一致，是db与缓存间的不一致。

这一类不一致，《缓存架构，一篇足够？》里有很是详细的叙述，本文再也不展开。

另外建议，全部容许cache miss的业务场景，缓存中的KEY都设置一个超时时间，这样即便出现不一致，有机会获得自修复。

5、如何保障数据库的扩展性？