邓刚

分布式数据库在金融行业内已经有很多案例，比如北京银行的案例：https://pingcap.com/zh/case/user-case-beijing-bank 网商银行的案例：https://mp.weixin.qq.com/s/NdLLSQ_WHqG-fMa4x5rYhg

分布式数据是未来数据库发展、建设的方向。分布式数据库也是从传统数据库演化来的，传统的 DBA 大多数的知识和经验仍然能够用到分布式数据库的运维上，比如 SQL 的优化，服务器资源的监控、优化等。建议可以从了解、搭建一

两种方式各有利弊、都是可以的。需要根据实际情况进行选择。比如，如果业务系统是重新开始搭建的，可以更多考虑适配选定的数据库。但如果业务系统已经上线使用，更多的需要考虑数据库适配应用。

分布式数据库由于多数采用 share nothing 的架构，跨节点事务的性能是一个很大的挑战。对于死锁检测问题，分布式数据库都有各自的方式，比如在 TiDB 中维护了全局的 wait-for-graph ，通过确保该图无环来避免死锁。在中间件

对于中小城商行，从性能和数据量上来说，单个交易系统使用传统数据库也可以满足要求。引入分布式数据库主要是从提高响应业务的敏捷性，弹性扩容、降低运营成本等几个方面来考虑。引入分布式数据库，由于性能一般都能满足要求

测试数据库性能可以采用业内标准的 TPC-C 来进行。也可以参考信通院的金融行业分布式事务数据库测试来进行 。

分布式数据库经过这几年的发展和使用，功能已经比较完善，性能也能满足银行绝大多数的使用场景。银行 OLTP 类业务很多都可以适用。但一些业务系统，如果使用了传统数据库的某些特定功能，比如存储过程，则改造适配起来会比较困

计算和存储分离，更容易实现资源池化，部署与扩展也能更加灵活，是未来发展的趋势。计算和存储绑定的方式，从目前来看，能更加充分地利用资源，实现更高的性能。在选择上，需要遵从企业数据中心规划的要求，比如是否计划近期进行数据

信通院有一个模拟银行转账交易的金融分布式事务数据库测试 。

在确保全局一致性的前提下实现更高的性能，是分布式数据库实现的一个关键点和难点。不同的分布式数据库有不同的实现方式。一般来说，如果集群的规模很大，达到几千甚至上万台，有的选择专门硬件如原子钟，来保证整个机群版本的