京东云总监带你吃透分布式精髓(含视频)

但如果真正要做一个数据库的解决方案，目前的主流思路还是计算与存储分离，为什么会出现计算与存储分离呢?主要原因有以下几点：现在的网络延时一直在下降，带宽一直在增长，从我个人的工作经验来看，未来可能还有更大的网络带宽出现;但与此同时，磁盘IO的吞吐量并没有增长得像网络这么快。

此外，存储的虚拟化有利于成本下降，分布式存储有利于提高IOPS。如果在一个机器上做Raid的话，它的性能会比单个硬盘要好很多;如果采用分布式系统写入，它的IOPS其实会更高。

目前业界比较有名的几个计算与存储分离的解决方案，最著名的就是亚马逊的Aurora。

Aurora为什么选择计算存储分离?关于这一点，还需要探究当时亚马逊做RDS的解决方案如何。亚马逊RDS，就是它们的Realtional Database Service，整体数据存在local disk/EBS上面。

我们可以看到，整个IO的写入链条是比较长的，要把数据落盘，binlog落盘，redo log落盘，而且整个binlog两边要同步，最后还要把EBS的数据适当地备份到云存储中去。(这个只是备份，与实时写入无关)。

由于链路比较长，而且包括整个EBS的实现中，EBS就是个分布式的快存储，本质上也是多副本的。在多副本的情况下，EBS在远端也要做整个数据的同步，所以Aurora的设计目标就是思考能不能把存储与计算做一些相应的分离。出发点就是数据库存储引擎能不能与分布式块存储融合在一块，融合成一个新的存储引擎。

另外一个方案是F1/Spanner的方案，思路又是什么呢?

做一个分布式系统，如果去兼容MySQL比较麻烦的话，那是不是可以另起炉灶，做一个新的分布式系统。

它的思路很简单，就是重新去改写一些SQL，所以像F1/Spanner并不兼容MySQL的一些协议时，就会引入新的分布式事务管理，把SQL都拆解成K/V的一些操作结构，对这种方案而言，SQL的兼容性是个长期耗时而且是无限接近的一个过程，主要需兼容已有的生态会比较费力。但如果是一个新业务，用这种分布式方案就没有问题;如果是个旧业务，有自己成熟的SQL，想用它就比较困难了。

可以看到对一个MySQL服务而言，其实有两部分组成，一部分是Server，一部分Storage。Storage标准的架构是redo log加个data，这是InnoDB的一个结构，如今InnoDB已经成为MySQL的一个标准，大家都是按照这种方式去做的。

关于主从同步，是用binlog复制的方式，把binlog复制到Slave这边，Slave对binlog重放，然后Slave就有完整数据，这是传统的一个数据库组成模式。

对于MySQL而言，它的数据流向会是什么样子的?第一步，如果针对一个事务或者一个SQL语句，它会写很多redo log。第二步，会写到binlog中，binlog以后会做半同步，会同步到Slave中，返回一个信息，这时候可以进行一个整体的commit。

对于整个数据流向的一个示意图，主从之间用了整体的binlog复制方式去做。如果想做一个分布式系统的话，而且出发点是不能够将这些一样的数据放在同一个分布式系统中，需要做哪些事情?

我们发现，如果计算和存储分离之后，把所有的存储都放在一个分布式存储系统中去，master与slave读的是同一个数据，其实就不需要binlog了，这个是比较容易理解的。binlog用来传输具体的数据，因为数据都放在一起。

3计算和存储分离的优点

在于分布式存储的存储空间会相对大一些;另外一点，如果说要增加一个新的slave，以前在MySQL的主从复制中增加一个新的slave，通常怎么做?

要么就新建一个空白的slave，慢慢从组合开始同步数据，总而言之就是利用binlog同步数据;但如果整个数据量比较大的话，建立一个新的从时间会非常长，或者说根据备份去重建一个新的从，进而拷贝数据库备份。在这个基础上再去追新日志，无论如何增加一个节点，时间应该还是要以分钟计，至少以10分钟为单位。

但在计算与存储分离之后，新建一个slave时间就非常快了，而且备份数据的时候会快很多。因为针对传统主从系统做备份，其实都要去做一个文件系统的备份。做文件系统快照也行，用mysql dump也行，需要把本地文件传到云端存储;在分布式存储系统中，可以把这个任务转移给底层系统去做，当然数据的强一致还要靠底层存储去保证。

（编辑：应用网_阳江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!