思路比结论重要,为什么比是什么重要,今天就花1分钟,说下这里面架构演进的思路。磁盘能力无法线性扩展,内存能力无法线性扩展,计算能力无法线性扩展。如今,喜欢创造概念的架构师们,把这种架构称为“Shared Everything”架构。如上图所示,DISK/MEM/CPU 都耦合在一个DBMS进程内,必须部署在一台服务器上,完全处于竞争态,无法线性扩展,并行处理较差。数据库单机部署,就是典型的“Shared Everything”架构。最容易想到的,就是把无状态的逻辑计算部分,从DBMS进程内拆分出来,做成可扩展的微服务集群,实现“计算与存储分离”。(1)CPU逻辑计算拆分出了独立的进程,可以集群部署,能够线程扩展;(2)DISK/MEM 仍耦合在一个进程内,仍处于竞争态,无法线性扩展;Oracle Rac,就是典型的“Shared Disk”架构,核心思路是“计算与存储分离”。存储部分磁盘IO仍有集中的资源竞争,还有没有进一步的优化空间呢?最容易想到的,就是把数据打散,分布到不同的数据库实例上,每部分数据享有单独的资源。(1)把整体数据存储分为了N份,每份之间没有交集;(2)每份数据的 DISK/MEM/CPU 都在一个DBMS进程内,部署在一台服务器上;没错,这就是“水平切分”,它是典型的”Shared Nothing”架构。对 Shared Everything/Disk/Nothing 这些高大上的名词,进一步认识了不?水平切分虽然是一种可扩展架构,能够实现线性扩展资源,但它会使得调用方失去数据的全局视野,使得调用方能力受限:并把一些原本属于DBMS职责的工作,转嫁到调用方。如何解决“线性扩展能力”,同时又解决“失去全局视野”与“调用方能力受限”的问题呢?最容易想到的方案是,数据库主从集群,每份数据都进行复制,每个实例都独享 DISK/MEM/CPU 资源,避免实例之间的资源竞争。(1)把整体数据存储分复制了N份,每份之间数据都一样;(2)每份数据的 DISK/MEM/CPU 都在一个DBMS进程内,部署在一台服务器上;理想很丰满,现实很骨干,思路没问题,但实际执行“复制”的过程中,会碰到一些问题。第一种,异步复制(Asynchronous Replication)又叫主从复制(Primary-Secondary Replication),是互联网公司用的最多的数据复制与数据库集群化方法,它的思路是,从库执行串行化后的主库事务。是并行执行的,主库并不能保证从库的事务一定执行成功,甚至不能保证从库一定收到相关的请求,这也是其称作“异步复制”的原因。第二种,半同步复制(Semi-synchronous Replication)为了解决异步复制中“不能保证从库一定收到请求”等问题,对异步复制做了升级。(2)从库收到请求后,事务提交前,会给主库一个ACK;(1)主库的性能,会受到较大的影响,事务提交之前,中间至少要等待2个主从之间的网络TTL;大数据量,高并发量的互联网业务,一般不使用“半同步复制”,更多的公司仍然使用“异步复制”的模式。最后是MySQL5.7里,新提出的MySQL组复制。第三种,组复制(MySQL Group Replication,MGR)(1)解决了单点写入的问题,一个分组内的所有节点都能够写入;(2)最终一致性,缓解了一致性问题,可以认为大部分实例的数据都是最新的;(3)高可用,系统故障时(即使是脑裂),系统依然可用;(1)首先,分组内的MySQL实例不再是“主从”关系,而是对等的“成员”关系,故每个节点都可以写入;(2)其次,增加了一个协商共识的认证(certify)环节,多数节点达成一致的事务才能提交;和MySQL传统的复制不同,MGR的核心是分布式共识算法,类似于Paxos。Shared Everything:数据库单机系统,资源竞争;Shared Disk:Oracle Rac,计算与存储分离;Shared Nothing:水平切分,复制集群,资源完全隔离;组复制:MySQL 5.7的新功能,核心在于分布式共识算法;《缓冲池(buffer pool),这次彻底懂了!》
《写缓冲(change buffer),这次彻底懂了!》
《日志缓冲(log buffer),这次彻底懂了!》
《double write buffer,这次彻底懂了!》
《关于MySQL,这篇都没人赞?》
本站仅提供存储服务,所有内容均由用户发布,如发现有害或侵权内容,请
点击举报。