1同行回答
Oracle就目前来说，自身的架构设计，高并发集群，以及各种高可用架构都是比较完善的，自成体系且应用广泛，机制完善。
一、MySQL高可用方案
MySQL以及各种开源数据库，也有自身的集群方案，但是大多需要和业务以及借助第三方工具来实现。或者通过分布式来均衡高并发。主要的高可用集群架构可以分为如下几种：
1、基于共享存储的高可用方案--SAN
基于共享存储的高可用，及使用传统的基于SAN共享存储，结合开源的Keeplive做主从同步，可避免除存储外的组件损坏引起的宕机，部署相对简单，对应用透明，但是存储时单点，且存在性能瓶颈
2、基于磁盘复制的高可用方案-DRBD
保证主备的数据一致性，不依赖共享存储，此方案处理failover的方式上依旧需要借助主机层面的高可用组件，如keeplive，Heartbeat等。不同的是，在数据共享方面，采用了基于块级别的数据同步软件DRBD来实现，，但是可扩展性较差。它并不共享存储，而是通过服务器之间的网络复制数据。
适用于数据库访问量不太大，短期内访问量增长不会太快，对数据库可用性要求非常高的场景。
3、基于MySQL自身的主从复制-Replication
基于MySQL自身的主从复制，5.7以后的GTID，以及之前的replication。主从复制，部署简单，但是只能有一个Master进行读写，其余都为备库，还需要结合业务。并发量不大的情况下，可采取主从，管理简单。
4、MHA高可用方案
MHA是一套MySQL高可用管理软件，除了检测Master宕机后，提升候选Slave为New Master之外（漂虚拟IP），还会自动让其他Slave与New Master 建立复制关系。 MHA Manager可以单独部署在一台独立的机器上，并管理多个master-slave集群。但是，只支持一主多从架构，集群中必须最少有三台数据库服务器，要保持切换对应用透明，依然依赖于VIP，不适用于大规模集群部署，配置比较复杂。且MHA管理节点本身的HA无法保证。
MySQL 5.7 之前数据不丢的前提是Master服务器还可以被MHA Manager进行SSH连接，通过应用保存的binlog 的方式来保证。MySQL 5.7 之后通过无损复制， 仅仅是减少了丢数据的可能性，假如此时的状态为切成异步的状态，那就和之前一样了（可以设置超时的时间很大）；当Master恢复的时候，最后一部分数据是否需要Flashback，MHA也是不负责这个事情，需要人工介入。
5、基于zookeeper/consul的高可用方案
借助zookeeper组件，结合MHA或者其他高可用架构场景，实现强制一致性的高可用集群分布，可适应大规模高并发场景，需要一定的技术实力，引入zookeeper，架构复杂度上升，但是整体扩展性非常好，可以管理大规模集群。保证了整个系统的高可用，主从的强一致依赖于MySQL本身，比如半同步，或者外围工具的回补策略
6、基于MMM高可用方案
MMM提供了MySQL主主复制配置的监控、故障转移和管理的一套可伸缩的脚本套件。在MMM高可用方案中，典型的应用是双主多从架构，通过MySQL replication技术可以实现两个服务器互为主从，且在任何时候只有一个节点可以被写入，避免了多点写入的数据冲突。同时，当可写的主节点故障时，MMM套件可以立刻监控到，然后将服务自动切换到另一个主节点，继续提供服务，从而实现MySQL的高可用。可以灵活选择VIP方案或者全局目录数据库方案(更改Master IP映射)来进行切换。
MMM提供了自动和手动两种方式移除一组服务器中复制延迟较高的服务器的虚拟ip，同时它还可以备份数据，实现两节点之间的数据同步等。由于MMM无法完全的保证数据一致性，所以MMM适用于对数据的一致性要求不是很高，但是又想最大程度的保证业务可用性的场景。对于那些对数据的一致性要求很高的业务，非常不建议采用MMM这种高可用架构。
7、基于中间件proxy高可用组件的集群方案
中间件：
阿里 Cobar、MyCAT
360 Atlas
淘宝 Tddl
网易 Cutus
MySQLProxy
ProxySQL(Percona)
KingShard
MaxScale(MariaDB)
OneProxy
切换对应用透明,可扩展性强，方便分片扩展,可以跨机房部署切换,但是需要有一定自研能力，或者选择有完整的后期技术支持的中间件，以及社区活跃度较高的，有一定能力，后期可自研或者自己优化开发相关的中间件。以适应自身的业务需求。
二、集群/分布式
基于集群或者分布式的HA包括：
Mysql Group Replication
Mysql InnoDB Cluster
Percona XtraDB Cluster
MariaDB Galera Cluster
1、MGR
关于MGR原理，可参考可以参考阿里的数据库内核月报，关于mgr的文档。 http://mysql.taobao.org/monthly/2017/08/01/
基于传统异步复制和半同步复制的缺陷——数据的一致性问题无法保证，MySQL官方在5.7.17版本正式推出组复制（MySQL Group Replication，简称MGR）。 由若干个节点共同组成一个复制组，一个事务的提交，必须经过组内大多数节点（N / 2 + 1）决议并通过，才能得以提交。如上图所示，由3个节点组成一个复制组，Consensus层为一致性协议层，在事务提交过程中，发生组间通讯，由2个节点决议(certify)通过这个事务，事务才能够最终得以提交并响应。
引入组复制，主要是为了解决传统异步复制和半同步复制可能产生数据不一致的问题。组复制依靠分布式一致性协议(Paxos协议的变体)，实现了分布式下数据的最终一致性，提供了真正的数据高可用方案。
2、MySQL InnoDB Cluster
Cluster解决方案其实是由MySQL的几个不同产品和技术组成的，比如MySQL Shell, MySQL Router, Group Replication. 一组MySQL服务器可以配置为一个MySQL集群。在默认的单主节点模式下，集群服务器具有一个读写主节点和多个只读辅节点。辅助服务器是主服务器的副本。客户端应用程序通过MySQL Router连接到主服务程序。如果主服务连接失败，则次要的节点自动提升为主节点，MySQL Router请求到新的主节点。InnoDB Cluster不提供NDB Cluster支持
3、Percona XtraDB Cluster
官网地址：https://www.percona.com/doc/percona-xtradb-cluster/5.7/intro.html
节点在接收sql 请求后，对于ddl 操作，在commit之前，由WSREP API 调用galera 库进行集群内广播，所有其他节点验证成功后事务在集群所有节点进行提交，反之rollback。pxc 保证整个集群所有数据的强一致性，满足CAP理论中满足：Consistency 和 Availability。
PXC提供的特性
同步复制，事务要么在所有节点提交或不提交
多主复制，可以在任意节点进行写操作
在从服务器上并行应用事件，真正意义上的并行复制
节点自动配置
数据一致性，不再是异步复制
限制：
只支持INNODB表
不允许大事务的产生（否则的话后果很严重）
写性能取决于最差的节点
不能解决热点更新问题
乐观锁控制
对于写密集型应用需要控制单个节点的大小，单个节点数据越大，新加节点如果采用自动添加可能产生很大抖动（添加节点建议用备份或者备份+binlog 进行IST(Incremental State Transfer)增量同步