银行上分布式数据库需要避免哪些坑？

■ 来自社区交流，供大家参考

银行分布式数据库建设路径探讨？

现在我们行领导听到非常多人来沟通说分布式数据库如何好如何有价值，那银行在分布式数据库的核心诉求是什么？为什么一定要上分布式数据库？有没有其他的技术路线可以满足需求？如果上分布式数据库，需要避免哪些坑？希望能听听同行经验和看法，让我们也能知道同行大家是如何想的！（问题来自@pobird  系统架构师）

@wanglaye 金融机构  技术经理：

银行传统数据库在应对互联网金融场景时遇到了明显瓶颈，在面临交易复杂度和交易频率的大幅提升时，传统数据库能够采取的优化方案非常有限，若仅依靠软硬件升级来提升性能的话，成本非常昂贵。另外，在应对双十一这类特殊交易日时，需要在短期内提升数据库的能力，传统数据库缺乏这方面的灵活性。若仅仅为了应对有限特殊日的流量，而配置很高的性能，又会造成资源的极大浪费。基于能力、可控、弹性、成本等方面的考虑，引入具有高可用、高性能、高可扩展性的分布式数据库成为优先选择方案。

分布式数据库设计阶段需要考虑很多方面，比较重要的像是高可用方案、存储方案、灾备方案、安全、监控、运维等，这些在前期都要规划好。还有一点很重要，分布式数据库最终是为应用服务的，要充分考虑应用从传统数据库迁移至分布式数据库的难度，尤其在测试阶段，要充分考量分布式数据库的兼容性。

在分布式数据库选型时，最好结合具体的应用场景，如OLTP和OLAP。另外，数据库厂商的技术服务支持能力和案例成熟度也要充分考虑。

以上是本人的一些小经验，供大家讨论。

@匿名：

关于诉求和为什么一定要上分布式数据库，不想多说，因为这些问题是仁者见仁智者见智的问题，近期我们做了一些分布式数据库的验证测试工作，其中还是碰到很多问题的，通过测试，发现分布式基础问题21个，分布式和Oracle兼容性问题28个，分布式和应用兼容性问题2个，分布式性能问题8个，以上问题都的到了厂商的确认，并进行了底层的修复。发现以上问题，都是通过大量的业务测试、场景测试和压力测试发现的，并进行了分析提交BUG修复。因此所谓的坑不是能避免的，而是要通过大量的测试去发现BUG，解决BUG，才能避免上了生产后踩坑。

目前我们通过认真讨论，也制定了大量异常场景进行破坏性测试，例如硬件问题场景、网络问题场景、业务问题场景（异常SQL）及极端场景进行了测试，通过以上大量的测试，技术人员自行编制了健康检查和健康巡检方案、慢查询SQL优化指南、分布式数据库异常问题解决案例手册、各异常场景测试报告及处理方案及总体测试报告等文档。

所以我们认为一个好的数据库是用时间、应用场景磨合出来的，只是我们在走之前Oracle、Db2已经走过的磨合道路罢了。

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

一、分布式数据库能解决什么问题？

首先，分布式数据库主要用于解决单机存储上限的问题。如今每天产生各类的数据量非常巨大，如果使用传统方案，要么不便于管理，要么成本过大。

其次分布式数据库可以一定程度分散单节点数据库压力，如读写分离、多节点并行运算等。

最后，某些分布式数据库有多数据中心方案，可以以较低的成本实现数据库层面的多活方案

二、银行在分布式数据库有什么核心诉求？

主要还是看用在什么业务场景,不同的分布式数据库有不通的优缺点和适用场景,这里只讨论厂商原生的分布式数据库。比如有的需要强事务可以考虑tidb，大量的写可以考虑hbase/cassandra，结构常变快速迭代可以考虑mongodb，搜索为主可以考虑es/solr，大量数据缓存可以考虑redis(cluster)等

三、为什么一定要上分布式数据库？

大多数情况是因为单机无法满足存储或性能要求，参考第一问

四、有没有其他的技术路线可以满足需求

公司研发团队自行编写中间件，可以满足需求，只是对研发能力要求较高，需要考虑到各类所需的场景。目前有不少大型互联网公司有采用此方案。

五、如果上分布式数据库，需要避免哪些坑？

1、出于稳定性考虑，最好用官方原始的分布式方案，谨慎选择使用第三方中间件。

2、因为分布式技术要求较高，建议有专人或者供应商进行维护。

3、使用主流的且经过时间考验的分布式方案，某些厂商为了分布式而分布式反而有不少问题。

4、对研发进行相关使用培训，否则性能损耗明显。

5、分布式架构时，某些特性会不支持，需要提前调研。

6、分布式场景下一致性的备份是个难点，不同数据库有不同解决方案。

7、重要数据各分片节点至少有2份或以上冗余，避免数据丢失

@孔再华  中国民生银行 数据库运维工程师：

现在所有的大行都在实践分布式数据库。

分布式主要解决两个问题。一是性能扩展，弹性伸缩。单机数据库的处理能力是有上限的，尤其是纵向扩展有极限，也不能解决单库的瓶颈。分布式数据库的横向扩展几乎是唯一的解决途径。二是高可用性，单节点的异常不会导致整个集群的损坏，不会影响全局。异常节点的数据和任务能动态漂移，恢复时间短。

然而分布式数据库也存在很多挑战，并不是那么容易实现。分库分表对应用是否透明? 如果从应用角度就开始分，合理开发应用，对于性能来说是最好的方式，但是需要很高的设计开发成本。 如果对应用透明，完全由数据库来做，那么性能可能会成为问题，因为应用会存在跨库事务，存在两阶段提交等。 分布式事务是否支持? 我们会看到接触的大多数分布式产品都支持，然而性能呢，都是问题。在测试的很多分布式数据库，都存在gtm这样的设计，用来协调数据库节点的事务。测试过程中，性能的瓶颈也基本出在这个核心功能上。

因此在上分布式数据库的时候，一定要关注这些点。挑选合适自己的数据库。从性能，高可用，管理性等方面全面评审才行。

@508mars 华泰证券 数据库管理员：

核心诉求我觉得有以下几个：

1）一些数据库越来越大，访问量越来越高，单机已经无法承载，或者纵向扩容的成本太高，这时候就需要通过支持横向扩展、支持廉价x86服务器的分布式数据库技术来解决。

2）现在很多行都开始微服务以及数据中台的建设，如果采用传统数据库技术，数据库实例的数目将会非常恐怖，DBA的运维工作将会受到极大挑战，解决这个问题我们就需要一个既能很方便的弹性伸缩，又能资源隔离（多租户）的数据库来存储数据，很多分布式数据库都提供了这样的能力。

市面上的分布式数据库技术分为两个流派：

1）采用中间件的分库分表方案，比如使用mycat

2）原生分布式数据库，比如国产的有tidb、oceanbase、巨杉数据库等等

分库分表方案在市面上使用很多，尤其在互联网。这种方案的优势是底层采用成熟的传统数据库，所以数据库层面比较稳定，缺点是对应用的侵入性比较强、限制比较多，同时运维非常不方便。

而原生分布式数据库对应用非常友好，在应用看来就是一个单库，无需关心分布式事务、数据存储在哪个节点等一系列问题，同时运维也非常方便，一个DBA可以轻松管理100多台机器构成的集群。因此它的诞生其中一个目标就是替代分库分表方案，而且全球技术评级机构像Gartner、Forrester都从来不会把分库分表方案放到他们的评估列表中。原生分布式数据库同时还提供了良好的弹性伸缩容能力、高可用甚至容灾能力，这也是业界对其比较看好的重要原因。当然目前原生分布式数据库的缺点也很明显：

1）太年轻，与传统数据库相比无论从稳定性（主要指性能，发生bug的概率）和功能性上来说都有一定差距

2）对存储过程、外键、触发器等特性基本不支持

需要避免的坑，我想到的主要有：

1）如果应用大量使用Oracle PL/SQL存储过程，迁移会很痛苦，个人不太建议拿这些系统做试点

2）分布式数据库一般都采用两阶段提交，因此效率上会不如单机数据库事务，为了提升两阶段提交的性能，有些数据库会采用乐观锁，乐观锁会出现一些跟悲观锁不一样的行为，因此应用逻辑可能需要调整来适应

3）在分布式数据库上跑中间结果集很大但最终结果集很小的查询效率可能不太好，主要是跨节点传输大量数据导致耗时较长，而传统数据库顶多就是从磁盘到内存这个过程，没有网络IO

4）分布式数据库和传统数据库之间如何做容灾的问题，比如分布式数据库作为主库上线运行了，但是我们担心它会出问题，想利用传统数据库做备库，两者之前的数据同步如何进行，这目前也是我们想要解决的事情

@杨建旭  中国人民银行清算总中心 技术经理：

为什么一定要上分布式数据库？

--业务量大了，必须要分库分表。

如果上分布式数据库，需要避免哪些坑？

--如何分库分表要根据自己业务、技术能力来做。 x轴拆分（水平复制数据库）、y轴拆分（按功能分）、z轴拆分（按用户分）。

以上仅供参考，欢迎点击阅读原文分享您的经验和观点

下载 twt 社区客户端 APP

与更多同行在一起

高手随时解答你的疑难问题

轻松订阅各领域技术主题

浏览下载最新文章资料

长按识别二维码即可下载

或到应用商店搜索“twt”

长按二维码关注公众号

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