数据库软件架构,到底要设计些什么?

开发 开发工具 MySQL
分片解决“数据量太大”这一问题,也就是通常说的“水平切分”。一旦引入分片,势必面临“数据路由”的新问题,数据到底要访问哪个库。

一、基本概念

概念一:单库

单库

概念二:分片

分片

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

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

(1)范围:range

  • 优点:简单,容易扩展。
  • 缺点:各库压力不均(新号段更活跃)。

(2)哈希:hash

  • 优点:简单,数据均衡,负载均匀。
  • 缺点:迁移麻烦(2库扩3库数据要迁移)。

(3)统一路由服务:router-config-server

  • 优点:灵活性强,业务与路由算法解耦。
  • 缺点:每次访问数据库前多一次查询。

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

概念三:分组

分组解决“可用性,性能提升”这一问题,分组通常通过主从复制的方式实现。

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

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

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

二、如何保证数据的可用性?

解决可用性问题的思路是:冗余。

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

数据的冗余,会带来一个副作用:一致性问题。

1. 如何保证数据库“读”高可用?

冗余读库。

2. 冗余读库带来什么副作用?

读写有延时,数据可能不一致。

上图是很多互联网公司mysql的架构,写仍然是单点,不能保证写高可用。

3. 如何保证数据库“写”高可用?

冗余写库。

采用双主互备的方式,可以冗余写库。

4. 冗余写库带来什么副作用?

双写同步,数据可能冲突(例如“自增id”同步冲突)。

如何解决同步冲突,有两种常见解决方案:

  • 两个写库使用不同的初始值,相同的步长来增加id:1写库的id为0,2,4,6...;2写库的id为1,3,5,7…;
  • 不使用数据的id,业务层自己生成唯一的id,保证数据不冲突;

阿里云的RDS服务号称写高可用,是如何实现的呢?

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

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

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

这种方式的好处:

  • 读写没有延时,无一致性问题;
  • 读写高可用;

不足是:

  • 不能通过加从库的方式扩展读性能;
  • 资源利用率为50%,一台冗余主没有提供服务;

画外音:所以,高可用RDS还挺贵的。

三、如何扩展读性能?

提高读性能的方式大致有三种,第一种是增加索引。

这种方式不展开,要提到的一点是,不同的库可以建立不同的索引。

如上图:

  • 写库不建立索引;
  • 线上读库建立线上访问索引,例如uid;
  • 线下读库建立线下访问索引,例如time;

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

这种方法大家用的比较多,存在两个缺点:

  • 从库越多,同步越慢;
  • 同步越慢,数据不一致窗口越大;

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

常见的缓存架构如下:

  • 上游是业务应用;
  • 下游是主库,从库(读写分离),缓存;

如果系统架构实施了服务化:

  • 上游是业务应用;
  • 中间是服务;
  • 下游是主库,从库,缓存;

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

不管采用主从的方式扩展读性能,还是缓存的方式扩展读性能,数据都要复制多份(主+从,db+cache),一定会引发一致性问题。

四、如何保证一致性?

主从数据库的一致性,通常有两种解决方案:

1. 中间件

如果某一个key有写操作,在不一致时间窗口内,中间件会将这个key的读操作也路由到主库上。

2. 强制读主

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

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

另外建议,所有允许cache miss的业务场景,缓存中的KEY都设置一个超时时间,这样即使出现不一致,有机会得到自修复。

五、如何保障数据库的扩展性?

秒级成倍数据库扩容:《亿级数据DB秒级平滑扩容

如果不是成倍扩容:《100亿数据平滑数据迁移,不影响服务

也可能,是要对字段进行扩展:《1万属性,100亿数据,架构设计?

这些方案,都有相关文章展开写过,本文不再赘述。

数据库软件架构,到底要设计些什么?

  • 可用性
  • 读性能
  • 一致性
  • 扩展性

希望对大家系统性理解数据库软件架构有帮助。

【本文为51CTO专栏作者“58沈剑”原创稿件,转载请联系原作者】

戳这里,看该作者更多好文

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2016-11-29 08:50:17

数据库软件架构

2022-02-07 22:55:13

云原生数据库技术

2018-08-26 15:39:03

数据库MySQL索引

2017-12-13 10:04:05

2017-04-24 11:01:59

MySQL数据库架构设计

2023-03-07 08:17:19

Postgresql数据库优化

2014-01-02 09:56:33

2011-03-04 09:09:46

AD数据库

2017-06-10 11:13:39

数据库架构数据库集群

2021-07-12 11:32:36

数据库悲观模式

2020-05-22 10:00:08

数据库数据库设计软件设计

2023-08-27 16:11:35

数据库分布式事务数据库

2019-02-27 09:46:05

数据库架构并发

2017-11-03 11:02:08

数据库中间件

2017-06-08 11:06:03

数据库架构分组

2011-03-10 11:12:59

数据库

2011-03-10 11:17:03

数据库设计技巧

2011-04-15 13:28:44

数据库设计

2011-03-21 13:41:20

数据库开发规范

2020-11-23 16:42:38

数据库MySQL技术
点赞
收藏

51CTO技术栈公众号