理解中心化数据库节前我写了一篇关于分布式数据库的文章。当时有几个朋友和我讨论过如何在集中式数据库和分布式数据库之间进行选择。事实上，数据库产品并不是万能的。针对不同的应用场景和不同的用户群体，他们对数据库的选择是不同的。对于一些用户或者一些应用场景来说，选择分布式数据库可能是一个必然的选择。对于其他用户或应用场景，选择集中式数据库更容易。总的来说，由于集中式数据库比较简单，可能适用的场景更广泛，尤其是对于中小型非关键系统或者不具备运行和维护大型分布式数据库系统能力的用户。选择集中式数据库可能更符合企业的需求。事实上，使用集中式数据库的客户也需要分布式数据库的很多特性，比如高可用、多副本、故障自动隔离、水平扩展等。许多用户担心集中式数据库的单机整体容量可能有限。事实上，对于大多数系统来说，单机要达到极限还是非常困难的。无论是内存、CPU、IO、网络、存储容量，目前的上限都相当高，一般系统想要达到上限还是比较困难的。即便如此，集中式数据库也有必要支持某种程度的横向扩展。比如Oracle的RAC，虽然不能像分布式数据库那样横向扩展到几十上百个节点，但是RAC的水平扩展能力还是让人觉得比较安心。对于国内的中心化关系型数据库来说，强一致性读写分离是一种很好的水平扩展方式。它的实现方法没有OracleRAC那么难，可以解决大量读操作占用过多系统资源的问题。实现强一致性读写分离的更好方案，是国产中心化数据库在同质化竞争中脱颖而出的一条出路。可能有朋友会说，现在国内的数据库和开源数据库基本功能差不多，这有什么难的。事实上，目前开源和国产数据库的集群计算都是插件化的，并不是从数据库的底层设计出发，只是将集群计算框架和原有的RDBMS内核进行了整合。要弄清楚这个问题，我们首先要分析客户为什么要找一个功能。有时候客户需要强一致的读写分离并不是为了横向扩展，而是为了用最简单的方式实现应用系统的高可用。数据库强一致性和同步不丢失数据一直是客户对保证数据库高可用的强烈需求。虽然大多数用户可以接受部分数据丢失，但只要主系统出现故障，他们可以快速恢复业务。最低限度。但正是因为failover是有损的，所以在真正做switchover的时候还是有些犹豫。因为每次切换之后，都有一些脏数据需要处理，给运维部门、业务部门、开发人员留下一些尾巴。如果切换后能做到零数据丢失，不需要做收尾工作，那么当主系统出现故障时，故障切换会非常果断。强一致性同步的另一个好处是，在我们类似MIS的系统中，读写比高达8:2甚至9:1。从应用的角度来说，将一些读操作转移到只读副本上，可以大大减轻主实例的负担，也可以降低主实例出现故障的概率。如果任何时候主备实例的数据都不是完全一致的，那么我们的应用就需要做相应的修改，保证一些只读操作可以在只读副本上运行。一些只读操作需要强一致性，必须在主实例上运行。但是，如果主从数据库系统中的数据在任何时候都能保证强一致性，那么在集群环境下编写应用程序的难度就会大大降低。除了读写分离的强一致性外，客户的另一个重要需求是透明的应用故障切换。Oracle这个词简称为TAF，属于RAC故障转移的一种早期方法。取而代之的是功能强大的快速连接故障转移（FCF），但国内大部分应用软件仍在使用TAF。TAF的好处是当数据库实例出现故障时，应用可以自动切换。Oracle12.1之后支持的GDS服务可以支持集群计算环境下的读写分离、负载均衡、故障转移等功能。我们国内的数据库厂商可以仔细研究一下它的功能和实现方法。OracleGDS可以构建统一、复杂、强大的统一计算环境，让RAC\ADG\OGG等复制技术和计算框架有效集成为一个整体。我们在数据库集群计算环境中需要强一致性。强一致性读写分离的实现方式主要有以下几种：第一种模式：多实例共享存储+bufferfusion读写分离：多个读写分离数据库实例共享一组存储数据，只有主实例支持读写，其他实例为只读。对于没有写入磁盘的脏块，直接从主实例的缓冲区中获取。这种实现方式比OracleRAC的多主模式简单；第二种模式：多实例共享存储+WALAPPLY：与第一种模式类似，采用一主多从模式，主实例可以读写。其他实例是只读的。不同的是，多个实例是完全独立的，不通过bufferfusion来保证读写一致性，而是通过在备实例上重放WAL数据来保证读写一致性。这种模式相对于第一种模式的优势在于主从实例完全独立，相互影响很小。只要底层存储能支持，从节点再多问题不大。缺点是如果master实例有大量的写操作，slave实例的replay可能会造成一定的延迟。polardb-PG就是这种模式的一个例子；第三种模式是多实例存储复制+WALAPPLY：为了防止底层存储的IO性能达到极限，从底层实现存储的同步/半同步自动复制，保证多个Data存储副本之间的一致性。不同的实例可以使用独立的副本，或者有限数量的实例可以共享一个独立的副本。其他实现方式与第二种方式类似，这是第二种方式的变体。Amazon的AURORADBCLUSTER就是这种模式的典型案例；第四种模式多实例非共享存储零数据丢失复制：主从实例是一个完全独立的数据库，保证WAL数据在存储底层自动无损复制，保证已经被WAL提交事务的文件可以复制到从库。从库通过日志回放保证与主库的同步或半同步。事实上，以目前的数据库和分布式数据库技术，实现上述四种模式并不存在不可逾越的技术难点。WALWRITER等核心组件到操作系统、存储系统、网络实现全栈设计和优化，使其成为一个集成的数据库设计，而不是一堆组件的简单集成。这种一体化的设计与实现，可以实现整体优化处理，自动处理各种异常，并自动进行相关的容错处理，从而保证系统提供的读写、故障转移、故障数据修复的强一致性。数据库。等可以根据数据库底层模块自动完成，而不需要运维人员或应用开发人员做相关处理。甚至未来会通过SQL执行算子实现下推，在某些计算场景下实现跨数据库实例的并行计算。这种计算框架可以解决目前中心化数据库中一些比较棘手的问题。例如，分析大型数据库表时产生大量IO导致的系统性能问题。在该计算框架下，集群计算可以通过以下方式实现。当发起表分析任务时，主库分解分布式计算任务，通过消息队列将任务分发给多个从库，由从库完成实际的计算任务，再将结果发送给主库，统一到库中。然后通过复制技术分发到各个从库。如果是十几年前，硬件处理能力和分布式复制技术还没有发展到今天的时候，中心化数据库的设计可能不会往这个方向考虑。随着框架的快速发展，我们中心化数据库的架构设计能否摆脱沿用了几十年的老方案，尝试一些适合现代软硬件技术的新方案？事实上，OracleGDS并不是一个原始的集群计算框架，而是在ADG、OGG、ONS、FAN、ADGFARSYNC等技术的基础上逐渐发展起来的集成计算框架。但是，从GDS我们也可以看出，中心化数据库完全可以从单机模式过渡到集群计算的新模式。事实上，集群计算模型在开源社区中也发展迅速。MYSQLMGR是典型的集群计算架构。只是目前的集群计算架构大多是通过整合数据库和服务组件来构建的，并不是基于数据库的原生态设计，没有硬件、操作系统、数据库内核和服务网关的一体化设计。因此，在应用中也需要大量的工程实现工作，需要在运行时对整个集群进行监控和调整，不能像数据库一样进行一体化部署和运行。事实上，我们完全可以从数据库底层设计一个支持集群计算框架的集中式数据库系统，大大简化了现有集群计算的工程化工作。这种基于集群计算架构的集中式数据库在技术上得以实现。会比分布式数据库简单很多，使用效果肯定是相当不错的。
