分布式数据库在商业银行设计与实践相关的20个问题

前不久我们邀请行业专家分享了《分布式数据库 TiDB 在商业银行的设计与实践》（点击标题可阅读），并与会员共同探讨了在商业银行中，分布式数据库应用的相关问题，获得了广泛关注，以下是嘉宾wanglaye根据活动交流内容总结出的重点问题和典型问题，有助于大家对分布式数据库在商业银行的应用进一步了解，以及弄清相关疑问、难点。供大家参考。

背景

大数据时代，为应对海量数据的井喷式增长和用户需求的不断增加，分布式数据库应运而生。分布式数据库将位于不同地点的多个服务器通过网络互相连接，共同组成一个完整的、全局的大型数据库，它在逻辑上集中、物理上分布。在数据存储上，分布式数据库将数据打散存储在不同服务器上，故而将数据库压力分散到不同服务器上。分布式数据库具有以下显著特点：高可扩展性、高并发性、高可用性。

分布式数据库在互联网应用场景下已经积累了很多成熟的技术，但相比互联网企业，金融行业对分布式数据库的要求更高，除了上文提到的高可扩展性、高并发性、高可用性之外，分布式数据库还需要具备支持分布式事务、提供业务数据一致性、易于维护等特性，因此，金融行业需要更加完备的技术支持。

面对互联网业务的不断深化以及业务量的爆发式增长，传统数据库存储能力有限、响应时间长、服务器压力大、扩容成本高等问题逐渐凸显。面对交易复杂度及交易量的大幅提升，某行信息系统采用的传统数据库一体化解决方案，在应对此类场景时遇到了明显的性能瓶颈。该行计划搭建基于实时交易的分布式数据库平台，响应国家科技金融战略，开辟数据库创新的新路径；对IT系统而言，使用分布式数据库可以提高性能、缩减成本、保障数据安全与高可用；对运维人员而言，分布式数据库可以实现自动资源调度，提高运维效率。详情可见：分布式数据库 TiDB 在商业银行的设计与实践

本次交流活动针对分布式数据库在商业银行领域的设计与实践，基于上述实践分享，就分布式数据库的特点、应用场景、选型、性能、设计、实践等方面提出了20个问题，并做了较为深入的讨论和详细的解答。

一、分布式数据库的特点、应用场景相关问题

【Q1】分布式数据库适用场景有哪些？和传统的数据库有哪些不同？

@匿名用户：

分布式数据的使用场景，依赖于数据库产品本身的特点来说的。如果非要说一些它的场景的话，哪就是两个量大（数量量大，请求量大）共存的业务。

和传统数据库的区别有几点：

1.分布式。传统数据库基本上单机版。

2.能支撑更大量的数据，和请求量（或事务量）。

3.因数据的分片方式不同，要结合应用场景进行选择和应用适配。传统数据库不需要

@mornsky 某银行研发工程师：

互联网时代，数据量、并发量剧增，传统单节点数据库方式很难适应，这就是分布式数据库的用武之地。今后，不管是互联网企业还是金融业或传统企业，分布式数据库是趋势，或者传统数据库也将走向分布式升级改造。

@wanglaye 某商业银行 技术经理：

分布式数据库针对的是海量数据、高并发交易的应用场景。

传统事务型业务场景在选择数据库时，也要考虑分布式数据库是否支持分布式事务。

【Q2】TIDB 相对比一体机区别？

@tshqin PingCAP 数据库管理员：

具体是那种一体机呢？大机，AS/400，Teradata，Netezza，Exadata，HANA？TiDB 一般使用场景是数据量较大的 OLTP 系统，也可以混合轻量 OLAP 运算。

【Q3】分布式数据库有没有安装简易的简易学习版或者单机版，用于学习普及培训?

@gaolyang 某商业银行 技术经理：

建议到pingcap官网上看看，上面有很详细的学习文档，https://www.pingcap.com/docs-cn/。

@MrSylar 某金融公司 数据库管理员：

有木有建议学习版或者单机版，我不是很确认。但个人感觉，所有的数据库安装基本都不会是问题，无非是个熟悉的过程，你更多需要的是个成功的安装文档，so 多加几个相关的群，你会发现一大堆。

@冰玉 北京瑞尼尔 数据库开发工程师：

分布式是在多台服务器的基础上的，单机的可以是分布式的单个节点独立运行。他的难点就是多台机器协作作业，单机可以运行但是没有什么意义。可以简单点，在两个虚拟机上安装。

分布式并不是很高深，内部原理复杂，通常配置和使用并不是很麻烦。

@刘诚杰 平安城科 数据库管理员：

mongodb的sharding，可以使用mtools工具快速安装单机的学习版（测试版）。

【Q4】Db2 dpf数据库属于分布式数据库吗？有没有正在使用的，性能、可靠性如何？

@wanglaye 某商业银行 技术经理：

Db2是传统数据库，与分布式数据库还存在很大区别。

@tshqin PingCAP 数据库管理员：

shared nothing 的 MPP 在广义上也属于分布式架构，用于重型 OLAP 系统，如经营分析，财务报表，反欺诈，决策支持等系统。在 MPP 数据库中，一张表的数据分布在多个分区上，可靠性随分区数量增加线性下降，可以通过对分区进行多副本复制提高可用性。Join 性能是 MPP 的核心竞争力，因此被大规模用于 OLAP 系统中，而 OLAP 对于可用性要求不太高的特点也一定程度掩盖了 MPP 的缺点。

此种架构不作 OLTP 系统数据库使用。

@冯万里 IBM 数据库架构师：

确切说dpf是属于阉割了高可用功能的分布式数据库。因为dpf虽然有多个节点，每个节点又有多个分区，但是宕掉任何一个节点，数据库功能都无法正常使用，和平常大众所认知的分布式数据库还有一些差别。

【Q5】HBASE分布式数据库特点？

@yinxin 某集团公司 项目经理：

Hbase的优点：

1 列的可以动态增加，并且列为空就不存储数据,节省存储空间.

2 Hbase自动切分数据，使得数据存储自动具有水平scalability.

3 Hbase可以提供高并发读写操作的支持

Hbase的缺点：

1 不能支持条件查询，只支持按照Row key来查询.

2 暂时不能支持Master server的故障切换,当Master宕机后,整个存储系统就会挂掉.

其他：

1.数据类型，HBase只有简单的字符类型，所有的类型都是交由用户自己处理，它只保存字符串。而关系数据库有丰富的类型和存储方式；

2.数据操作：HBase只有很简单的插入、查询、删除、清空等操作，表和表之间是分离的，没有复杂的表和表之间的关系，而传统数据库通常有各式各样的函数和连接操作；

3.存储模式：HBase是基于列存储的，每个列族都由几个文件保存，不同的列族的文件时分离的。而传统的关系型数据库是基于表格结构和行模式保存的；

4.数据维护，HBase的更新操作不应该叫更新，它实际上是插入了新的数据，而传统数据库是替换修改；

5.可伸缩性，Hbase这类分布式数据库就是为了这个目的而开发出来的，所以它能够轻松增加或减少硬件的数量，并且对错误的兼容性比较高。而传统数据库通常需要增加中间层才能实现类似的功能。

【Q6】mycat主要的应用场景是什么呢？是不是主要和mysql进行结合？

@喂小饱me9 chinapay 数据库运维工程师：

mycat是基于mysql的，目前正好有测这个，我的主要目的是为了方便将SQL语句翻译成MONGODB语句，应用程序通过连接mycat去查询后端的MONGODB，mycat也可以作为一个库集成工具，对于用户来说，只要查询mycat，就可以查到mycat后端的多个库。

@TonyWang 系统工程师：

建议看官网介绍 http://www.mycat.io/

【Q7】MySQL分布式有什么成熟的方案（除了MyCAT）？

@TonyWang 系统工程师：

MyCat 是MySQL分布式的一种实现方式，以数据库代理方式

其他方式也可以考虑，下图是京东的

网址：http://shardingsphere.io/document/current/cn/overview/

二、分布式数据库的选型相关问题

【Q1】主流的分布式数据库有哪些？

@login 网络架构师：

市面上的分布式数据库有Tidb、巨杉、OB、TDSQL等。

@韩成亮 某金融 数据库架构师：

补充下GPDB 

https://greenplum.org/

MariaDB ColumnStore 

https://mariadb.com/products/technology/columnstore

【Q2】选择分布式数据库对于银行自身的意义？有哪些好处？

@wanglaye 某商业银行 技术经理：

随着国家对信息系统安全可控的要求不断提高，银行业对于自身的技术路线选择也应自主可控。近年来，商业银行纷纷加大对分布式数据库的投入，大部分银行仍处于探索阶段，少数银行将分布式数据库技术应用于非业务交易系统上。因此，我行计划搭建基于实时交易的分布式数据库平台，以开辟数据库创新的新路径。

此外，对IT系统而言，分布式数据库可提高性能、缩减成本、保障数据安全与高可用。对运维人员而言，分布式数据库可以进行一定程度的自动资源调度，提高运维效率。

@韩成亮 某金融 数据库架构师：

首先需要明确一件事情，银行也是需要分布式数据库的。

目前的数据库系统架构，理论上当然是没问题的，但是随着未来业务场景的变化，会造成诸如业务量的急速上升，同时周边产品的蝴蝶效应，还有一些互联网业务的发展，不可避免的会造成高并发，高数据量，高可用性的相关要求，自然而然，分布式数据库的需求就应用而生，当然，这两者是有一定的关联性，并不是一蹴而就的，对于其他行业而言，也是一样的道理。

对于银行而言，目前的架构容灾无可厚非，由于银行行业的特殊性，一般话而言会有多个灾备中心，在大部分的情况下，灾备中心的机器会存在一定程度的资源浪费，乃至可以说是空置，还需要经常的进行切换，保证灾备中心的可用性，还有就说机器的规模，基本上会要求1：1 ，无论是从硬件成本还是人力成本都是很大的开支。

从某种角度上而言，银行可能比其他任何行业都急需分布式数据库的需求。

分布式数据库的好处，简单点说就是 成本低，易维护，易扩展，可以有更多的成本投入到业务中去。

@tshqin PingCAP 数据库管理员：

传统架构中的核心数据库如大机，AS/400，Power + Oracle Rac/DB2 PureScale 都已经或将面临一个非常核心的挑战 - OLTP 系统数据量超过了架构所能承载的极限，离线部分如日终处理，季度结息等也耗时越来越久。

分布式数据库的计算+存储 scale-out 能力突破了现有架构的容量限制。

【Q3】当前金融环境下分布数据库选型？目前分布式数据库各式各样，要想选择一个靠谱的分布式数据库是特别的难。特别对于金融行业，对数据的一致性、可用性要求这么高。

@p14159 数据库管理员：

目前很多金融公司都开始使用多云的环境，对应的数据库也开始向着分布式发展，OLTP OLAP的界限不再明显。 市场上有很多类似的产品，商业的如阿里的DRDS、亚马逊的Aurora等，开源的如CockroachDB 、TiDB 、 巨杉、 RadonDB 等。

更多的选择，更多的学习成本，给技术人员带来了更多的挑战。

在分布式数据库的选择上，大家重点要考虑哪些因素？ 

个人认为有如下几点：

1 大厂/社区的支持

2 庞大的用户规模，丰富的生产使用案例

3 开发团队更重视用户的声音，能够及时调整设计思路。

4 对原生的SQL完全支持

5 完整的生态，如备份迁移工具，优化分析报告、监控与自动化管理等

@gaolyang 某商业银行 技术经理：

还有一点很重要，公司的技术支持态度及能力。

@wuwenpin 软件开发工程师：

自身的技术力量更重要。

@匿名用户：

我个人觉得从几个地方去看：

1.产品成熟度。数据库是个非常重要的系统，对系统的稳定性要求非常好，产品成熟度高代表着稳定性会好一些。

2.使用广泛。使用广泛也是为了稳定性，同时遇到问题，有响应的社群交流。

3.技术实力。公司是否具有很高的技术实力和知名度。

4.针对这些产品结合自己的金融场景来选择，其实上面的不是都适合金融的OLTP场景。

5.成本。这里包括购买成本，以及维护成本，这个需要自己去测试一下。

【Q4】选择分布式数据库所注重的数据库特性有哪些？

@匿名用户：

我个人觉得有几点需要关注：

1.是OLTP还是OLAP？

2.在具体的场景下性能如何？

3.数据分布的策略是什么？

4.增删节点是否比较容易？

5.后续在使用过程中如果遇到问题，它支持是否给力？

【Q5】贵行对于分布式数据库的技术评价项有哪些方面？

@wanglaye 某商业银行 技术经理：

主要有以下几个关键评价指标：

可靠性和高可用性，灵活扩展能力，分布式查询支持性，兼容性，基础运维友好性。

三、分布式数据库设计、实践、性能相关问题

【Q1】传统数据库如果要改造成分布式数据库，有哪些技术难点？

@韩成亮 某金融 数据库架构师：

个人觉得主要是思维模式的转变，毕竟分布式数据库就目前而言，在事务而言，采用的分布式事务，还有就是分布式数据库主要有调度节点，计算节点和存储节点构成，这个跟传统的其实是个很大的差别，对于问题的排查可能需要更加准确的认知，还有一些分布式数据库的特性，分布式数据库的使用习惯，跟传统的有很大差别，比方说一件扩容，弹性扩展，在线迁移，还有就是高可用等，其次是传统意义上的备份方式就不是很实用了。

至于传统数据库的改造，说到底就是业务的改变，简单点而言，无论是传统数据库还是分布式数据库说到底的本质上而言是存储数据，并进行相应的业务逻辑处理，存储数据库大体是一致的，对于业务的处理部分就会牵扯到事务了，乃至于性能响应了，这部分的难点不言而喻，事务的一致性跟性能的可用性就是一个取舍，当然也可以使用事务的最终一致性来解决，而这个也是常规的分布式数据库所推荐的方案。

@gaolyang 某商业银行 技术经理：

首先从业务系统角度来说，该系统所使用的数据库对象构成方面，最好只有简单的SQL语句，而无存储过程等传统数据库中的复杂对象，也就是数据迁移成本；

其次，对于所创建的分布式数据库集群，由于集群有一定的服务器规模，所以要平衡硬件成本问题；

最后我认为，业务系统的类型除了应满足高并发等OLTP数据库的特性之外，还有海量数据存储的需要。

【Q2】贵行做的分布式数据库的多活如何保证网络的延时？

@wanglaye 某商业银行 技术经理：

集群内部使用万兆网络通讯最佳，多数据中心之间使用裸光纤+波分设备是最佳选择，如果是异地，在条件允许的情况下，用光纤最佳，但要考虑高昂的成本。最好是从架构层面设计多活，从业务层面考虑异地网络的延时。

@chrislay  UBI 系统架构师：

多数据库中心，租用运营商的带宽，一般是波分设备，有的是拉裸纤，成本就高了，还有就是业务架构上的优化。

【Q3】单数据中心，多 TiKV 进程终止、TiKV 服务器宕机、TiDB 服务器宕机、PD 服务器宕机，集群是否仍然可以对外服务？

@匿名用户：

单数据中心下，出现一定程度（每个产品有一定的最大宕机数）宕机，集群是可以对外提供服务的。

如果是多IDC下，目前很多分布式数据库是做不到的，除非考虑IDC之间做专线。

@wanglaye 某商业银行 技术经理：

这个要考虑整个集群的架构设计。

TiKV 是一个集群，通过 Raft 协议保持数据一致性，并通过 PD 做负载均衡调度。单个TiKV节点失效时，会影响这个节点上存储的所有Region。对于 Region 中的Leader 结点，会中断服务，等待其他TiKV上的Region重新选举Leader，待Leader选出了可继续对外提供服务，这个过程非常短；对于Region 中的Follower节点，不会影响服务。

TiDB 是无状态的，通过前端的F5对外提供服务。当单个TiDB实例失效时，仅仅会影响正在这个实例上进行的会话，从应用的角度看，会出现单次请求失败的情况，应用重新连接至其他TiDB实例后即可继续获得服务。单个TiDB实例失效后，可以重启这个实例或者部署一个新的实例。

PD 是一个集群，通过 Raft 协议保持数据的一致性。单个实例失效时，如果不是leader，那么服务完全不受影响；如果是leader，那么PD集群会重新选出新的leader，自动恢复服务。

在实际测试和应用过程中，单数据中心，TiKV 服务不可用、TiKV 主机故障、TiDB 主机故障、PD 主机故障，数据库均能正常提供服务。

【Q4】集群中单台TiKV出现故障，如tikv进程终止、TiKV 主机万兆网卡断开、TiKV 主机服务器宕机，集群是否仍然可以对外服务？

@wanglaye 某商业银行 技术经理：

只要集群中剩余可用副本数仍占大多数，集群就可以对外服务。

TiKV 进程终止，集群对外服务正常TiKV。进程恢复后，数据同步正常，该TiKV 恢复正常状态。

单台 TiKV 网络故障，数据库正常提供服务。 网络恢复后，数据同步正常，该 TiKV 恢复正常状态。

单台 TiKV 主机故障，数据库正常提供服务。 主机恢复后，数据同步正常，该 TiKV 恢复正常状态。

@tshqin PingCAP 数据库管理员：

在部署集群的时候可以为集群中的 tikv 添加 label 信息，PD 会根据 label 信息进行副本调度，根据所配置的 label 级别的不同，可以避免将同一个 region 的两个 replica 调度到：

同一台服务器的两个 tikv 实例上

同一个机架的几个 tikv 实例上

同一个机房的几个 tikv 实例上

据此可以实现服务器级/机架级/机房级的容灾，因为集群中还存活大多数的副本就有能力对外提供服务。

详情参考官方手册：https://www.pingcap.com/docs/op-guide/location-awareness/

【Q5】OLTP型分布式数据库跨节点事务性能问题？金融银行传统业务采用分布式数据库的话，业务场景复杂，例如对账户表的拆分，转账交易的话可能会导致大量的分布式事务，影响整体数据库性能，或者无法发挥分布式数据库的优势，针对这个问题，有没有比较理想的解决方案？

@刘诚杰 平安城科 数据库管理员：

CAP就占有技术本身就无法兼得，在银行场景只能牺牲速度，保证事务执行。除了核心的资金场景，少用事务可以更合理使用分布式数据库。

@韩成亮 某金融数据库架构师：

针对这个问题，首先我们需要了解事务的一致性，分布式数据库不可避免的或多或少存在这样的问题，简单点而言，我们有些时候并不需要保证单个事务的一致性，我们可能通过最终一致性来解决，而这个也是分布式数据库设计的一个因素，因为往往有些时候可用性和一致性很难平衡，这就有了保证最终一致性的各种措施比如消息队列，全局事务表，二阶段提交，三阶段提交等。

【Q6】分布式数据库在运维过程中的坑有哪些？

@阳嗨超 某平台架构部高级技术经理 IT顾问：

所谓的坑是需要看具体的某一个产品的。

分布式数据库运维中，整体来说有几个地方的挑战：1. 是运维的复杂度会提升不少。譬如：异常故障的处理等。 2.备份和恢复会复杂一些。这些的恢复是指产生逻辑错误导致的问题恢复。

@韩成亮 某金融 数据库架构师：

对于任何一个分布式数据库而言，坑不坑的我觉得并没有什么太大的意义，作为一个软件的存在本身就会存在这些那些bug，只能说，生产无小事，发现问题，解决问题。

其实说到底就是需要我们对自己所运维的数据库有一个充分的了解，在实际运维中学习，多用多了解。

【Q7】分布式数据库有哪些灾备或备份方式?如何更好地解决分布式节点中个别节点出故障问题?

@wanglaye 某商业银行 技术经理：

首先要确定分布式数据库的部署方式，单中心、多中心等不同架构对应的备份方式也不一样。

确定部署方式后，根据raft原理，只要集群可用节点占集群的大多数，集群都可用。

【Q8】贵行是将TIDB用在哪个业务系统？

@wanglaye 某商业银行 技术经理：

目前我们已将某实时交易系统迁移到TiDB数据库，运行状况良好，需要重点关注TPS、响应时间、连接数等关键指标。

在数据库选型时，我们考虑了高可用性、弹性扩展能力、数据迁移能力、基础运维能力、分布式查询能力，TiDB最终成为我们选用的产品。

本文由活动嘉宾wanglaye总结整理。（wanglaye，某商业银行技术经理，致力于金融科技基础架构研究及项目管理，重点负责大数据、分布式数据库及相关方案的架构设计和技术支持。）

本文内容由来自金融领域的gaolyang、韩成亮、mornsky、p14159、喂小饱me9等专家高手，以及专注数据库技术的chrislay、刘诚杰、wuwenpin、冯万里、tshqin、MrSylar、yinxin、冰玉、TonyWang、login等分享。

 推荐资料：

分布式数据库TiDB在商业银行的设计与实践

http://www.talkwithtrend.com/Document/detail/tid/419235

TiDB集群安装

http://www.talkwithtrend.com/Document/detail/tid/419205

postgresql分布式数据库架构

http://www.talkwithtrend.com/Document/detail/tid/418759

Greenplum数据库最佳实践

http://www.talkwithtrend.com/Document/detail/tid/418755

长按二维码关注公众号