金融行业分布式数据库转型之路

　　分布式数据库是相对于集中式数据而言的，具备分布式数据管理能力的一种新型数据库软件产品。是面对高性能、大数据量业务系统，特别是无法进行大规模重构的业务系统，实现分布式能力引入的一种有效解决方案。分布式数据库具备数据分片管理、分布式事务、读写分离等关键分布式能力，能够为应用提供类似与集中数据库的使用方式，可以降低应用实施分布式改造的复杂度。近年来，各国产厂商都在积极推进分布式数据库产品的研发，技术已经逐步成熟，金融行业也已经有成功案例投入生产系统使用。本文尝试从多个角度，阐述金融行业分布式数据库转型所面临的问题及解决思考。
　　1. 背景：为何会走向分布式
　　人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。
　　1).业务驱动
　　移动互联网和电子支付的蓬勃发展对金融系统能力带来全新的挑战
　　金融行业的数据急剧增长，对数据存储和管理提出了更高要求
　　面临高并发业务和大用户量带来的系统压力
　　要求移动应用响应速度更快
　　大型机系统已经是全球最大规模的系统，可靠性风险逐渐上升
　　2).政策指导
　　《金融科技（FinTech）发展规划（2019-2021）》中明确指出：＂加强分布式数据库的研发应用。做好分布式数据库金融应用的长期规划，加大研发与应用投入力度。有计划、分步骤稳妥推动分布式数据产品先行先试，形成可借鉴、能推广的典型案例和解决方案，为分布式数据库在金融领域的全面应用探明路径。建立健全产学结合、校企协同的人才培养机制，持续加强分布式数据库底层和前沿技术研究，制定分布式数据库金融应用标准规范，从技术架构、安全防护、灾难恢复等方面明确管理要求，确保分布式数据库在金融领域的稳妥应用。＂
　　2. 分布式可选技术路线
　　人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。
　　1).路线：分布式中间件+单机数据库
　　这类产品，一般采用了典型的＂Share Nothing＂架构，实现存储与计算分离，通过上层无状态的计算节点提供弹性可扩展的计算能力，下层通过增强单机数据库提供基础存储能力及本地算力。这一架构通过硬件堆叠，可近似线性地提供计算性能和存储容量，具有可支持超大规模集群的能力。
　　❖ 产品优势
　　这一架构产品的优势在于功能丰富、可按业务做定制；稳定性较高，基于成熟稳定的单机引擎。在面对超大规模数据存储，通过灵活的分片配置策略，支持高灵活度数据打散技术，并可贴近场景需求定制分片。
　　❖ 产品劣势
　　相对不足在于全局事务能力、全局MVCC、副本控制、高可用等方面存在先天短板，需要有针对性增强。例如引入全局事务管理器组件，突破单机限制，实现分布式事务的实时一致性及全局MVCC能力，对应用透明的分布式事务处理，应用无需改造。通过一阶段提交+自动补偿机制，提升分布式事务处理性能。针对数据强一致性的要求，在单机库同步技术基础上，通过内核级的增强优化实现更高级别的复制保证数据不丢失。此外，由于需维护多节点一致性而带来的在跨分片DDL、分片节点扩容、跨节点复杂查询、全局一致的备份恢复等方面问题值得关注。
　　❖ 最佳实践
　　这种架构产品较为适用于数据规模巨大、对延迟要求很高的在线交易场景。在数据库设计时，需要特别注意分区键和分区策略的选择，合理布局数据，尽量避免跨节点的分布式事务处理，以提高数据库的效率。
　　2).路线：原生分布式数据库
　　这类产品，一般也是采用＂Share Nothing＂架构，实现存储与计算分离。与上面不同的是，底层多采用自研或裸存储引擎，数据按规则打散并存储多个副本，通过paoxs/raft等分布式协议保证多个副本间数据一致。上层实现数据库基础的优化器、执行器等组件，对分布式事务、全局MVCC等支持更为彻底。此外，由于其底层的存储引擎不是依赖某一产品，可根据需要组织数据，因此在适配场景上更有优势，例如在某些分析类场景可选择列存。
　　❖ 产品优势
　　Native的原生实现，工程上不依赖其他产品，可控程度更高。面对很多新的需求，可从底层加以实现支持，不受限于第三方。在副本控制、数据一致性、容灾、弹性能力等方面更具有优势。此外，场景方面有更为灵活的选择及未来可扩展的空间。
　　❖ 产品劣势
　　产品成熟度，仍需较长时间沉淀。特别是使用在核心业务场景，仍然需要较长时间的锤炼。此外，其内置的分片规则，对于某些需贴合业务的架构设计不太友好。对于高并发、低延迟的极端场景仍然有一定局限。
　　3).路线：云原生数据库
　　在某种程度上讲，云原生数据库也是一种分布式，但与前两者区别是非Share Nothing架构，而是Share Everything模式。其底层是与分布式云存储，本质上来说仍然是一种集中式架构。上层的计算部分，是无状态的一组结点组成。针对这种架构不足展开说明，原因是这种方式是需要对底座有比较重的依赖，无法在金融行业相对要求独立环境中部署，除非整个底层都更换。因此，使用选择上存在一定困难。
　　4).路线：业务自研+(开源)单机数据库
　　这一模式是在传统单机数据库的基础上，通过业务自研完成数据拆分。在处理上，尽量通过业务单元化方式，将数据集中在单元内完成；即使极少数需要跨单元，也可以通过应用层面解决事务类问题。
　　❖ 产品优势
　　优势很显然，底层基础设施不用修改，避免了引入新产品带来的风险及其他管理成本。可根据业务需求灵活定制，对底层依赖很小，未来的迁移、扩容等很从容。
　　❖ 产品劣势
　　最大的缺点无疑是成本及效率。由于其对业务有较大侵入性，需要投入较大的开发维护成本，当然也有些可改进的方式。如引入数据库中间件类的产品，将逻辑尽可能封装在底层，上层可更专注于业务开发。
　　5).技术路线对比
　　根据不同技术栈的特点，在不同场景上各有所擅长。下面简单总结的一些场景，当然不同企业在技术路线选择上，不仅仅会考虑技术特点，还要综合其他多种因素。
　　6).最佳实践：解耦路线依赖
　　通过数据库的技术标准化和轻量化工作，形成统一的数据库使用规范，解耦应用和底层数据库技术架构，在标准数据库协议及语义下，可以很轻松的更换数据库架构。通过构建异构间数据同步、流量接入控制（限流、灰度等）、全局数据服务（如事务、快照等），实现业务的无感切换和迁移回退，保证最大的灵活可控。
　　3. 技术路线选型路径
　　人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。
　　1).选型难点
　　银行在分布式数据库选型应用上也有几大难点：
　　一是复杂业务逻辑问题，包括数据库技术基因匹配性（如：数据库本身锁机制、隔离级别问题），包括技术兼任性（如存储过程、视图兼容性）；
　　二是应用的适配度问题，银行应用大部分都是基于单机关系型数据库机制设计的，例如大部分场景都是串行机制，发挥不出来分布式数据库的强大并发处理技术，反而分布式数据库本身的二阶段提交机制，对简单事务的延时增加问题，造成串行事务执行性能低下；
　　三是人员能力的匹配性，需要根据人员技术能力进行选型考虑，例如基于Spanner体系，基于Aurora体系，基于国内互联网公司自研的产品等，要考虑现有人员对数据库技术的了解程度，更要关注数据库技术本身的开放度和社区热度，让人员可以很快的学习和提升数据库技术能力；
　　四是数据库自身能力问题，包括在分布式事务、数据一致性、高可用容灾等，相较于传统集中式数据库还是存在一些不足；此外金融业在联机交易的低延迟要求、跑批类的高吞吐要求也对分布式数据库提出了很高的要求；
　　五是数据库运营维护问题，包括是否具备足够能力维护分布式数据库？是否能够接受数据库转型期间的业务中断时间？是否具备迁移（甚至在线）迁移能力？是否具有应用级双发能力，规避可能出现的风险？等
　　2).选型要素
　　技术为业务服务的，不能为了使用技术而使用，需要综合考虑成本和收益的平衡。分布式数据库使用场景，应当在数据大规模、高并发、高可用性等场景下有其特有优势。一般的业务场景如果能用单机数据库支撑的尽量用单机库。选择一款分布式数据库，会带来一系列的成本，如应用适配成本、运维成本、硬件成本，这方面后面会赘述。此外，在做上述判断时，还需考虑业务的发展，最好是能判断三年的数据量和交易量的增长变化。
　　在进行分布式选型时，可重点考察下列几个方面：分布式事务
　　分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。但在设计之初，就应尽量做到业务单元化，将事务控制为本地事务，这可大大提升执行效率。性能
　　由于二阶段提交和各节点之间的网络交互会有性能影响，分布式数据库优势不是单个简单sql的性能，但是大数据量的sql查询，每个节点会将过滤之后的数据集进行反馈，会提升性能，并且分布式数据库的优势是并发，大量的sql并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的SQL语句的事务，OLTP类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。建议尽量改造存在跨节点数据流动的SQL语句（主要是多表关联）的事务。数据备份
　　分布式数据库一致性保证通过内部时钟机制，所有节点都会遵循一致的时钟，所以备份恢复的增量也是基于时钟，相当于单机数据，但是分布式数据库的备份解决方案最重要标志是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐会大很多，还有就是是否支持一些分布式备份方案，比如S3协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候制定节点进行恢复到指定时间点，整个过程可配置自动任务自动执行。高可用
　　分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署，如果同城主备可以采用集群级的异步复制。异地建议采用集群级的binlog异步复制。建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件T+1恢复到异地灾备。数据一致性
　　NewSQL分布式数据库基本都是通过获取全局时钟时间戳，采用二阶段提交实现一致性，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务＂中间状态＂的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。其他因素
　　金融行业在数据库选型中，除了需要考虑上述四点外，还有其他一些因素的考虑。如原有系统的承载能力、是否必须进行选择等。
　　3).选型依据
　　除了上述技术因素外，在选型中还需考虑系统运行现状，可重点参考下述指标：系统数量
　　考量租户能力数据量
　　考量系统承载力系统性能指标
　　TPS、QPS、RT等并发量
　　系统的最大并发数：为了节省成本，多套小系统可以共用一套数据库，但是负载很大的高并发场景还是独立搭建。 业务中断时间
　　系统最大可容忍的业务中断时间：分布式数据库节点宕机并不是对业务没有任何影响，主节点宕机都涉及到一个切换的问题，切换就是影响业务的时间，要充分评估业务能否忍受这么长时间的中断。 系统的迁移成本
　　分布式数据库不可能做到oracle、db2、mysql所有数据库的百分之百兼容，所以不同类型的数据库在迁移上都会或多或少的涉及到应用的改造。
　　4).资源评估
　　除了对运行时的各种因素评估外，作为底层技术基础设施的更换，还需要考虑基础资源的使用。分布式数据库通常会采用廉价x86 pc服务器，搭配本地ssd固态盘、万兆网卡，单体硬件成本较低。但在服务器数量上，需要有更多考虑。一方面分布式数据库组件众多，且每个组件都需要高可用配置，即使部分可采用混部方式解决，但在整体数量上仍然会较多。此外，还需要考虑各组件的负载模型不同、关键组件独立部署、数据多副本等等问题。另一方面，结合重点关注的性能数据、例如支持的QPS等，从而计算出服务器数量需求。需要注意的是，分布式数据库厂商提供的性能测试采用的服务器参数，一般是高配服务器，如果实际生产使用服务器配置降低，还则要考虑性能数据损耗等问题。
　　5).运维评估
　　作为 一种新型的数据库产品，对运维方面也会带来不小的工作。至少包含了以下一些方面：硬件评估
　　如上面＂资源评估＂所谈到的。软件规划和部署方案
　　分布式数据库组件众多，而且每个组件都有高可用备份，所以在有限数量的服务器下进行组件的分配要尽量考虑达到各个服务器负载的均衡，GTM作为分布式数据库的瓶颈尽量和他们组件分开部署。监控方案
　　监控一般可以采用开源的zabbix进行定制化开发，当然也可以基grafana+prometheus的方案做监控。但一般大中型金融企业都有一套自己的监控系统，这里需要有个对接适配的过程。此外，由于分布式的多组件特点，在监控指标数量及指标间关联上，与传统数据库差异巨大，是需要监控摸索过程。语句调优
　　因为不同厂商研发的数据库SQL优化器及执行计划都有所不同，所以要根据不同产品进行学习。天然由于分布式架构带来的复杂度，也会影响到语句的执行效率。比较常见的如数据库访问链路长所带来的的问题、数据分布不均带来的问题及分布式优化器的问题等。备份方案
　　分布式数据库如何做到多节点全局一致性备份也是难点，要做到真正意义上的基于时点恢复，就需要做到分布式环境下每个全局事务的可追溯操作。应急方案
　　因为分布式数据库还处于发展阶段，还不成熟，技术比较复杂，所以生产环境下要制定详细的应急方案，让不了解分布式数据库的同事也能够在出现问题时按照手册操作。DDL变更
　　在分布式架构下，DDL变更是个难点。如果做到全局一致，做到业务无感知，是核心点。不同厂商产品实现能力层次不齐，介于此安排在低峰期操作并做好必要的监控回退。水平扩容
　　分布式架构下，都是支持水平扩容的。一般来说，非数据节点的扩容是相对容易的，对业务也是无感的，但涉及到数据节点的扩容，势必会遇到数据reshard的问题。建议选择在低峰期，同时控制好扩容粒度。即便如此，仍然建议提前做好容量规划，避免扩容。跨片计算
　　分布式架构下，数据是分布在多个节点中。如果数据计算是可以在本地计算完成，无疑是效率最高的，但完全避免跨片计算是不太现实的。如果发生跨片计算，则不可避免地对上层节点带来压力，要做好相应监控，并争取在根本上避免跨片类计算。
　　4. 分布式转型成本分析
　　人生基本上就是两件事，选题和解题。最好的人生是在每个关键点上，既选对题，又解好题。人生最大的痛苦在于解对了题，但选错了题，而且还不知道自己选错了题。正如人生最大的遗憾就是，不是你不行，而是你本可以。
　　分布式转型，势必会带来一定的成本。这里尝试将可能带来的成本做个分析：
　　1).成本分析
　　这里我们将成本分解为几个方面：硬件成本
　　分布式数据库不依赖于特有硬件，标准X86服务器或者国产化服务器即可，存储多为本地存储即可，推荐使用SSD甚至是NVMe SSD，网络一般万兆网络即可。在这部分主要成本是取决于集群规模、数据量及数据库自身架构。此外，如果涉及到灾备方案，还需要考虑灾备环境的硬件投入及主备间的专线费用。软件成本
　　这部分是来自分布式数据库本身的软件采购成本，成本取决于各厂商的内部商业策略。但这部分总体来讲，是较传统数据库产品还是有优势的。此外，这部分还涉及到维保费用，针对分布式数据库来说，相对较新，企业自有能力尚不具备，还是建议购买原厂服务或其他三方公司的服务，降低风险。开发测试成本
　　这部分是指针对数据库更换后，应用需要需要完成的必要的开发测试成本。这部分成本差异很大，跟原有系统实现有较大关系。如果原有系统重度依赖数据库（大量功能是基于数据库自身功能实现的），那么存在的改造量较大。新型分布式数据库的功能，不能与传统数据库做一一对应，很多能力是需要在应用层重构完成。针对这种情况，是建议应用开发遵循数据库标准方式进行（如采用MySQL作为标准）开发，这样如有改型也很简单。此外，还有一类隐形成本包含在这部分，如果业务比较重要，是需要考虑双发支持或灰度迁移的方式，这会带来一部分工作量。总体来说，这部分成本是比较高的，可能占整体成本的大部分。运营维护成本
　　这部分成本，包括了为满足更换数据库所带来的数据迁移成本和上线后的日常维护成本。针对前者，可以在应用侧解决或者外采商业软件解决；后者更多是人员管理成本。针对这部分成本，是有个相对较长的投入，且整体成本不少。
　　2).方案成本对比
　　采用不同的技术路线，针对上述的成本投入是存在较大差异的。硬件成本
　　前两种数据库方案需要有专门投入，且这两种方式都有较多的组件，因此硬件投入较大。采用开源数据库的方案，相对投入较少，很多能力是通过上层业务自研完成，不依赖数据库。软件成本
　　前两种数据库方案是需要单独采购软件，整体费用较高；第三种使用开源，一般只需维保类费用，费用相对较低。开发测试成本
　　前两种数据库方案是作为相对独立的产品出现，对业务研发有一定影响，但影响不大；第三种对业务有很大耦合性，需要在开发侧投入更多的资源。运营维护成本
　　维护方面，第一种方案可部分依靠单机库的运维能力，增加对分布式的运维支持；第二种方案引入新的一种数据库，需要有更多运维侧的投入；第三种主要依靠开源库的运维能力，需要有一定人力成本。
　　韩锋频道：
　　关注技术、管理、随想。