logo

从读写分离到分布式

由于 Web 系统中读写需求拥有明显的二八分特征——读取流量占 80%,写入流量占 20%,所以如果我们能把读性能拆分到多台机器上,在同样的硬件水平下,数据库总 QPS 也就能提高五倍。

各种主从架构

各种主从架构是最简单最直接的读写分离架构。如图 9-1 所示就是阿里云 RDS 的几种主从架构。

图 9-1 阿里云 RDS 的几种主从架构

无论是远古时代谷歌的 MMM(Multi-Master Replication Manager for MySQL) 还是中古时代的 MySQL 官方的 MGR(MySQL Group Replication),还是最近刚刚完成开发且收费的官方 InnoDB Cluster,这些主从架构的实现方式都是一致的:基于行同步或者语句同步,近实时地从主节点向从节点同步新增和修改的数据。

图 9-2 包含网关的主从架构

由于这种方法必然会让主从之间存在一段时间的延迟(数百毫秒到数秒),所以一般在主从节点前面还要加一个网关进行语句分发,其架构如图 9-2 所示。该集群的运行方式如下:

  1. select等读语句默认发送到从节点,以尽量降低主节点负载
  2. 一旦出现updateinsert等些语句,立刻发送到主节点
  3. 并且,本次会话(session)内的所有后续语句,必须全部发送给主节点,不然就会出现数据写入了但是读不到的情况

图 9-3 一主四从架构图

像图 9-3 那样搭建一个一主四从的 MySQL 集群,总 QPS 就能从单节点的 1 万提升到 5 万,顺便还能拥有主节点故障后高可用的能力。主从架构比较简单,也没有什么数据冲突问题,就是有一个很大的弱点:

写入性能无法提升:由于数据库承载的单点功能实在是太多了(自增、时间先后、事务),导致哪怕架构玩出了花,能写入数据的节点还是只能有一个,所有这些架构都只能提升读性能。

那怎么提升写性能呢?这个时候就要拿出分布式数据库了。

分布式数据库

由于数据库的单点性非常强,所以在谷歌搞出 GFS、MapReduce、Bigtable 三驾马车之前,业界对于高性能数据库的主要解决方案是买 IOE 套件:IBM 小型机 + Oracle 数据库 + EMC 商业存储。而当时的需求也确实更加适合使用商用解决方案。

后来搜索引擎成为了第一代全民网站,而搜索引擎的数据库却“不那么关系型”,所以谷歌搞出了自己的分布式 KV 数据库。后来谷歌发现 SQL 和事务隔离在很多情况下还是刚需,于是在 KV 层之上改了一个强一致支持事务隔离的 Spanner 分布式数据库。而随着云计算的兴起,分布式数据库已经成了云上的“刚需”:业务系统全部上云,总不能还用 Oracle 物理服务器吧?于是云上数据库又开始大踏步发展起来。

下面我们按照时间顺序,逐一梳理分布式数据库的发展史。

阅读数:2940      字数:958 最后更新:2023-10-26 12:02:39