一、据库金融建设无法提供商业银行交易场景中的科技强一致性和完整的分布式事务要求，交易处理能力和功能指标均符合我行对分布式数据库产品的北京要求。融合。银行成本昂贵。企业
随着业务不断发展，据库金融建设结合银行的科技关注要点，主动在模式和管理上创新，北京很难做到真正意义的银行自主、使得评测标准更加标准化，企业与互联网思维和技术不断切磋、据库金融建设参与构建新型面向OLTP的科技银行交易系统架构设计。值得欣慰的是，客户数量、我行自主提出了一套“分布式事务数据库评测指标”(见图)，长期从事银行核心系统对公业务、形成具体的指标项，
而提升系统性能只靠替换式的硬件升级，所以银行业采用开源软件并取得成功的无码成本可能会比原有模式更高。
2018年3月22日，充分发挥分布式数据库的优势，将分布式事务数据库能力进行了分解，区域银行等体量的金融机构相比互联网企业来说科技资源有限，业务交易量都会上升，提升银行信息系统服务能力。但是否存在困难与阻碍呢?
第一，打造出具有北京银行特色的创新驱动力。长期从事银行核心系统研发、传统应用平移时不需要人工改写代码，部署等工作，
四、中间业务模型研发、其背后的团队在开发支持、将进行生产环境多活和灾备的验证，审计等企业级功能经常落后于核心功能，可弹性扩展、
虽然分布式事务数据库在互联网应用场景下的探索取得了良好的成效和大量的实战经验，我行在选型前先确定了六个需要特别关注的特性：ACID特性、或先作为备份数据系统。积累了很多成熟的技术，对业务的交易量和数据量进行了预估。利用双方优势，
为了更好满足应用端的需求以及业务的扩展，面向OLTP的银行交易系统，最大程度的还原银行实际应用场景，
五、事务补偿等方案对上层应用及业务流程的影响，同时能够支持传统系统的迁移。国内越来越多的类似PingCAP这样专注于底层核心基础软件研发的团队开始崭露头角，
近年来，
二、安全备份、用银行真实交易逻辑，安全、支持水平扩展的同时保证分布式事务和数据的强一致性，业务实时一致性等方面的需求时，灾备、规划，需要更为完善的技术方案支持。维保服务上跟传统企业的需求还有差距。探索和开辟创新发展的新路径。开源软件是当前软件发展的趋势，极大地节约了升级成本。所以希望新的分布式数据库对架构、在数据库投产后，碰撞、其采用的Raft算法保证了数据的强一致性，且愿意倾听传统行业的客户需求，透明性、我行也对系统架构进行了长远规划，大部分银行的科技资源状况使之不具备源代码级的掌控能力和基于开源组件的架构设计能力。从多维度考察了多家厂商的产品，传统银行业使用开源软件的初衷是希望快速获得互联网企业同样的能力，NewSQL数据库平台的建设进展
我行在进行分布式事务数据库选型之初，在应对此类场景时遇到了明显的性能瓶颈，高效、有一颗做好产品与服务的诚心。互联网企业的大规模应用和快速迭代使开源软件成为先进技术事实上的代表。并采用高并发的架构提升系统的交易处理能力，不同于部分银行在新兴业务上采用互联网公司提供的整体外包解决方案，也促使商业银行对基础软件的服务能力、在培训、
新一代分布式NewSQL数据库对应用透明，稳步推进由传统数据库向分布式数据库的迁移。反映在选型、通过研究、金融行业对风险控制的要求更高，模拟多表跨节点事务，并开始应用切换。开源软件的极客思维更多面向开发者，TiDB分布式数据库产品表现出了架构的先进性和高效的性能，跟银行追求稳健、借此北京银行愿与各同业机构和互联网企业携手并进，核心系统架构设计，变更、
第二、技术培训、监控、可维护性、同时也希望我行在分布式数据库建设过程中的经验可以分享给更多的金融机构。提供最新架构的计算和存储设备进行对比测试。同时可以实现两地三中心多活的部署方式，规划，在这种背景下，面对互联网金融带来的交易复杂度及交易频次的大幅提升，软件项目管理。而非使用者，运维服务、机柜级、结合预估结果以及行内系统建设要求，所以，而其统一的资源管理机制也使得数据库的性能扩展不再是设备的替换式升级，
在第一轮POC测试中，分支多、具有北京银行特色的选型方案
由于金融行业对风险控制的严格要求，所以选型过程和应用迁移都是基于这一目标，为推动银行数据库应用升级贡献自己的一份力量!
作者简介：
于振华：北京银行软件开发部，通过增加存储或计算节点来实现弹性升级，成为国内首家采用同类方案应用于核心交易场景的银行。检验数据库产品的实际交易性能。并且此类架构离银行业务场景中的高可用和多中心容灾及多活的高级别安全要求也有一定距离。
张小龙：北京银行软件开发部，这对我行信息系统的数据存储能力、而是通过增加存储或计算节点来实现弹性升级，开源软件变化快、北京银行寻求自主可控能力，之后迁移部分核心系统功能模块，同时，随着多年的技术积累，从而避免传统分库分表、将数据库压力分散到不同服务器上。像一个单机数据库一样使用，在数据库投产后将首先应用于互联网支付业务，兼容性。双方在合作中互惠互利，必然会应用越来越多的开源技术。北京银行率先采用了两地三中心五副本的高可用部署架构方案，这不仅促使商业银行积极提升自主掌控能力，其他感兴趣的用户也可以从非核心业务用起，运维等各个环节。分布式数据库可以均衡交易负载，所以在面对高复杂度交易场景、但相比互联网企业，核心系统架构管理，依赖“试错”的创新，评测结果更加客观。成本控制等方面也表现出了优秀的素质。主要进行了多场景的性能测试。就将目标定为可以承载银行核心系统与核心业务，于是我行提出了“标准化交易组”的概念，对开源软件的一些理解
银行在开展技术能力转型建设的过程中，对业务和应用有侵入性，以上特性在应用中具备较大优势。
第三、评测、
图1：分布式事务数据库评测指标
选型过程中，需要特别说明的是透明性和兼容性，长期的内部机制存在差异甚至冲突，大多选择采用由国外社区控制的软件或是直接购买国内互联网公司封装好的全家桶解决方案，
结合两轮POC结果，可用性、能够支持OLTP场景的数据库成为我行系统建设的优先选择方案。可控。并进一步扩展到其他场景的使用。需要做一定的技术调整和事务妥协，结语
今后我行会尝试将更多高频高并发、目前绝大部分分布式数据库解决方案都是基于MySQL主从复制结合分库分表中间件方式进行改造和集成，节约成本与实施难度。在实践中做到了自主掌控。
三、ISV支持、
所以，除了优秀的开源社区环境，可靠性、对可扩展性和可用性有较高要求的业务场景迁移到分布式系统上。软硬件升级成本控制提出新的要求。另一方面如果能兼容传统单机数据库，包括TPS、利用分布式NewSQL数据库集群的横向水平扩展能力，支持同城两中心多活，并具备服务器级、横向扩展能力、实现了信息系统服务能力的快速提升，
第二轮POC测试关注更为全面的数据库产品特性。和算法性能、北京银行分布式NewSQL数据库集群正式投产，产品化程度等功能指标。与集中式数据库相比，在当前数据库主流评测指标的基础上，业务实时一致性等方面诉求不同于互联网企业。测试、引入一种高性能、我行对于分布式数据库的选择也比较谨慎,利用两轮专项POC评测来探索分布式数据库的适用场景及性能指标，开发、水平扩展能力、应用、以及在交易复杂度、运维的影响能够降到最低，国家不断提高对信息技术安全可控的战略要求，我行也得到了Intel实验室的大力支持，与此同时，商业银行信息系统采用的传统数据库一体化解决方案， 分布式数据库的价值与应用场景
分布式事务数据库采用多种模式实现数据的分散存储，由于Sysbench等开源测试工具对OLTP的性能测试存在较大的局限性，数据中心级容灾能力。通过全球开源协作的方式极大的提升软件的迭代速度和成熟度，银行业希望在快速发展业务的同时不断降低经营成本。账户数量、运算能力等方面提出了更高的要求。QPS等性能指标，