• 四是数据库自身能力问题，包括在分布式事务、数据一致性、高可用容灾等，相较于传统集中式数据库还是存在一些不足；此外金融业在联机交易的低延迟要求、跑批类的高吞吐要求也对分布式数据库提出了很高的要求；     

技术为业务服务的，不能为了使用技术而使用，需要综合考虑成本和收益的平衡。分布式数据库使用场景，应当在数据大规模、高并发、高可用性等场景下有其特有优势。一般的业务场景如果能用单机数据库支撑的尽量用单机库。选择一款分布式数据库，会带来一系列的成本，如应用适配成本、运维成本、硬件成本，这方面后面会赘述。此外，在做上述判断时，还需考虑业务的发展，最好是能判断三年的数据量和交易量的增长变化。

在进行分布式选型时，可重点考察下列几个方面：

1）分布式事务

分布式架构，自然会带来分布式事务的问题。由于需要跨节点的网络交互，因此较单机事务会有很多损耗。随之带来的是事务处理时间较长、事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。针对单笔事务来说，分布式事务执行效率是肯定会有降低的，分布式带来的更多是整体处理能力的提升。但在设计之初，就应尽量做到业务单元化，将事务控制为本地事务，这可大大提升执行效率。

2）性能

由于二阶段提交和各节点之间的网络交互会有性能影响，分布式数据库优势不是单个简单sql的性能，但是大数据量的sql查询，每个节点会将过滤之后的数据集进行反馈，会提升性能，并且分布式数据库的优势是并发，大量的sql并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。对于含有需要节点间数据流动的SQL语句的事务，OLTP类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。建议尽量改造存在跨节点数据流动的SQL语句（主要是多表关联）的事务。

3）数据备份

分布式数据库一致性保证通过内部时钟机制，所有节点都会遵循一致的时钟，所以备份恢复的增量也是基于时钟，相当于单机数据，但是分布式数据库的备份解决方案最重要标志是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐会大很多，还有就是是否支持一些分布式备份方案，比如S3协议接口，是否支持压缩等功能。分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候制定节点进行恢复到指定时间点，整个过程可配置自动任务自动执行。

4）高可用

分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署，如果同城主备可以采用集群级的异步复制。异地建议采用集群级的binlog异步复制。建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件T+1恢复到异地灾备。

5）数据一致性

NewSQL分布式数据库基本都是通过获取全局时钟时间戳，采用二阶段提交实现一致性，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。

6）其他因素

金融行业在数据库选型中，除了需要考虑上述四点外，还有其他一些因素的考虑。如原有系统的承载能力、是否必须进行选择等。

除了上述技术因素外，在选型中还需考虑系统运行现状，可重点参考下述指标：

1）系统数量

考量租户能力

2）数据量

考量系统承载力

3）系统性能指标

TPS、QPS、RT等

4）并发量

系统的最大并发数：为了节省成本，多套小系统可以共用一套数据库，但是负载很大的高并发场景还是独立搭建。     

5）业务中断时间

系统最大可容忍的业务中断时间：分布式数据库节点宕机并不是对业务没有任何影响，主节点宕机都涉及到一个切换的问题，切换就是影响业务的时间，要充分评估业务能否忍受这么长时间的中断。  

6）系统的迁移成本

分布式数据库不可能做到oracle、db2、mysql所有数据库的百分之百兼容，所以不同类型的数据库在迁移上都会或多或少的涉及到应用的改造。

除了对运行时的各种因素评估外，作为底层技术基础设施的更换，还需要考虑基础资源的使用。分布式数据库通常会采用廉价x86 pc服务器，搭配本地ssd固态盘、万兆网卡，单体硬件成本较低。但在服务器数量上，需要有更多考虑。一方面分布式数据库组件众多，且每个组件都需要高可用配置，即使部分可采用混部方式解决，但在整体数量上仍然会较多。

此外，还需要考虑各组件的负载模型不同、关键组件独立部署、数据多副本等等问题。另一方面，结合重点关注的性能数据、例如支持的QPS等，从而计算出服务器数量需求。需要注意的是，分布式数据库厂商提供的性能测试采用的服务器参数，一般是高配服务器，如果实际生产使用服务器配置降低，还则要考虑性能数据损耗等问题。

作为 一种新型的数据库产品，对运维方面也会带来不小的工作。至少包含了以下一些方面：

1）硬件评估

如上面“资源评估”所谈到的。

2）软件规划和部署方案

分布式数据库组件众多，而且每个组件都有高可用备份，所以在有限数量的服务器下进行组件的分配要尽量考虑达到各个服务器负载的均衡，GTM作为分布式数据库的瓶颈尽量和他们组件分开部署。

3）监控方案

监控一般可以采用开源的zabbix进行定制化开发，当然也可以基grafana+prometheus的方案做监控。但一般大中型金融企业都有一套自己的监控系统，这里需要有个对接适配的过程。此外，由于分布式的多组件特点，在监控指标数量及指标间关联上，与传统数据库差异巨大，是需要监控摸索过程。

4）语句调优

因为不同厂商研发的数据库SQL优化器及执行计划都有所不同，所以要根据不同产品进行学习。天然由于分布式架构带来的复杂度，也会影响到语句的执行效率。比较常见的如数据库访问链路长所带来的的问题、数据分布不均带来的问题及分布式优化器的问题等。

5）备份方案

分布式数据库如何做到多节点全局一致性备份也是难点，要做到真正意义上的基于时点恢复，就需要做到分布式环境下每个全局事务的可追溯操作。

6）应急方案

因为分布式数据库还处于发展阶段，还不成熟，技术比较复杂，所以生产环境下要制定详细的应急方案，让不了解分布式数据库的同事也能够在出现问题时按照手册操作。

7）DDL变更

在分布式架构下，DDL变更是个难点。如果做到全局一致，做到业务无感知，是核心点。不同厂商产品实现能力层次不齐，介于此安排在低峰期操作并做好必要的监控回退。

8）水平扩容

分布式架构下，都是支持水平扩容的。一般来说，非数据节点的扩容是相对容易的，对业务也是无感的，但涉及到数据节点的扩容，势必会遇到数据reshard的问题。建议选择在低峰期，同时控制好扩容粒度。即便如此，仍然建议提前做好容量规划，避免扩容。

9）跨片计算

分布式架构下，数据是分布在多个节点中。如果数据计算是可以在本地计算完成，无疑是效率最高的，但完全避免跨片计算是不太现实的。如果发生跨片计算，则不可避免地对上层节点带来压力，要做好相应监控，并争取在根本上避免跨片类计算。

分布式转型，势必会带来一定的成本。这里尝试将可能带来的成本做个分析：