金点分享
本期受邀分享的嘉宾是韩锋：CCIA（中国计算机协会）常务理事，前Oracle ACE，腾讯TVP，阿里云MVP，dbaplus等多家社群创始人或专家团成员，现在建信金科担任数据库资深专家。韩锋有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验。曾担任多家公司首席DBA、数据库架构师等职。韩锋在云、电商、金融、互联网等行业均有涉猎，精通多种关系型数据库，对NoSQL及大数据相关技术也有涉足，实践经验丰富。曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。
1. 背景：为何会走向分布式
金融行业的数据急剧增长，对数据存储和管理提出了更高要求 面临高并发业务和大用户量带来的系统压力 要求移动应用响应速度更快 大型机系统已经是全球最大规模的系统，可靠性风险逐渐上升
2. 分布式可选技术路线
3. 技术路线选型路径
一是复杂业务逻辑问题，包括数据库技术基因匹配性（如：数据库本身锁机制、隔离级别问题），包括技术兼任性（如存储过程、视图兼容性）； 二是应用的适配度问题，银行应用大部分都是基于单机关系型数据库机制设计的，例如大部分场景都是串行机制，发挥不出来分布式数据库的强大并发处理技术，反而分布式数据库本身的二阶段提交机制，对简单事务的延时增加问题，造成串行事务执行性能低下； 三是人员能力的匹配性，需要根据人员技术能力进行选型考虑，例如基于Spanner体系，基于Aurora体系，基于国内互联网公司自研的产品等，要考虑现有人员对数据库技术的了解程度，更要关注数据库技术本身的开放度和社区热度，让人员可以很快的学习和提升数据库技术能力； 四是数据库自身能力问题，包括在分布式事务、数据一致性、高可用容灾等，相较于传统集中式数据库还是存在一些不足；此外金融业在联机交易的低延迟要求、跑批类的高吞吐要求也对分布式数据库提出了很高的要求； 五是数据库运营维护问题，包括是否具备足够能力维护分布式数据库？是否能够接受数据库转型期间的业务中断时间？是否具备迁移（甚至在线）迁移能力？是否具有应用级双发能力，规避可能出现的风险？等
分布式事务 分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。但在设计之初，就应尽量做到业务单元化，将事务控制为本地事务，这可大大提升执行效率。 性能 由于二阶段提交和各节点之间的网络交互会有性能影响，分布式数据库优势不是单个简单sql的性能，但是大数据量的sql查询，每个节点会将过滤之后的数据集进行反馈，会提升性能，并且分布式数据库的优势是并发，大量的sql并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的SQL语句的事务，OLTP类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。建议尽量改造存在跨节点数据流动的SQL语句（主要是多表关联）的事务。 数据备份 分布式数据库一致性保证通过内部时钟机制，所有节点都会遵循一致的时钟，所以备份恢复的增量也是基于时钟，相当于单机数据，但是分布式数据库的备份解决方案最重要标志是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐会大很多，还有就是是否支持一些分布式备份方案，比如S3协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候制定节点进行恢复到指定时间点，整个过程可配置自动任务自动执行。 高可用 分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署，如果同城主备可以采用集群级的异步复制。异地建议采用集群级的binlog异步复制。建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件T+1恢复到异地灾备。 数据一致性 NewSQL分布式数据库基本都是通过获取全局时钟时间戳，采用二阶段提交实现一致性，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。 其他因素 金融行业在数据库选型中，除了需要考虑上述四点外，还有其他一些因素的考虑。如原有系统的承载能力、是否必须进行选择等。
系统数量 考量租户能力 数据量 考量系统承载力 系统性能指标 TPS、QPS、RT等 并发量 系统的最大并发数：为了节省成本，多套小系统可以共用一套数据库，但是负载很大的高并发场景还是独立搭建。 业务中断时间 系统最大可容忍的业务中断时间：分布式数据库节点宕机并不是对业务没有任何影响，主节点宕机都涉及到一个切换的问题，切换就是影响业务的时间，要充分评估业务能否忍受这么长时间的中断。 系统的迁移成本 分布式数据库不可能做到oracle、db2、mysql所有数据库的百分之百兼容，所以不同类型的数据库在迁移上都会或多或少的涉及到应用的改造。
硬件评估 如上面“资源评估”所谈到的。 软件规划和部署方案 分布式数据库组件众多，而且每个组件都有高可用备份，所以在有限数量的服务器下进行组件的分配要尽量考虑达到各个服务器负载的均衡，GTM作为分布式数据库的瓶颈尽量和他们组件分开部署。 监控方案 监控一般可以采用开源的zabbix进行定制化开发，当然也可以基grafana+prometheus的方案做监控。但一般大中型金融企业都有一套自己的监控系统，这里需要有个对接适配的过程。此外，由于分布式的多组件特点，在监控指标数量及指标间关联上，与传统数据库差异巨大，是需要监控摸索过程。 语句调优 因为不同厂商研发的数据库SQL优化器及执行计划都有所不同，所以要根据不同产品进行学习。天然由于分布式架构带来的复杂度，也会影响到语句的执行效率。比较常见的如数据库访问链路长所带来的的问题、数据分布不均带来的问题及分布式优化器的问题等。 备份方案 分布式数据库如何做到多节点全局一致性备份也是难点，要做到真正意义上的基于时点恢复，就需要做到分布式环境下每个全局事务的可追溯操作。 应急方案 因为分布式数据库还处于发展阶段，还不成熟，技术比较复杂，所以生产环境下要制定详细的应急方案，让不了解分布式数据库的同事也能够在出现问题时按照手册操作。 DDL变更 在分布式架构下，DDL变更是个难点。如果做到全局一致，做到业务无感知，是核心点。不同厂商产品实现能力层次不齐，介于此安排在低峰期操作并做好必要的监控回退。 水平扩容 分布式架构下，都是支持水平扩容的。一般来说，非数据节点的扩容是相对容易的，对业务也是无感的，但涉及到数据节点的扩容，势必会遇到数据reshard的问题。建议选择在低峰期，同时控制好扩容粒度。即便如此，仍然建议提前做好容量规划，避免扩容。 跨片计算 分布式架构下，数据是分布在多个节点中。如果数据计算是可以在本地计算完成，无疑是效率最高的，但完全避免跨片计算是不太现实的。如果发生跨片计算，则不可避免地对上层节点带来压力，要做好相应监控，并争取在根本上避免跨片类计算。
4. 分布式转型成本分析
硬件成本 分布式数据库不依赖于特有硬件，标准X86服务器或者国产化服务器即可，存储多为本地存储即可，推荐使用SSD甚至是NVMe SSD，网络一般万兆网络即可。在这部分主要成本是取决于集群规模、数据量及数据库自身架构。此外，如果涉及到灾备方案，还需要考虑灾备环境的硬件投入及主备间的专线费用。 软件成本 这部分是来自分布式数据库本身的软件采购成本，成本取决于各厂商的内部商业策略。但这部分总体来讲，是较传统数据库产品还是有优势的。此外，这部分还涉及到维保费用，针对分布式数据库来说，相对较新，企业自有能力尚不具备，还是建议购买原厂服务或其他三方公司的服务，降低风险。 开发测试成本 这部分是指针对数据库更换后，应用需要需要完成的必要的开发测试成本。这部分成本差异很大，跟原有系统实现有较大关系。如果原有系统重度依赖数据库（大量功能是基于数据库自身功能实现的），那么存在的改造量较大。新型分布式数据库的功能，不能与传统数据库做一一对应，很多能力是需要在应用层重构完成。针对这种情况，是建议应用开发遵循数据库标准方式进行（如采用MySQL作为标准）开发，这样如有改型也很简单。此外，还有一类隐形成本包含在这部分，如果业务比较重要，是需要考虑双发支持或灰度迁移的方式，这会带来一部分工作量。总体来说，这部分成本是比较高的，可能占整体成本的大部分。 运营维护成本 这部分成本，包括了为满足更换数据库所带来的数据迁移成本和上线后的日常维护成本。针对前者，可以在应用侧解决或者外采商业软件解决；后者更多是人员管理成本。针对这部分成本，是有个相对较长的投入，且整体成本不少。
硬件成本 前两种数据库方案需要有专门投入，且这两种方式都有较多的组件，因此硬件投入较大。采用开源数据库的方案，相对投入较少，很多能力是通过上层业务自研完成，不依赖数据库。 软件成本 前两种数据库方案是需要单独采购软件，整体费用较高；第三种使用开源，一般只需维保类费用，费用相对较低。 开发测试成本 前两种数据库方案是作为相对独立的产品出现，对业务研发有一定影响，但影响不大；第三种对业务有很大耦合性，需要在开发侧投入更多的资源。 运营维护成本 维护方面，第一种方案可部分依靠单机库的运维能力，增加对分布式的运维支持；第二种方案引入新的一种数据库，需要有更多运维侧的投入；第三种主要依靠开源库的运维能力，需要有一定人力成本。
韩锋频道：
关注技术、管理、随想。
长按扫码可关注
「喜欢这篇文章，您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文章的来源（墨天轮），文章链接，文章作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
