1、银行核心场景是否适合上分布式数据库？如果要上需要达到什么客观条件才可以？

【问题描述】银行目前大部分使用的都是集中式数据库（Oracle、DB2等等），如果有想法平滑过度到分布式数据库，银行内部需要做哪些准备工作？银行核心场景是否适合上分布式数据库？如果要上需要达到什么客观条件才可以？否则盲目上就是一个坑。

@顾黄亮  苏宁消费金融有限公司 技术总监： 

毋庸置疑，银行的核心系统是可以上分布式数据库的，无论是交易核心还是账务核心。

银行在数据库选型，需要考虑四点，分布式事务、性能、数据备份、高可用。在过程中需要根据不同的场景进行应用的改造和数据库架构的设计，举个简单的例子，账务核心进行跑批，亿级的海量读取的需求，需要采取分布式数据库模式，另外还有分布式访问客户端和分布式中间件模式可以选择。

以笔者的经验，客观条件取决于四点，1、科技是否有足够的能力进行系统的迁移；2、运维是否有能力进行分布式数据库的维护；3、业务是否能够接受数据库换型期间的业务中断时间；4、是否有相对明确的数据量和并发数的指标。

@luxh08 某互联网银行 科技部门副总：

根据我行的经验，就是通过数据库的技术标准化和轻量化工作，形成统一的数据库使用规范，解耦应用和底层数据库技术架构，在统一的Mysql数据库协议下，可以很轻松的更换数据库架构，通过Mysql和分布式数据库的互相同步机制，可以实现业务的无感切换和迁移回退。

银行核心系统场景是典型的OLTP，有大量的针对数据库的记账类更新操作，单个update或者insert操作的性能，单机库是分布式库的几倍以上，在热点账户场景对分布式数据库带来了严重的性能问题，造成了记账超时带来的客户短款问题，核心系统考虑分布式数据库的条件是，需要做大量的应用改造来弥补数据库的问题，比如热点账户场景子余额改造，比如联机场景改造为批量场景，之后需要经过严格的测试，比如生产流量复制测试，引入混淆测试平台。

2、银行的核心系统数据是强一致性，那么分布式数据库的数据强一致性如何保证？安全性如何保证？

@luxh08 某互联网银行 科技部门副总：

Newsql分布式数据库基本都是通过获取全局时钟时间戳，采用二阶段提交实现一致性，可以实现一致性的保证，分库分表架构对于事务的一致性，需要应用层考虑，比如通过合理的分区键设计来规避。

@金融行业 技术经理：

分布式数据库对于跨节点事务目前还是实现的最终一致，对于全局一致性读，一般通过引入类似全局时间戳的组件统一管理全局事务，在数据库选型时可以重点关注厂商对这一块的实现。如果目前暂时无法提供全局一致性读的分布式数据库，对于要依赖分布式事务“中间状态”的业务，优先进行业务改造进行规避，其次通过合理的数据分片设计让其在单节点内完成。

3、现有分布式数据库是否能承载核心下移数据的交易量？

【问题描述】对于分布式系统改造，如对传统金融的如400核心的数据库进行分布式数据库改造，分布式数据库是否能承载核心下移的交易量、稳定性及性能要求？

@金融行业 技术经理：

目前银行传统核心中小行和大行都有成功改造的案例，全国性大行像中信银行的新核心，平安银行信用卡新核心都是分布式数据库的，所以通过相应的适配改造，主流分布式数据库能够满足银行OLTP类的业务的交易量、稳定性和性能要求。

4、传统关系型数据库、中间件+数据库、原生分布式数据库使用原则？

【问题描述】1、随着newsql数据库发展，数据库可以说是百花齐放，对于银行业应用系统来说，传统关系型数据库、中间件+关系型数据库、原生分布式数据库使用原则从几个维度考虑？2、对于某些OLAP应用来说，基于中间件+关系型数据库、原生分布式数据库、或者nosql数据库（hadoop、mpp）都可以实现时，是从几个维度考虑使用什么数据库的？

@fanyqing 厦门银行 系统架构师：

问题1：

传统关系型数据库，如Oracle、MySQL、DB2等，支持SQL操作，具备ACID属性，通常用于处理业务数据较小的OLTP。随着业务数据的增长，传统关系型数据库已慢慢无法满足业务需求，于是，应用系统开始考虑分库分表的方式，即将一个业务系统的数据按照一定的规则，分布到多个数据库上，这样每个数据库需要处理的数据可以更少，以此满足业务系统不断增加的数据处理需求。中间件+分布式数据库模式就是属于此种情形。其中中间件主要用于数据的分片与分布式事务的处理，对应用来说是透明的。因此，中间件+分布式数据库主要用于数据量大的OLTP业务。而原生分布式数据库需重构数据库系统，原生支持分布式事务处理与数据切分，原生分布式数据库根据其数据处理引擎，有些适用于OLTP场景，有些适用于OLAP场景，还有些适用于离线分析场景。因此，我们在选择数据库时，首先要考虑是应用于哪类业务场景，其次要考虑该业务所要处理的数据量、数据增长的速度，业务的并发量等。如果选择的是中间件+关系型数据库，在数据库设计时，需要特别注意分区键和分区策略的选择，合理布局数据，尽量避免跨节点的分布式事务处理，以提高数据库的效率。

问题2：

对于OLAP应用，虽然各类数据库都可以实现业务数据的处理需求，但实现的成本和实现的效果大不不同。比如，关系型数据库（包括中间件+关系型数据库），大都采用行存，适用于OLTP场景，如果用于OLAP，虽然可实现业务能力，但效率较差。即使是原生分布式数据库，因重构数据库系统，也要根据数据处理引擎，选择合适的原生分布式数据库来处理OLAP业务。至于NoSQL，因SQL支持能力有限，如果要用于OLAP，会增加应用的开发难度。故在实际应用时，需要根据业务场景，以及自身发技术储备，选择合适的数据库。

5、如何评估银行分布式数据库项目的整体成本？相比Oracle性价比怎么样？

@顾黄亮  苏宁消费金融有限公司 技术总监： 

成本可以分为开发测试成本、数据库的软硬件成本、运营维护成本等。开发测试成本主要是开发该项目的人力成本，这个因项目而异。分布式数据库的硬件成本主要包括PC服务器加本地SSD盘，软件成本因厂商而异。有其他文章进行过比对，引用如下：

@luxh08 某互联网银行 科技部门副总：

根据具体的情况不一样，成本表现也不同，根据我行的经验，硬件成本>运维成本>应用改造成本，我们在数据库规范这块做的比较彻底，很早就执行了统一的标准，不容许采用存储过程，事务大小限制，统一mysql数据库协议等措施，所以应用基本上在mysql数据库和分布式数据库之前迁移应用改造成本很低。

运维成本由于之前数据库方向就是确定mysql，运维人员的技术储备都是满足分布式数据库的要求，mysql和分布式数据库的转换成本很小。

我们采用分布式数据库，最大的成本就是硬件成本，由于分布式数据库对服务器处理器和IO要求较高，并且由于我们采用的分布式数据库的产品对租户隔离性做的不好，造成重要应用都是单个集群，单个集群最小的服务器数量是6台，所以我们分布式数据库的PC服务器投入量很大。

由于我们采用的分布式数据库是开源运营方式，如果不考虑厂商的服务可以不用采购，我们针对重要系统购买了一部分license许可，外围系统都是自主运维，所以在成本上相比oracle要便宜很多。

6、处理返回数据集很大的并发场景适合用哪种分布式数据库？

【问题描述】哪种分布式数据库适合处理返回的数据集很大(几兆几十兆)的并发场景？有一批实时的时间序列数据，需要按时间来查询，并做聚合及复杂处理(不止是sum、avg、max这种)，目前来看分布式数据库是elasticsearch跟redis这两种都不太适合使用。

@luxh08 某互联网银行 科技部门副总：

Elasticsearch是做非关系数据的搜索引擎场景使用的，比如日志查询场景，redis是主要是做零时文件查询cache使用，大数据查询场景，特别是做join，sum等操作，建议使用hive架构、hatp架构还有就是后起之秀ClickHouse数据库在不少大的互联网公司作为实时大数据分析使用，性能非常强，大数据的聚合查询，大数量的复查查询类场景，我理解性能提升关键有下面几点，一是列式存储是提高性能的关键点，二是还有就是分布式节点架构，所有节点都能参与进来，三是节点本身能过滤计算数据集合，减少数据在网络上的传输量，四是可以使用底层的存储级索引，可以在物理存储过滤掉一些成本。

@顾黄亮  苏宁消费金融有限公司 技术总监：

提供一个思路，返回数据集很大一般在几个场景中遇到，1、jdbc对数据库进行读取不够合理；2、数据分析场景下需要对千万级数据进行快速计算和响应；3、调用存储过程返回庞大的结果集。

在这种情况下，有一些是通过数据库解决，还有一些通过应用的优化进行解决，比如分页或减少结果集传输次数，如果从数据库层面进行选型，很多分布式数据库都适合，关键看是否匹配场景，匹配能力是否覆盖，1、是否具备多维度关联预先计算出结果的能力；2、是否具备高并发场景的能力，其中涉及锁的机制；3、是否具备应对维度过大和枚举值多的能力。

@wanglaye 某大型金融机构 项目经理：

提供一个思路。influxDB配合kafka和程序， 复杂处理建议放在程序里做，让数据库专注处理时序数据。

7、分布式数据库是否有较完善的备份恢复解决方案？

@luxh08 某互联网银行 科技部门副总：

分布式数据库一致性保证通过内部时钟机制，所有节点都会遵循一致的时钟，所以备份恢复的增量也是基于时钟，相当于单机数据，但是分布式数据库的备份解决方案最重要标志是否支持物理级的备份，物理级的备份会比逻辑的备份性能吞吐会大很多，还有就是是否支持一些分布式备份方案，比如S3协议接口，是否支持压缩等功能。

@annoymous：

分布式数据库基本都具备备份和恢复方案，通常从备节点进行连续备份（全量+日志），恢复的时候制定节点进行恢复到指定时间点，整个过程可配置自动任务自动执行。

8、对于同城双活数据中心与异地灾备数据中心，如何设计分布式数据库部署方案？

@luxh08 某互联网银行 科技部门副总：

分布式数据库大多都是基于多数派协议，同城双中心不适合多数派的要求，同城数据级多活建议采用三中心部署，如果同城主备可以采用集群级的异步复制。异地建议采用集群级的binlog异步复制。

@金融行业 技术经理：

建议实例的主备节点设置在同城两个双活数据中心，仲裁节点三机房部署；异地灾备单独启实例与本地实例进行数据库间同步，也可以将本地备份文件T+1恢复到异地灾备。

9、分布式数据库对于复杂数据库事务的性能问题？

【问题描述】对于复杂数据库事务，分布式数据库可能出现需要多个数据库节点同时处理的情况，是否会因为各数据库节点之间多次数据同步或者交互，造成事务处理时间较长？

@luxh08 某互联网银行 科技部门副总：

对，由于二阶段提交和各节点之间的网络交互会有性能影响，分布式数据库优势不是单个简单sql的性能，但是大数据量的sql查询，每个节点会将过滤之后的数据集进行反馈，会提升性能，并且分布式数据库的优势是并发，大量的sql并发也会比单机数据库强大，应用需要做分布式架构的适配，将串行执行机制尽量都改造成并发处理。

@金融行业 技术经理：

对于含有需要节点间数据流动的SQL语句的事务，OLTP类的分布式数据库处理效率一般较差，事务处理时间会较长，事务期间的锁持有时间也会增加，数据库的并发性和扩展性也会很差。建议尽量改造存在跨节点数据流动的SQL语句（主要是多表关联）的事务。

10、在分布式数据库项目中，为进行系统规格设计，如何进行定量需求分析？需要收集哪些需求数据信息？

@顾黄亮  苏宁消费金融有限公司 技术总监：

一般情况下， 在分布式数据库项目中，为进行系统规格设计需要考虑下列方面的准备。

1、如何进行服务器选型：一般分布式数据库都会采用廉价x86 pc服务器，搭配本地ssd固态盘、万兆网卡，硬件成本较低。

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

3、监控方案：监控一般可以采用开源的zabbix进行定制化开发，当然也可以基grafana+prometheus的方案做监控。

4、如何进行调优：因为不同厂商研发的数据库sql优化器及执行计划都有所不同，所以要根据不同产品进行学习。

5、备份方案：分布式数据库如何做一致性备份也是研发难点，要做到真正意义上的pitr就需要做到分布式环境下每个全局事务的“barrier”操作。

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

此外还需要一些数据的收集，如下：

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

2、系统的最大数据量：多租户系统下需要考虑各个系统的数据量之和。

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

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

@wanglaye 某大型金融机构 项目经理：

题主说的“系统规格设计”，具体包括哪些内容可以详细描述一下。

我从分布式数据库规模角度分享一下经验。

业务系统层面，要调研系统数量、各系统业务量（包括总交易量、各种交易TPS等）、每种交易对数据库的sql条数（尤其关注读写频率，查询也要统计），从而大致计算出QPS。

分布式数据库层面，重点关注性能测试数据、服务器配置参数，一般主流3副本，对应3台服务器，以此作为组合，关注可以支持多少QPS，从而计算出服务器数量需求。需要注意的是，分布式数据库厂商提供的性能测试采用的服务器参数，一般是高配服务器，如果实际生产使用服务器配置降低，则要考虑性能数据损耗。

@luxh08 某互联网银行 科技部门副总：

不是所有系统都适合分布式架构，技术为业务服务，主要考虑成本和收益的平衡，分布式数据库的使用场景，应该是海量数据、海量用户、海量交易数，单机数据库可以处理的场景不建议采用分布式数据库，分布式数据库的使用会有成本的，比如应用适配成本、运维成本、硬件成本，能用单机数据库支撑的业务场景就尽量用单机库，但是还要考虑业务的发展，最好是能判断3年的数据量和交易量。

11、相较于银行核心系统传统架构，分布式架构的系统运维有哪些不同点？

@luxh08 某互联网银行 科技部门副总：

这个分布式架构我理解是数据库分布式架构，目前大部分核心场景上线分布式数据库都是采用分库分表架构，在运维过程中要关注以下几个方面，一是DDL类操作对数据库可用性的影响，二是后期节点扩容的复杂性，三是夸节点负责聚合类查询对性能的影响，四是多节点备份恢复的一致性，总结就是需要解决多节点全局一致性带来的复杂性挑战。

*本公众号所发布内容仅代表作者观点，不代表社区立场