dto 是只给前端需要的数据吗_银行需要分布式数据库吗？

金融数士

关注大数据、分布式等技术领域的最新发展，分享金融业技术实践，普及数据技术知识。

以下文章来源于金融数士 ，作者Ivan

技术优秀的你，未来一两年很可能会被老板问到这个问题 “我们要不要上分布式数据库”，你有答案了吗？Ivan试着来帮你分析一下。

我们都知道数据库是IT系统的基石，高性能高可靠的服务是它默认的前提。银行目前的数据库方案被多年实践过的方案，理论上当然是没问题的，但是未来会怎样呢？

高性能

业务场景的变化带来业务量的激增导致高性能的需求提升。

一个场景是小额支付的流行。以前，你去超市买个十几块钱的东西要刷卡，收银员十有八九会送个白眼给你，Ivan这样心理素质差的还是乖乖用现金结账。现在，大街小巷的商户摊贩都支持扫码支付了，几块钱买包瓜子刷微信也是很爽的，没人跟你叽歪。

这样，小额支付场景由原来的现金变成了扫码支付，最终体现在银行的交易量增长。大家对比刷卡的频率和刷微信的频率，大致也能明白交易量的增长情况吧。

其次是理财业务，按照目前的监管政策银行理财是5万元起购，余额宝是1元起购。近年来一直有降低起购门槛的呼声，未来银行理财门槛的下降是大概率事件，银行天然有维持理财产品业绩的意愿，这就肯定会推高交易量。

这两类场景本质上都是银行业务互联网化带来的冲击，无论是推出互联网同质化业务还是与互联网企业合作，都导致银行的交易模式与频率会更加接近微信、支付宝。

当然你可能说我们是小银行，交易量小，或者我们主要做对公业务搞定几个大客户就行，那确实这个问题就那么突出。但是，性能压力对于股份制以上的银行还是会存在的，分布式数据库是可选的方案。

高可靠

银行的高可靠方案很多都是采用SRDF，它的主要问题是成本。

SRDF方案，数据库采用主备模式，在高端共享存储上保存数据库文件和日志，使数据库近似于无状态化。主库一旦出现问题，备库启动并加载共享存储的文件，继续提供服务。

这套方案能够做到RPO为零，RTO也比较小。但存在三个问题，一是对高端存储的依赖，导致硬件成本比较高；二是备库在日常都是处于空闲状态，而且造成资源闲置，要知道主备机房通常都是1：1的比例容灾，意味着一半的设备闲置；三是因为备库不是active的，所以需要通过定期演练，确保其可用，增大了使用成本。

这三个问题具有普遍性，基本上所有银行都会面对(监管要求，商业银行取得金融许可证大致四年后都要建立灾备中心)，分布式数据库是可以解决或部分解决的。

有的同学可能会说，不一定要用分布式数据库呀，这些问题我们现在已经解决了。下面，让我们来梳理一下通常会有哪些解决方案，有什么利弊。

可替代解决方案

垂直扩展

这是个最偷懒也最可靠的方法。增加更多的内存、CPU，升级配置更高的机器，自然获得更好的性能。但是，今天主机已经谢幕，小型机处理能力的上限短期就会触碰到(对于股份制银行以上规模)。何况现在X86的呼声高涨，小型机也注定是明日黄花，所以硬件不能完全解决问题。

读写分离

这个方案也很成熟，但并不是对所有应用都有效。读写分离通常都是异步数据同步，存在一定的时延，如果你的查询业务能够容忍这个时延，确实是很好的办法。但如果要求主从库强一致性，试图通过强同步方式实现，就会有很大的问题(在副本同步专题再展开讨论)，再者写性能并没有得到提升，很多问题依然没有得到解决。

微服务

对数据库而言多数就是垂直分库分表，如果没有分布式事务的干扰，分库是个好办法，付出代价就是微服务本身的改造成本。但微服务不代表没有热点服务，仍然可能造成性能压力。其次，如果不是业务本身，仅为了分摊压力而拆库，会将很多事务的东西暴露到应用层，会加大应用的复杂度。

如果上述方式都不能解决问题，我们还有最后两招，水平分库分表和分布式数据库。事实上，争吵最多的也是这类两方案的拥护者。

水平分库分表

也就是Sharding+Proxy。直接拆数据库对应用影响太大，大家都感觉疼，所有加个Proxy让应用感知不到，这个想法很棒。所以Proxy的方案还是蛮多的而且历史悠久，比较代表性的有 Sharding-JDBC/TDDL/Atlas/MyCat。

这类方案面临的问题1、跨分片的SQL怎么处理2、唯一键、外键等全局约束怎么处理3、全局ID如何生成4、分片通常是基于业务键Hash，要求数据存在一个稳定的业务键恰好能解决访问热点，业务是否支持。5、是否支持分布式事务

这类方案也在不断的演化来解决上述问题，直到DRDS及类似方案的出现，已经转化为Proxy流派的分布式数据库。

分布式数据库

可以分为三类，一是Aurora为代表，以log is database为理念，但不适用于多数的银行场景；二是Proxy流派，就是Proxy的延续，内核还是关系型数据库(多采用MySQL)，增加了SQL解析适配、节点调度、全局事务控制等内容。三是NewSQL流派，通常是存储引擎与计算引擎分离，访问接口兼容传统关系数据库SQL，存储采用KV存储和LSM模型，主副本采用Paxos/Raft协议同步，支持分布式事务，完全的ShareNothing架构。目前基本主流的方案是在后两者中选择。
不妨对别一下，你的方案是否解决了全部问题。

记得看过一个很贴切的比喻，IT系统就像时装，既要有实用性，还要符合时尚潮流。我们用来讨论分布式数据库也很合适，上面说了主要是实用性，还要讲讲时尚潮流。

时尚潮流

鼓励创新和扶持民族产业是过去五年的主基调，相信在未来很长一段时间也不会变化，这应该就当今中国是最大的时尚潮流。

银行业处由于业务稳定的要求，在技术选择上偏向保守，重视案例，所以头部企业有很强的示范效应。我们谈到的很多问题，可能真正有迫切要求的是大中型银行，但这种示范效应很可能会带动其他银行的技术转型。

我们再来看看业内的实践，南京银行、浙商银行引入了OceanBase，中信银行与中兴通讯合作自研GoldenDB ，三家银行都已经在生产环境投产。宇宙行也提出了分布式数据库的研究计划。开源数据库方面，对标Google Spanner的TiDB/CockroachDB得到广泛关注。这是不是代表示范效应开始累积？

最后，Ivan做一个大胆的预测，未来一两年内头部示范效应就会充分显现，随后的两三年很可能会出现一次分布式数据库为代表的基础架构升级，涉及四大行、多数股份制银行和少数城商行。

相信到看这里，你已经有了自己的答案。无论是否选择，优秀的你怎么能不了解分布式数据库呢，别让技术的贫穷限制了我们的想象力。