内容很多。我的总体思路是从一些概念的边界出发，推导出相关的策略。在这个过程中，我会重点介绍一些实现案例和设计思路。我将从以下四个部分来阐述。一、关于架构思路和一些概念边界1、为什么需要分布式数据库架构？首先，我们需要有一个整体的认识，对此有一个灵魂拷问：为什么需要分布式数据库架构？答案确实是，千千万万个不同的面孔。为此，我整理了一张粗略的图来说明我的观点。早期的数据库架构模式主要是单机模式。虽然单机模式也能满足我们早期的一些业务需求，但是随着数据规模的扩大和业务的快速增长，对单机数据库系统提出了更高的要求，由此延伸出以下发展方向：1)通过更高级的配置原来的单机数据库通过扩容等方式变得更大更强。在这种情况下，数据库就会变成一个“超人”，如上图所示的“超人”。2）业务分成多个部分完成。这个模型后期可能会产生多个分支。如果容量越来越大，需求的复杂度也会越来越高，这可能会涉及到集群模式管理，如上图“三个工人”和“两个超人”所示。3）集群模式可以扩展另一种模式。当原有的单机模式难以扩展时，我们可以将原有的高端单机增加到两个以上，再通过业务拆分完成。这种情况可能会导致尴尬的局面。有些配置在容量足够的情况下会有上限。比如数据库达到一定程度后会“臃肿”。针对这个问题，对于人工难以承载的业务，可以基于代理层来实现，比如上图所示的“六工+代理”。4）如果对上述第三种模式进行扩展，可能会出现另一种模式，即数据存储与数据管理分离，即数据存储与数据计算分离。这个过程需要相关的调度管理进行衔接和协作，如上图右侧所示。以上内容用一个小案例来说明为什么需要分布式数据库架构。初听“分布式数据库架构”可能会比较绕口。下面将区分分布式数据库和数据库分布式架构这两个概念。2.概念边界分布式数据库和云原生数据库的概念近年来非常流行。同时，分布式架构和微服务架构在业界也有大量的实现场景和最佳实践。我们通常所说的分布式数据库和分布式数据库架构还是有一定区别的，但是也有一定的关系，就像下面的包含关系，是一种层次递进的关系。从上图中，我提炼出了几个关键点：分布式数据库是分布式架构的重要组成部分，但又不是完全依赖于它，也就是说业务层的架构设计可以直接影响到整体架构的好坏。分布式数据库架构的发展空间比分布式数据库更大，更贴近业务。分布式只是分布式数据库架构的一种演进策略。云原生数据库是分布式数据库的一种演进形式，相对来说更加垂直。如上图左侧图表所示，分布式分发涉及的整体成本较高，在硬件、软件、开发测试等方面存在差异，目前分布式数据库的布局大致是分为三类：基于分片模式的数据库集群、基于NewSQL的分布式数据库和云原生数据库。不同品类都有相应的典型代表和领军人物。他们都有自己擅长的业务场景和领域。目前基于sharding模式的数据库集群发展比较成熟，而NewSQL和云原生数据库这几年发展迅速，是一种新的数据库架构。进化趋势。说到架构，就要考虑架构的维度。3.通用架构能力通常从弹性扩展、高可用、高性能三个维度来考虑整体架构。这三个维度一般可以衡量架构设计的目标是否达到预期。1）弹性膨胀。原来的单机可能不够用，我们可以通过弹性扩展，把原来的水平扩展进化成弹性扩展。2）高可用性。通过架构能力可以实现中间件节点和数据节点的整体高可用。3）高性能。架构能力可以在读写性能方面获得更高的能力支持。至此，我们对一些概念和架构注意事项有了一个整体的了解。如上所述，架构需要不断演进。那么架构策略有哪些，能否统一呢？我打算从单机和数据两个维度来推导架构的策略。2、从单机和数据维度推导架构策略。架构的演进通常是根据需求和业务发展动态适配的。如果单机配置能够满足容量和性能等资源需求，那么在开发设计周期和系统复杂度上也是一样的。理想的平衡状态也是推荐的，但是很多业务的发展趋势并不是线性的，而是指数级的变化和增长。在这种情况下，有必要在早期的架构设计中进行预防性的架构设计，即我们不能在设计初期就下意识地偷懒。当业务发展的速度与后端的转化能力不匹配时，问题就会接踵而至。很多前期没有考虑到的问题，都是基于分布式设计的。不管但是开发周期和系统复杂度都会让人难以接受。1.单机维度推导架构演进策略单机模式下的分布式架构可以拆分为三个维度：系统配置、数据库配置、数据库相关服务管理。1）系统配置系统配置包括CPU、内存等，相对来说是一种固定模式，扩展起来也比较容易，而且随着硬件的发展其成本也大大降低。简单来说，如果成本在可控范围内，可以通过花钱升级硬件来解决。2）数据库配置数据库配置包括单库容量、单表容量、连接数和吞吐量，其中单库容量的扩展存在一定的瓶颈。从整体上看，数据库配置的扩展会比较困难，但此时有一些复杂性不是单纯升级硬件就能解决的。比如我曾经管理过一个容量为1T的表。对于单机来说，还是要相当谨慎的，这里的难度是中等左右。3）服务管理服务管理包括负载管理、高可用管理、事务管理、运维管理等，在事务管理的复杂度上，单机模式优于分布式。在管理方式上，单机模式采用的是AllInOne模式，可以看成是集中式管理，而分布式管理则需要大量的自动化运维支持。与单机管理相比，分布式管理在负载管理和高可用管理上有了很大的提升。在混合负载方面，原来的单机模式是对整个服务的整体覆盖，但是在分布式架构体系中，必须考虑整体负载能力的提升，不能因为单节点的缺点。整体难度比较高。高的。2.数据维度推导架构演进策略首先将数据分为以下三个维度：1）流式数据流式数据是无状态的，多个事务之间没有关系，每次业务到来都会产生新的文档，比如交易流水、支付流水，只要能插入新的单据，就可以完成业务。特点是后面的数据不依赖前面的数据，所有数据按时间流向入库。2）配置数据配置数据是指我们所说的配置中心字典、数据字典配置等，这类数据数据量小，结构简单。一般是静态数据，变化频率很低。3）StatefuldataStateful数据是有状态的。多笔交易依赖于有状态的数据，必须保证数据的准确性，比如账户余额。充值时必须拿到原余额才能支付成功，所以状态数据的整体维护是最复杂的，这是我们分布式事务管理的核心部分。基于以上数据类型分类，我们可以扩展出三种类型的表：字典表、日志表和状态表。在架构设计和演化上，配置型和管道型数据的扩展方案比较丰富，通常不需要事务管理，所以在扩展和性能上表现都很好，方案比较实用，并且最困难的是状态类型的数据，因为它有数据关联和依赖，所以需要事务管理。在可扩展性和性能方面的解决方案并不完美，需要做出一定的权衡，比如事务降维，或者将对数据强一致性的要求降低到最终一致性等。下面分别对这三类表格进行解读，比较架构演进策略。①字典表的数据量最小，日志表的数据量极大，状态表的数据量与业务规模有关。②数据依赖字典表中基本没有事务依赖，即使有也只存在于极少数的配置中；日志表没有事务依赖，更容易找到修改日志表的切入点；状态表作为一个整体具有事务依赖性。③业务特点字典表整体处于多读少写的模式；日志表以大规模密集读写为主，整体模式为读少写多的模式；状态表整体处于多读多写的模式。④架构策略Architecture1.0策略我们通常基于读写分离模式对字典表进行扩展和改进。对于日志表，我们需要考虑提前拆库拆表。我们称这种模式为元素周期表。对于状态表，我们可以通过读写分离的方式来缓解读取这部分的流量，但是并不能从根本上解决问题。架构2.0策略可以对字典表采用全局分库分表的方式。日志表主要使用业务路由和数据库中间件。状态表比前两者复杂。一种方式是分库分表，另一种方式是基于分库分表的方式做事务降维或者直接在整体流程中做事务降维。事务降维包括两种方式，一种是在整个流程中根据业务的特点不启用事务，另一种是在设计中将事务的维度或粒度最小化，并基于最小化的分片维度进行操作.⑤系统优化策略字典表的优化比较明确。我们可以通过缓存方式对其进行优化，可以解决大部分问题。在日志表的写入过程中，实时延迟不会很高，我们可以基于队列以异步的方式提高整个系统的吞吐量。状态表主要缓存读取部分的状态因子数据。在系统优化策略的维度上，字典表和日志表是比较容易优化的，而状态表的处理和转换策略是一个难点，整个过程都不??能彻底解决问题，总体要求是设计感也比较高。⑥建设目标字典表适用于配置中心建设，日志表适用于票据存储平台建设，状态表适用于数据中心建设。三、架构演进与案例分析在这一部分，我将架构的演进分为三个阶段：1.0、2.0、3.0，以便于后面的描述。这种划分方法的优缺点并没有严格的区分。架构1.0阶段的主要策略是垂直拆分，拆库拆表，读写分离。Architecture2.0阶段的主要策略是基于数据库中间件和业务路由的分布式解决方案。Architecture3.0阶段的主要策略是基于云关系数据库和分布式关系数据库。在整个架构和架构策略的演化过程中，整体的模式类似于上面提到的模式。单机模式在2.0阶段通过业务拆分或者业务路由和数据库中间件策略满足业务需求。3.0阶段，通过存储计算分离和调度层满足业务需求。下面详细解释每个阶段。1.架构1.0阶段及案例该阶段我们通过拆库拆表的方式将商业数据库迁移到MySQL。最初，我们可能处于单机模式。在整个单机模式下，我们通过分库分表，将业务拆分到两个相对独立的服务器上，进而实现日志数据的异步写入。对于有状态数据，我们可以改进读写分离。在1.0阶段，我们通过拆分隔离来拆分业务，包括两种拆分方式：1）将大状态业务拆分为两部分，一部分是全局业务，另一部分是特定目的地业务。例如，一家游戏公司有20款游戏。我们将这些游戏的公共属性数据进行拆分，在平台层进行重组，进而展开不同游戏的独有属性数据。2)在单机模式下拆分日志数据和状态数据。日志数据拆分难度较小，可以通过数据库中间件实现。在拆分日志类数据的过程中，面对大量的读需求，可以通过一主多从来提高读写分离。在这个阶段，数据量大的表很难改。简单来说，单机数据库的流水线数据存在明显的瓶颈。比如一张表每天产生20G的日志，那么单机容量规格假设为300G只能保存2周左右的数据，而数据清洗通常需要业务profile写相应的逻辑进行定时处理，这有在数据库负载和查询性能方面存在一定的隐患。为了改善这个问题，我们提出了周期表的概念，将周期表按照时间分为日、周、月、年、年五个维度。日志数据可以按照这五个维度进行拆分。按照元素周期表拆分日志数据的好处是数据清洗容易，整个清洗过程的维护成本也较低。为了实现数据清洗工作，我们也做了一些情况分类，比如DBA对表的自动扩容和自动清洗。清理表不是直接清理已有的表，而是设置一个时间限制，比如一个月。超过时间限制后，会将表放入回收站，然后对表的内容进行操作。运行后，该表会被放入另一个库中，并在一定时间后逐渐清理。在这整个过程中，如果有一些数据需要恢复，我们可以快速重置。现在我们已经连接了四五百个元素周期表，形成了一个自循环的管理模式。对于公司整体的业务来说，几乎很难看到一些数据量恐怖的表格，因为这些基本都是杜绝的。二、架构2.0演进及案例1）消息服务路由改造在架构2.0阶段，首先对业务路由进行改造。早期我们做消息业务的改造，比如打开APP后的消息推送，整体吞吐量比较大。在早期的业务中，对于消息存储的数据统计要求比较高，我们希望能够第一时间将消息推送给用户并获得反馈，让整个业务运行形成一个闭环。如上图右侧所示，是数据库端的I/O使用情况。在I/O优化的过程中，一个master节点难以承载，所以我们将查询需求扩展到slave节点，实现读写分离。发现还是没有达到要求，统计查询还是很慢，I/O使用率还是爆满。我们扩展了列式存储并迁移了统计查询以提高查询效率。可以看作是解决查询瓶颈问题的方法。原有服务的I/O使用率降低了60%以上。动态扩展到三个节点，如上图左侧所示，性能有了明显的提升，提升了20%左右。整个过程是一个逐步优化的过程。2）第二种数据库中间件是基于数据库中间件模型。数据库中间件方式需要考虑同城异地的数据重分布、数据可用性、容灾等。基于这种架构模型，我们还提供了一些专门的服务，主要包括4点：中间件负载均衡数据库集群架构模型，通过Consul服务将原来的三层结构变成两层，实现了中间件层。负载均衡。配置建表针对在线数据库集群的建表需求，我们通过配置实现数据表的自定义创建。比如当我们需要创建一个表时，只需要在配置表中写入一条配置信息，然后我们就会通过服务扫描配置变化。如果有变化，我们将在线创建相关表格以确保业务连续性。流程看似简单，其实对集群的结构设计要求很高。对于集群的数据传输，数据传输是数据分离和组合的一个难点。我们通过中转程序来实现，比如DataX做数据聚合。为此，我们构建了一个中间层来统一传输。后续思路是直接将账单存储改造为NewSQL数据库，直接提供实时数据传递。只读查询一些复杂的在线数据查询也可以通过只读中间件完成。挂载到只读中间件节点，可以顺利实现在线数据查询。+NewSQL集群）提供流畅的读写需求。如果说这四点的力量还不够的话，那么中间件架构还有以下两个典型的优势可以补充，即数据再分布和分布式集群组的存储方式。①数据再分配的第一个好处就是数据再分配，因为中间件架构既有优点也有缺点。我们在实践中经历了很多考验。对于中间件架构，我个人认为它最大的特点就是拓扑结构的可扩展性。性别。例如，硬件服务器在保修多年后需要更换，而每台服务器的更换仍然会造成系统抖动。如果有几十个节点，这个替换其实会有一定的风险。基于中间件架构，可以快速实现拓扑扩展，如上图所示。如图，可以添加一组从库节点，然后收缩中间件，再将三层拓扑切换为两层。对于几十个或者上百个节点的快速切换，这是一种非常优雅的模式。整个切换过程大约3.5秒，当业务服务有重连机制的时候，集群内部其实已经发生了质的变化。②优势分布式集群组/通用存储方案设计第二个优势是分布式集群组/通用存储方案设计。比如数据库的整体分布式架构需要满足业务需求。发现很多数据表结构都是相似的，在这种情况下，我们可以实现动态灵活的存储管理方式。主要分为两个维度：第一，通用存储，就是说我们原来的一套集群不够用了，我们可以再增加一套集群来实现，就是集群组的模式。在这一层，我们把集群降到一层，在上层进行配置管理。上层有全局配置；其次，我们可以通过全局配置快速灵活的生成一些自定义的表结构，比如业务的数据存储要求是varchar(32)，有的是varchar(256)或者bigint。这些可以在集群组中动态配置，以适应不同的模板。这是通过这种灵活的配置管理方式实现的，对整个集群组数据进行存储管理。3、架构3.0演进与技术分析我们经常听到云关系型数据库、分布式关系型数据库等概念。个人整理后发现，在数据库的整个演进过程中，有很多故事。Google很早就开始在内部孵化Spanner，并在2011年左右发表了一篇论文，论文发表后，形成了两个分支。一个分支对原始模型不满意，另一个分支受到原始模型的启发对其进行改进。以上两个分支延伸出两大派系，一个是基于Aurora模型，基于这个思路产生了Aurora数据库，比如腾讯的CynosDB，阿里云的PolarDB。另一种是在Spanner论文思想的影响下，基于另一个系统生成TiDB等数据库。从整体上看，两派最大的区别在于Aurora等数据库与MySQL没有太大区别，整体结构采用了存储和计算分离的架构，而另一派则采用了NewSQL的全新设计体系，即兼容MySQL协议。Form出现，两者属于不同的体系，在数据库分布式架构策略上有不同的实现，从早期的读写分离模式到元素周期表、中间件，以及未来新的中间件。1）数据库分布式架构策略对比事实上，云原生数据库在概念上是弯道超车。在云原生数据库中，极光是数据库的典型代表。底层设计本质上是一种读写分离模式，但核心技术是分布式共享存储，从读写分离模式进行了重大更新。①云原生数据库-Aurora下面简单介绍一下具有代表性的Aurora数据库。AWS在MySQL的基础上进行了魔改。因为AWS对Spanner的事务处理能力不满意，所以提出日志就是数据库，重新设计了数据库。写分离集群扩展Aurora数据库，整体6副本，底层基于S3，整体采用读写分离模式。②CynosDB、PolarDBCynosDB和Aurora有一些区别，但整体结构是存储和计算分离的。基于Raft，redo被下推到存储管理。PolarDB基于RDMA，不会将redo下推到存储。它的本质还是基于存储和计算的分离。③TiDB架构我们TiDB研究时间比较早，前期长期沉淀在测试环境，后来逐渐从日志数据库的改造开始，逐步引入更多的业务范围。4.数据库分布式架构演进总结通过总结我们在分布式架构方面的实践，我把整个分布式架构分为两个维度，一个维度是从水平扩展能力的角度考虑的，另一个维度是从水平扩展能力的角度考虑的吞吐量。如果原来的单机在起点，垂直拆分可能会有很大的提升。2018年我们大量使用了读写分离模式，当然读写分离模式对于很多敏感业务没有那么严谨，但是在很多数据不是那么敏感或者延迟比较高的情况下是一个比较简单的架构改进没那么敏感。.在演进过程中，我们少走了一些弯路。我们预先对很多billingtable的数据进行布局拆分，转化为周期表模型。元素周期表模型改造后，我们目前已经很少见到数据量非常大的表格了。基于此，我们自然而然地引入了中间件的分库分表方案。对于中间件集群方案，我们后续有两种模式，一种是做业务拆分，另一种是将原有的通用存储方案并入，通过配置实现集群分组管理。过了这个阶段，就会有一个分界点，这也是数据库事务管理的最后一个非常核心的点。在事务管理方面，一种是复杂的管理模型，另一种是最小粒度的事务管理。之后已经尝试了新的中间件和NewSQL系统，技术栈将在2021年实现。这里补充一些数据，对不同的架构策略做一些对比。从整个分布式系统来看，各方面都有利有弊。我们要理性的看待一个技术，NewSQL系统不一定是最好的。为了保证观点的严谨性，我通过雷达图从以下几个方面对标准版实例、数据库中间件和NewSQL进行了评估。事务管理基于单机模式的长期验证，标准实例在事务管理上最具优势。事务管理中的中间件瓶颈。NewSQL集群的思维模型依赖于另一个系统，需要时间段的验证和业务场景的匹配，所以介于两者之间。验证周期单机模式验证周期长。迁移升级三者在迁移方面都有比较成熟的体系。高可用与其他两者相比，NewSQL在高可用方面具有明显的优势。扩容单机模式在扩容和缩容方面比较有限。NewSQL在扩缩容方面最有优势，可以实现一定的弹性扩缩容。性能中间件方案对某些性能极为敏感，在设计良好的情况下其整体性能更有优势。综上所述，应根据不同场景选择适合的方案，不能一刀切。四、技术展望与总结1、数据库架构演进趋势分析1）数据库生态本土化从整个数据库架构的演进过程来看，目前的数据库生态越来越多元化，也存在一定差异和差异Risk，这里我想提一下本地化数据库，因为它在生态中是不可或缺的。目前国内数据库的国产化程度还是比较高的。纵观近几年研发技术与数据库的紧密结合，很明显研发方向是减少对数据库的逻辑依赖，通过分布式技术架构来满足。对性能和扩展性有很强的需求，而互联网作为开源技术的试验田，提供了大量的业务场景，使得开源软件能够不断成熟迭代。在功能实现上，国产数据库也更适合国内用户的需求和体验。从这个角度来看，本地化的数据库通常具有分布式的生长基因。但是，业界也在短时间内产生了大量的数据库定制化产品。这些是核心组件和底层服务之外的部分定制，使用户很容易在各种本地化数据库中感到困惑。如果数据库只是为了对标和兼容其他商业数据库，我个人觉得会过于局限和局限，因为过多的泛应用会让数据库技术基础不够扎实，过分迎合用户体验.在设计理念上的妥协会让数据库技术难以聚焦，限制其更大的潜力。2）Dolessvsdomore在数据库分布式架构的改造中，少做对我来说是一种颠覆性的收获。我们早期在提升分布式架构的性能时，希望做的更多，支持更高的OPS，提供更高更强的性能。然而，我们发现在架构改造的过程中，情况恰恰相反。我们是从商业角度来做的。一些架构优化其实可以达到更好的效果。最后发现原来支持几十万的OPS，优化之后，几万的OPS就够用了。从这个角度看，分布式数据库架构还有很大的发展空间。3）分布式共享存储云原生数据库有共享存储的影子。比如Aurora，就是基于读写分离模式。它之所以能够在分布式方向实现弯道超车，是因为其核心部分是分布式共享存储技术。在原生数据库中，原本看似“土”的共享存储模型，居然玩出了新花样。4）HTAP需要理顺原有单一的OLTP和OLAP业务，在开发和管理上存在诸多不便，而HTAP可以在一定程度上有效结合两者的优势，从而提供更加统一高效的数据服务。我想这应该是近几年HTAP大火的原因吧。在此基础上，我建议警告数据扩展的问题。ALLIN问题带来的隐患，随着时间的推移，难度会越来越大。所以对于HTAP的方案，我不是很认同AllInOne的模式，或者有一些顾虑，需要理性的看待HTAP的方案。2、基于机器学习的数据库监控异常预测研究近年来，AIOps还是很火的，数据库也会搭这便车。前段时间，我进行了一些机器学习相关的研究。我用机器学习预测了数百台服务器的相关监控数据。如上图所示，我们基于回归模型和时间序列模型进行了预测。总体上，我们基本实现了对这些指标的一定周期性预测。那么问题来了，机器学习异常预测和分布式架构有什么关系？按照我的理解，原来数据库的负载预测是基于单机模式的，但是当我们考虑集群分布式架构的时候，我们需要从更全局的集群角度来看，缺点的定位很不同于单机模式。从这个角度来说，如果我们有一些分布式系统的异常预测模型，我们可以在此基础上做更多的工作。杨建荣竞技世界数据库专家dbaplus社区联合创始人，腾讯云TVP、OracleACE、《Oracle DBA工作笔记》、《MySQL DBA工作笔记》作者；现工作于竞争激烈的世界，擅长数据管理、数据迁移、性能优化，目前专注于开源技术、运维自动化和性能优化，坚持写技术博客，坚持了2400多天。
