1.前言本文总结了几种常用的关系型数据库架构及其演化历史。分析数据库架构方案的几个角度是故障时的高可用性、数据的一致性和切换后的可扩展性。每种产品也有其独特的优点和特点，在此不再赘述。2、Oracle数据库的架构解决方案ORACLE数据库可以同时运行OLTP和OLAP服务，其能力在商业数据库中名列前茅。支持IBM小型机和x86PC服务器，支持多操作系统。同时，有多种数据库架构方案可供选择，成本、收益和风险各不相同。A.IBMAIXHACMP+ORACLE9I+EMC图1：IBMAIXHACMP+ORACLE9I+EMC架构说明：1.两台IBMAIXA和B。AIXA运行OraclePrimary实例，AIXB分配部分资源虚拟化一个OSC运行Oracle备用实例。AIXB的大部分剩余资源都可以免费用于将来的另一个OraclePrimary实例。2.两个存储（EMC只是一个例子）A和B分别直连两个AIXA和B。StorageA存储了Primary实例的日志和数据，同时也存储了Standby实例的Redo（图中没有显示，只有当角色不是Primary时才有效）。StorageB存储Standby实例的日志和数据，同时也存储Primary实例的Redo文件。3、AIX也可以换成普通的x86_64PC服务器，HACMP可以换成支持linux的集群软件。比如VeritasHA。功能：1.高可用：当OraclePrimary实例不可用时，HACMP在AIXB上启动OraclePrimary实例。当存储A不可用时，将AIXC上的Standby实例故障转移到Primary实例。2.数据一致性：重做文件在两个存储上都保留。Standby实例在故障转移之前应用PrimaryRedo。理论上，即使发生故障转移也不会丢失数据。3、可扩展性：数据库的性能由主机AIX和存储容量决定，两者都可以向上扩展，成本会急剧上升，而且有上限。B、x86+ORACLERAC+EMC架构说明：1、两台主机A、B可以是AIX或x86_64普通PC服务器。它们通过网络直接相互连接，同时连接到共享存储EMCA。A和B分别运行一个RACPrimary实例。2、HostC可以是一台AIX或者x86_64普通PC服务器，直接连接另一个存储B，运行一个Standby实例。一些架构也有多个Standby实例，其中一个也是RAC。功能：1.高可用：无论哪个OracleRACPrimary实例不可用，另一个都可以自动接管服务。如果主实例的存储A不可用，则将备实例故障转移到主实例。2、数据一致性：如果Primary实例也输出一组Redo成员到B存储，理论上不会丢失数据。否则，在极端情况下，可能会因为缺少主事务日志而导致Failover失败。这种情况下，直接将备实例激活为主实例，可能会丢失少量数据。3、可扩展性：如果数据库的计算能力不足，可以水平扩展（增加RAC节点），如果存储容量不足，可以向上扩展（存储扩展）。C、OracleDataguard共享Redo架构说明：1、普通x86服务器A和B分别运行Oracle的Primary和Standby实例。它们直接相互连接并同时连接到共享存储。2.Primary和Standby实例的Redo、controlfiles、spfiles放在共享存储上，占用空间很小。数据文件放在本地机器上，一般是高速存储（比如SSD或者PCIE接口的Flash设备）。功能：1.高可用性：当Primary实例不可用时，将Standby实例故障转移到Primary实例。如果共享存储不可用，则两个实例都不可用。通常有第三个备用实例。2、数据一致性：在Failover之前将Primary实例的Redo文件应用到Standby实例，事务日志不丢失，数据强一致性。3.可扩展性：无。三、MySQL数据库架构方案A、ADHA（AlibabaDatabaseHighAvailability）架构说明：1、采用MySQLMaster-Master架构，双向同步，Slave只读。2、使用Zookeeper集群监控实例不可用，防止脑裂。功能：1.高可用：Master实例不可用后，Slave会被激活。可用性优先。如果Slave延迟超过一定阈值，则放弃切换。zk集群的三节点部署可以防止脑裂。2、数据一致性：为了尽可能少的减少数据丢失，建议开启单向半同步技术。同时，旧master恢复后，会尽量将没有及时同步到新master上的数据补上。由于同步依赖Binlog，理论上无法保证主从数据的绝对一致性。3、可扩展性：可以读写分离，可以添加slave来扩展读服务能力。B、MHA（MasterHighAvailability）架构说明：1、源于MySQL主从同步架构，采用半同步技术，因此至少有两个从实例（Slave）。所以整体架构是一主两从，两个从库不是级联关系。功能：1.高可用：当Master不可用时，自动从两个Slave中选出Binlog最多的Slave提升为Master。同时，将另一个Slave的Master换成新的Master。当Master异常时，如果拉取到Slave上的Binlog丢失（当master或slave发生故障时），很容易造成复制中断，所以这种高可用机制并不是一直有效。2、数据一致性：为了尽量减少Binlog的丢失，建议使用半同步技术进行主从同步。在网络异常的情况下，半同步可能会退化为异步同步。MHA只是尽力确保数据不丢失。并且由于同步依赖Binlog，理论上无法保证主从数据严格一致。3、可扩展性：可提供读写分离服务，可添加从节点扩展读服务能力。C.PXC（PerconaXtraDBCluster）架构说明：1.可以有两个节点，建议三个节点（防止裂脑）组成一个Cluster。三个节点同时提供读写服务。数据是三个独立的副本，不是共享存储。2、交易提交是同步复制，所有从节点同步提交。功能：1.高可用：三个节点同时提供读写服务，不会影响任何节点。2、数据一致性：数据强同步到所有节点，不丢失数据。需要主键，部分SQL不支持同步。3、可扩展性：事务提交是同步复制，其性能仅限于最差的节点。4.其他：多主复制，但同一行数据不能同时写入（乐观锁，会报死锁错误）。此外，还有写入放大的缺点。四、分布式数据库中间件架构方案A、分布式数据库DRDS架构说明：1、DRDSServer节点是一组响应SQL请求，进行分库分表路由转换、SQL重写、聚合计算的无状态程序，ETC。。支持库表两级维度拆分，支持多种灵活的拆分策略，支持分布式事务。2、MySQL节点主要用于存储数据，主备节点之间采用双向同步架构。此外，MySQLPaaS平台提供高可用切换和自动化运维能力。3.围绕这个架构还有一个数据同步组件（经纬），实现了小表广播和异构索引表的能力。4、最新版架构在只读实例的基础上实现了MPP并行计算引擎，支持部分OLAP查询场景。功能：1.高可用：计算节点（DRDSServer节点）的高可用通过前端负载均衡设备实现，存储节点（MySQL）的高可用通过ADHA实现。RTO在40s左右，RPO>=0。2、数据一致性：MySQL主备同步是半同步还是异步。ADHA将MySQL故障切换时主备不一致的概率降到最低。理论上不能保证绝对强一致性，RPO>=0。3.可扩展性：计算和存储节点可以单独扩展。存储扩展是通过增加MySQL实例和数据迁移和重新分布来实现的。4、运维：发生故障时，主备强制切换后，有一定概率会因为数据不一致导致主备同步中断。B、分布式数据库TDSQL架构说明：1、计算节点：由一组无状态网关节点组成，负责SQL路由、MySQLmaster故障时的路由切换等。2、调度系统：使用zk集群进行元数据管理，故障监控、数据库故障转移、弹性伸缩任务等。3、存储节点：MySQL主备架构，一主两从，强同步或异步同步。4.支持全时数据模型功能：1.高可用：网关前端估计也有负载均衡，MySQL主备切换依赖zk判断，RTO在40s左右2.数据一致性：当一个master而两个slave使用强同步，基本上可以保证RPO=0。如果是异步的，切换的时候可能会有延迟。3.可扩展性：通过增加网关的能力或数量来增加计算能力，增加MySQL节点的数量进而调整数据分布来提高计算和存储能力。4、运维：当出现异常时，可能会因为数据不一致导致主备同步服务中断，需要修复。C.分布式数据库GoldenDB架构也分为数据库和表，与DRDS基本相同。D、分布式数据库MyCat架构的原理和功能与前两种基本相同。底层存储节点也支持Oracle和Hive。E.分布式数据库HotDB5。分布式数据库A.Google的F1说明：1.F1支持sql，底层可以支持MySQL和Spanner。选择Spanner的主要原因是Spanner不需要手动分区，使用Paxos协议同步数据，保证强一致性和高可用。2.Spanner分为多个Zone部署。每个区域都有一个zonemaster（管理元数据和spannerserver）和多个spannerservers。3.Spanner的数据存储在tablet中，每个tablet按照固定的大小分成多个目录。Spanner以目录为单位进行负载均衡和高可用，paxosgroups与目录对应。4.Spanner的TrueTime设计为分布式事务的实现提供了新的方向（分布式MVCC）。B.PingCap的TiDBTiDB主要参考了Google的Spanner和F1的设计，在架构上有很多相似之处。架构说明：1.TiDBserver负责处理SQL和路由。无状态，可以部署多个节点，结合负载均衡设计，对外提供统一的访问地址。2.PDServer是集群的管理模块，负责存储元数据，为TiKV进行任务调度和负载均衡，分配全局唯一且增量的事务ID。3.TiKVServer是一个存储节点，从外部看是一个Key-Value存储引擎。表数据按照固定大小（比如20M，可配置）自动划分为多个Region，分布在多个TiKVServer上。Region是数据迁移和高可用的最小单位。Region的内容一共有三份，分布在三个区域。数据同步和强一致性由Raft协议保证。4.支持分布式事务，率先实现全局一致的快照。支持全局一致的备份。5、兼容MySQL主要语法。功能：1.可用性：计算节点无状态部署，结合负载均衡设计，保证高可用和负载均衡。存储节点部署三副本，使用Raft协议保持三副本的数据一致性和同步性，并在出现故障时自动进行选举（高可用）。2、可扩展性：计算和存储分离，可以独立扩展。存储节点扩容后，数据会重新分布，需要后台异步任务完成，不影响业务读写，可以在线扩容。可用于异地容灾，两地三中心异地活跃（三个机房之间的网络延迟很小）3.数据一致性：计算节点故障不会造成数据丢失,失败的存储节点将自动选举。领导者与旧领导者数据高度一致。C.支付宝的OceanBaseOceanBase的设计思路与Spanner类似，但在SQL、存储、交易等方面有自己的创新。架构说明：1、当前版本的计算和存储集中在一个节点（PC、OBServer），单进程程序，进程包括SQL引擎和存储引擎功能。2、表数据有一个或多个分区（使用分区表），业务需要指定分区规则。分区是数据迁移和高可用的最小单位。分区之间的一致性由MultiPaxos保证。3.支持分布式事务，2.x版本支持全局一致的快照。支持全局一致的备份。4、兼容MySQL的主要用法和Oracle的标准SQL用法，正在逐步兼容Oracle的更多功能。比如存储过程、游标和Package等。目标是兼容Oracle的常用功能，让应用去IOE时不修改代码。5、多租户管理能力，租户灵活扩展，租户之间有一定的资源隔离机制。6、应用可以通过反向代理obproxy或者ob提供的connector-java访问OceanBase集群。与Spanner的关系和区别：1.Spanner大约在2008年开始研发，2012年通过论文公开，首次实现跨地域水平扩展，实现自动高可用和数据强一致基于普通PC服务器。OceanBase从2010年开始研发，同样是在普通PC服务器的基础上，开发了自己独有的ACID特性、高可用技术和拆分技术。2、Spanner对标准SQL的支持不是很好，不是真正的关系型数据库，定位于内部应用。OceanBase定位为通用的分布式关系数据库，支持标准SQL和关系模型。基本兼容MySQL功能，逐步兼容Oracle功能。3.Spanner采用原子钟硬件和TrueTime设计，支持全局一致的快照，提供快照读隔离级别，对节点间网络延迟要求比较高。OceanBase通过软件提供全球时间服务，实现全球一致的快照功能。4、缺少Spanner的内部诊断和跟踪机制，而OceanBase的内部诊断和分析机制功能完备，针对商业软件标准。功能：1.可伸缩性：租户和集群的弹性伸缩非常方便，可以在线完成，对业务写入的影响可控。可用于两地三中心的异地容灾和多活（单元化设计结合业务）。2.可用性：当一个或多个观察者不可用时，只要分区的大部分成员存活，就可以快速选举并恢复服务（RTO=20s）。3、数据一致性：故障恢复后，数据库数据永不丢失。RPO=0。
