发完《Galera，MySQL主从之外的另一种选择》后，很多小伙伴在评论里留言：“这不是OracleRac吗？”“这不是MGR吗？”...idea比结论重要，why比what更重要，今天花1分钟来谈谈这里架构的演进。画外音：我们不想听底层的细节，所以我们不会细说。最早的数据库是独立的。最大的痛点是什么？它不能线性扩展。磁盘容量无法线性扩展，内存容量无法线性扩展，计算能力无法线性扩展。今天，喜欢创造概念的架构师称这种架构为“SharedEverything”架构。如上图所示，DISK/MEM/CPU都耦合在一个DBMS进程中，必须部署在一台服务器上。它们完全处于竞争状态，不能线性扩展，并行处理能力差。单机数据库部署是典型的“SharedEverything”架构。如何提高系统的并行能力？最容易想到的就是将无状态的逻辑计算部分从DBMS进程中剥离出来，做成可扩展的微服务集群，实现“计算存储分离”。如上图所示：(1)CPU逻辑计算拆分成独立的进程，可以集群部署，可以通过线程进行扩展；(2)DISK/MEM仍然耦合在一个进程中，仍处于竞争状态，无法线性扩展；Rac是典型的“SharedDisk”架构，其核心思想是“计算和存储分离”。部分存储磁盘IO仍存在集中资源竞争。是否还有进一步优化的空间？最容易想到的是将数据打散，分布到不同的数据库实例中，每一部分数据享有独立的资源。如上图所示：(1)将整体数据存储分成N个部分，每个部分之间没有交集；(2)每个数据的DISK/MEM/CPU在一个DBMS进程中，部署在一个服务器上；(3)每条数据之间不存在资源竞争；没错，这就是“横向切分”，是典型的“SharedNothing”架构。是不是对SharedEverything/Disk/Nothing这些高大上的名词有了更好的理解？事情还没完，横向分割有什么问题？水平切分虽然是一种可伸缩的架构，可以实现资源的线性扩展，但是会调用者失去数据的全局视野，调用者的能力有限：（1）无法实现全局JOIN；（2）无法实现全局排序；(3)不支持设置功能；(4)原来访问DBMS的操作，需要多次调用；(5)...而一些原本属于DBMS职责的工作，则转交给了调用者。如何解决“线性可扩展性”，同时解决“失去全局视野”和“调用者能力受限”的问题？最容易想到的解决方案就是数据库主从集群，每一份数据都是复制的，每个实例都独占共享DISK/MEM/CPU资源，避免了实例之间的资源竞争。如上图所示：(1)整体数据存储分为N个副本，每个副本之间的数据相同；（2）各数据的DISK/MEM/CPU在一个DBMS进程中，部署在一台服务器上（3）各数据之间不存在资源竞争；理想很丰满，现实很骨干，想法很好，但在实际执行“复制”的过程中，会遇到一些问题。以MySQL为例，常见的复制方式有3种：（1）异步复制（2）半同步复制（3）组复制第一种，异步复制（AsynchronousReplication）也叫主从复制（Primary-SecondaryReplication），是互联网公司使用最多的数据复制和数据库集群方式。它的想法是从数据库执行序列化的主数据库事务。其核心原理如上图所示：(1)第一时间线：主库时间线；主库执行事务主库事务序列化binlogbinlog同步到从库主库事务提交完成（2）第二条/第三条时间线：从库时间线；接收relaylog并执行与主库相同的事务生成自己的binlog（也可以继续从库）从库的事务提交完成从这个时间轴可以看到：(1)主库事务提交（2）从库事务的执行是并行执行的。主库不能保证从库的事务一定会执行成功，甚至不能保证从库一定会收到相关的请求。这也称为“异步复制”。"的理由。第二种，半同步复制（Semi-synchronousReplication），为了解决异步复制中“不保证从库接收请求”的问题，对异步复制进行了升级。其核心原理如上图所示：(1)第一时间线：主库时间线；主库执行事务。提交完成（2）第二/第三时间线：从库时间线；接收relaylog执行与主库相同的事务，给主库一个确认生成自己的binlog（也可以继续从从库）从库事务提交完成。从这个时间轴我们可以看出：(1)主库收到从库的ACK后会提交；(2)主库收到从库请求后，事务提交前，会给出一个ACK；半同步复制有什么问题？(1)主库的性能会受到很大的影响。（3）主从角色不同，主节点还是单点；大数据量、高并发的互联网服务一般不会采用“半同步复制”，更多的公司还是采用“异步复制”模式。最后，在MySQL5.7中，新提出了MySQLgroupreplication。第三种，组复制（MySQLGroupReplication，MGR）MGR有一些帅气的能力：（1）解决了单点写入的问题，一个组内的所有节点都可以写入；(2)最终一致性，一致性问题得到缓解，可以认为大部分实例的数据都是最新的；（3）高可用，当系统出现故障时（即使是脑裂），系统仍然可用；如上图所示：（1）首先，组内的MySQL实例不再是“主从”关系，而是对等的“成员”关系，因此每个节点都可以写；(2)其次，增加了共识认证(certify)环节，大多数节点只能提交同意的交易；画外音：Garela也是这样的机制。与MySQL传统的复制不同，MGR的核心是分布式共识算法，类似于Paxos。结合《Galera，MySQL主从之外的另一种选择》上次的留言，看来大部分人对算法底层核心都非常熟悉了，本文就不展开了。画外音：如果感兴趣的人多，我再详细展开。不知不觉已经写了几千字了，总结一下，做个总结吧。三种常见的数据库架构SharedEverything：数据库单机系统，资源竞争；SharedDisk：OracleRac，计算与存储分离；SharedNothing：水平切分，复制集群，资源完全隔离；三种常见的复制方式Slave，互联网公司最常用；半同步复制：确认从库，提交主库；组复制：MySQL5.7的新功能，核心在于分布式共识算法；知其然，知其所以然。想法比结论更重要。画外音：抱歉，我花了1分多钟才看完这篇文章。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
