| 编辑推荐: |
本文对分布式数据库在金融应用场景的数据库系统架构、功能和实施方案进行了介绍，希望对您的学习有所帮助。
本文来自于大数据期刊，由火龙果软件Alice编辑、推荐。
|
|
摘要：金融互联网化的迅速发展要求金融数据库系统同时具备高性能、可扩展、高可用和高容错等特性，传统数据库管理系统难以同时满足这些特性。为了应对金融互联网化带来的挑战，响应国家对技术自主可控需求，交通银行专注于支持金融行业典型交易的新一代数据库系统研发，通过实现轻量级分布式选举协议和分布式事务功能，开发了具备高性能、可扩展、高可用和高容错特性的分布式数据库，并成功将其运用于交通银行多个关键业务系统中。
1 引言
近年来，随着国际信息安全形势的日益严峻，国家信息安全战略逐步深入。为了应对金融业核心技术受制于人的严峻形势，中国人民银行、中国银行保险监督管理委员会相继提出了金融业应加快推进国产自主可控替代计划，以满足构建安全可控的信息技术体系的要求。然而，当前大型国有金融企业的核心系统主要依赖于国外IT巨头的集中式数据库产品和配套的底层硬件，核心技术缺乏突破，无法做到完全自主可控。
互联网金融化带来的主要挑战是数据量、交易量大幅度提高，并伴随数十倍于正常负载的交易高峰压力以及交易复杂度的增加。而商业银行采用的传统数据库在处理此类应用场景时，在扩展性、性能、吞吐量和可靠性等方面遇到了明显的瓶颈，只能通过简单的升级硬件的方式提升性能，不仅成本昂贵，而且面对互联网金融交易的指数级增长，这样的方式也无法保证系统的可持续正常服务。
近年来，大容量内存、高速网络和集群构建等技术的发展，为解决金融行业核心数据库系统支持互联网化改造提供了全新的思路。和传统的小型机、大型机相比，服务器集群具有更好的弹性，成本更低。此外，基于集群的分布式数据库在基础架构、事务处理、查询优化与处理、容错与高可用保障等方面都需要重新设计，才能保障数据库系统满足负担金融行业核心应用的高要求。
在此形势与背景下，交通银行联合华东师范大学和西北工业大学，于2013年开始共同研发可以支持银行核心交易的新一代关系型数据库系统，通过实现分布式选举和分布式事务两大核心功能，成功实现了具备高可用性、高可扩展性和高吞吐量特性的分布式数据库（以下简称CBASE），并将其应用于交通银行多个关键业务系统中。这是我国首例在大型银行的事务处理型应用中使用自主研发的数据库系统，打破了大型银行核心系统被国外IT公司垄断的局面，成功验证了国内商业银行使用自主研发数据库支撑银行应用的可行性，促进了金融领域自主可控技术的发展。
2 现有技术方案的局限性
2.1 传统集中式关系数据库
关系数据库理论诞生于20世纪60年代，经过几十年的发展与完善，技术已基本成熟。大多数企业的数据管理离不开关系数据库，其典型代表（如DB2、Oracle、MySQL等）广泛应用于各行各业中。关系数据库在工业生产、金融交易、企业管理方面占有举足轻重的地位。
然而，传统关系数据库系统的设计主要面向企业级应用，系统运行在独立的服务器上，而现代金融应用更多的是面向互联网用户。随着用户及相应数据量的急剧增加，传统的集中式关系数据库在可扩展性上的弊端日益显现。其技术缺陷可以简单归纳为以下几个方面：
单点处理性能瓶颈，即单节点的数据库系统无法处理大规模的用户并发访问计算；
单点运行风险高，容灾容错能力差；
单节点存储能力有局限；
应用扩容升级难度大，需要购置成本更高的高性能服务器。
金融行业、商业银行主要使用国外成熟的商业数据库产品，其对底层的硬件和配套软件有特定的要求，配套成本高，这样的模式不符合企业、银行控制成本的要求。此外，在核心业务上长期使用国外厂商的数据库产品，容易产生暴露信息安全的风险。最后，传统数据库厂商的核心代码都是在国外进行开发维护的，企业、银行在系统出现故障时，需要依赖数据库厂商到现场解决，沟通成本高，技术支持效率低。
2.2 NoSQL
互联网企业在发展过程中逐渐形成了一套基于非关系型数据库（not only SQL,NoSQL）的替代方案。在谷歌等公司发布了GFS
可扩展分布式文件系统、MapReduce分布式计算模型、BigTable分布式非关系型数据存储系统之后，在探索大数据存储、处理问题的过程中，逐渐诞生了一系列新型的数据库产品，其中包括列簇数据库、key-value存储数据库和文档数据库，这些数据库统称为NoSQL，如HBase、Cassandra、MongoDB和Dynamo等，这类数据库主要用于各大互联网公司的大数据和实时Web应用中。
NoSQL泛指不遵守传统关系数据、事务处理模型的下一代分布式数据库产品。NoSQL系统的分布式架构提供了一定的扩展性，同时通过备份保证了系统的容错性和可靠性。但是这类系统的数据模型采用按列存储或者key-value存储模式，更适合简单的数据操作，主要使用应用程序编程接口（application
programming interface,API）的方式访问数据，对SQL标准化的支持较弱且对SQL功能支持不足。NoSQL对金融业务的支持并不友好，这是因为金融行业应用中交易业务流程复杂，只能通过刻画业务能力更强的关系型模型实现。如果使用NoSQL直接替换传统关系型商业数据库，应用改造成本太高；而且这类系统牺牲了CAP理论中的数据一致性，只保证了系统的可用性和分区容忍性，这使得复杂的事务处理需要在应用层中实现，但是金融行业对风险控制要求严格，交易复杂度、业务一致性等方面的要求也不同于互联网企业，现有的NoSQL系统无法满足需求。因此金融行业系统普遍使用标准SQL访问数据。
2.3 基于数据库中间件
为了突破磁盘、CPU和内存等单机瓶颈，应对数据进行在线迁移。为了解决这个问题，除了购买成本难以控制的高规格服务器之外，有很多企业采用一种可以支持水平扩展的“数据库+数据库中间件”的解决方案。这种方案将数据库划分成两个层次：底层为在成本可控的商用服务器上使用成熟的关系数据库产品（如MySQL等）；然后在其上部署一层中间件，用于管理底层的数据库，并为应用提供透明的数据库服务。
这种方法需要对业务及数据进行分库分表处理，因此产生了一些局限性，如中间件的解决方案导致SQL功能受限，不能友好地支持复杂的跨分区连接操作。此外，由于缺乏统一的数据库锁管理机制，很多分布式事务难以实现。中间件本身的可用性也必须保证，在一定程度上增加了维护成本。
从数据库技术角度而言，无论是传统关系型数据库，还是互联网企业采用的NoSQL解决方案，在金融行业的应用中均存在一定的局限性。面对金融互联网化的挑战，迫切需要数据库技术的升级。为此，交通银行自主研发了一套分布式数据库系统，打破了上述瓶颈。下面将主要介绍系统的架构及特性。
3 系统架构与特性
3.1 设计目标
为实现自主可控、降低成本、可以承载金融业核心系统的目标，笔者团队对新一代分布式数据库期望的目标如下：
使用成本可控的普通服务器，能够以线性扩展的方式部署面向大规模用户与数据的应用；
可对外提供7×24 h、不间断、稳定的金融服务；
能提供丰富、高可靠、强一致性保证的数据处理服务，使之支撑各种复杂的金融应用；
能够应对应用高峰造成的压力（如金融优惠活动等特殊场景）；
方便系统的运维及管理。
上述特征表现在数据库系统上，即原子性、一致性、隔离性、持久性、可扩展性、高可用性、高可靠性、高吞吐量和高性能特性。数据库系统本身的复杂性决定了设计同时具备以上特性的系统存在很大的挑战。针对这一难题，在调研了大量的开源分布式系统后，笔者团队选取HBase和OceanBase等产品作为重点研究对象，沿用了HBase和OceanBase底层分布式存储模型，并在其基础上实现了基于读写分离的分布式数据库CBASE，从系统架构层面支持上述特性。
3.2 系统架构
如图1所示，CBASE的系统架构可以被划分为以下4个功能模块。
集群管理节点：主要负责管理集群中所有的服务器、数据分布及副本。
事务处理节点：主要负责响应更新操作，存储系统的增量更新数据。
图1 系统架构
数据存储节点：主要负责存储集群的基准数据，为了保证数据的可靠性，一般基准数据会存储多份。
SQL处理节点：主要负责接收并解析客户端的SQL请求，经过词法、语法分析和查询优化等一些列操作后，发送给相应的数据存储节点或事务处理节点进行执行。如果请求的数据分布在多台服务器上，SQL处理节点还需要将这些数据进行合并。
该分布式架构具备若干优势：
SQL处理节点、事务处理节点、数据存储节点分离解耦，各司其职，可根据需求对查询、事务、存储做到动态扩展；
对于大量改动不频繁的静态数据，利用普通的PC服务器进行多备份存储，通过冗余保证系统的高可靠性和高可用性，对于少量高并发事务产生的更新数据，配置大容量内存的事务处理节点处理，有效提高了事务的处理性能，并能有效应对高并发应用；
通过系统集群管理节点及事务处理节点间精确的一致性协议，做到数据存储节点及事务处理节点都具备多个实时同步的备份，主备角色间实现了快速切换，实现了系统的高可用性，即保证系统99.999
9%的时间是对外可用的。
此外，笔者在SQL标准化、查询支持、系统运维方面也做了很多努力，使之能支持复杂的金融业务场景。下面将简单介绍CBASE中使用的几个关键技术。
3.3 分布式数据库关键技术实现
3.3.1 写性能优化
CBASE设计和实现了读写分离的系统架构，区别对待读负载和写负载，并分别对其进行优化。对于未修改的冷数据，采用大量普通PC服务器进行存储，解决海量数据的可扩展管理问题。更新的热点数据被存储于内存大的少量事务处理节点中，当事务处理节点内存达到一定大小时，可以通过自动或者手动冻结的方式将数据存储到固态硬盘（solid
state disk,SSD）中，然后通过定期合并的方式将这些数据分散存储到静态数据节点中。这样的设计能支持可扩展的、高吞吐量的事务处理请求。大部分事务处理无须跨越事务处理节点，因此可以通过增加事务处理节点的方式提高系统的处理能力。对于少量分布式事务，可以通过优化的两阶段提交降低事务延迟。事务处理节点采用大容量内存存储数据，回避了传统数据库中集中式的锁管理器，采用更轻量级的基于行锁、多版本的并发控制协议以及混合存储介质存储日志等技术，极大地提升了系统性能。
3.3.2 高可用性保障
为提高系统的可用性，利用普通服务器集群以及主备同步的方案，实现系统对外7×24 h的可用性保证。传统的主备同步方案无法在保证数据一致性的同时，满足系统的高可用性。CBASE系统突破传统数据库难以同时兼顾高可用性与高一致性的困境，设计和实现了集群环境下分布式数据库的高可用性和高一致性日志强同步。基于Raft协议，设计和实现了轻量级分布式选举协议。在故障发生时，系统能够快速地从多个集群管理节点中选出主集群管理节点，并保证该主集群管理节点选举出包含全部已提交数据的主事务处理节点，实现了系统的高可用性以及数据不丢失。图2为CBASE中实现的分布式选举协议的状态转化，这是一个不确定性有限自动机。节点角色随着选举的进行可能随时出现以下变化。
当一个节点刚启动或从故障中恢复时，其角色为备节点，同时会设定一个定时器。如果该节点收到主节点发送的更新日志，则会重置定时器，保持角色状态不变。否则，定时器超时后，即认为集群中没有有效的主节点，该节点会转变为候选者，准备竞争成为新的主节点。
图2 分布式选举过程状态转化
候选者向其他节点发送投票请求后，可能出现3种情况：获得多数节点投票的节点成为主节点；收到更新日志信息，说明集群中已有主节点，候选者转变为备节点；选举超时，重新发起新一轮选举。
节点成为主节点后，便会向备节点发送更新日志，并重置其他节点的定时器。
分布式一致性算法（如Paxos、Raft算法）选主节点的过程可能出现活锁、多主节点、频繁选主节点的现象，这些对银行核心系统的可用性和可靠性有着不可预测的影响。本文使用一组轻量级的无状态集群管理节点选择事务处理节点的主节点。当集群管理节点选举主事务处理节点时，无须通过传统投票方式进行选举，直接根据事务处理节点的日志信息选主节点即可，从而解决了活锁问题；对于多主节点问题，本文提出在主节点上添加日志复制租约机制，如果主节点在租约时间内无法将日志成功复制给多数节点，主节点将会放弃主节点身份，等待重新选主节点；对于网络分区造成的频繁选主节点问题，新的选主节点请求需要先等待旧主节点租约过期，而此时集群管理节点能够与每个事务处理节点保持正常通信，不会发起新的选主节点过程，从而避免了事务处理节点的频繁选主节点的问题。
3.3.3 分布式事务
事务处理是支持金融行业应用的关键技术，保证了业务数据的完整性和一致性。现代大型银行应用除了要求数据库系统提供完整的事务功能支持外，还需要数据库系统具备互联网级并发事务处理能力。针对金融业务系统事务处理类应用的特征，
CBASE设计和实现了支持高通量事务处理的分布式数据库系统，相比原来采用的集中式数据库（DB2、Oracle）,CBASE无须用户设计、维护分库分表规则，系统会自动根据主键将数据划分到不同的事务处理节点，实现业务逻辑和数据存储解耦合，减少开发和维护复杂度，实现了资源线性扩展，集群解决I/O上限瓶颈。
在CBASE的分布式事务引擎实现中，采用如图3所示的优化的两阶段提交，保证事务的强一致性。当无故障时，该协议实现比较简单；但当发生故障时，如服务器下线、消息丢失或网络故障，采用超时动作防止进程无限阻塞，因此协议实现时，在进程可能阻塞的每一步都加入超时动作。在最坏的情况下，两阶段提交协议在执行过程中可能出现任意多次服务器故障和通信故障，并造成参与者很长时间停留在不确定状态上，这就是未决事务。
图3 优化的两阶段提交
未决事务处理其实就是两阶段提交协议的恢复流程。分布式事务在执行过程中的决定都保存在一个或多个恢复文件中，恢复过程就是根据持久存储中的内容恢复对象的值，也就是分布式事务的最终状态。对于参与者处理事务请求的过程中出现的等待超时的情况，参与者依次向其他参与者或Paxos组内的其他备协调者获取当前事务的最终状态。如果当前参与者无法获取事务最终状态，由于参与者也是Paxos组，可尝试切换主参与者。如果始终无法获取当前事务的最终状态，该参与者将不可用，需等待数据库管理员干预。
4 应用与实践
数据库属于系统底层核心组件，且分布式数据库技术存在大量的技术难点，此前金融领域也没有相关案例，因此在应用与实践过程中，交通银行遵循“稳定第一、谨慎试点、稳步推广”的原则，先后在金融行业查询类业务、流程类业务和高并发类业务中逐步推广应用，试点均取得了良好的效果，节省了大量的成本。下面以查询类业务（历史数据查询系统）和高并发类业务（贷记卡授权系统）为例，介绍分布式数据库在金融行业的实践。
4.1 分布式数据库在历史数据查询系统中的应用
随着时间的推移和业务的发展，各企业历史数据查询系统都会面临历史数据量不断增加、系统架构中传统数据库难以满足日益增长的需求的问题，这些问题逐渐成为系统瓶颈。金融行业的历史数据涵盖范围更广，以交通银行历史数据查询系统为例，其涵盖了主机业务、账务系统、贷记卡等上百个业务系统的历史数据，这就要求数据库具备良好的扩展性，以满足业务量的快速增长需求。除了存储历史数据外，历史数据查询系统还需要对外提供联机事务查询和部分更新服务业务，以减少其他在线业务的历史数据管理压力，这就要求数据库能够快速响应联机查询服务。
历史数据查询系统要求数据库同时满足高性能、高可靠性和高可扩展性，分布式数据库可以很好地满足这些要求。在经过大量的评估和测试后，交通银行于2014年在历史库系统中使用CBASE。目前系统整体数据量已超过上百TB，且以每日超1
TB的量不断增加。在大并发查询下，查询响应时间均保证在毫秒级别。多年的稳定运行充分验证了自主研发的分布式数据库应用于金融领域的可行性。
4.2 分布式数据库在贷记卡授权系统中的应用
信用卡业务的纵深发展和客户量的增加使交易量不断上升，需求变更越来越频繁，迫切需要贷记卡授权系统提供持续高效、可在线升级、7×24
h稳定的交易服务。另外，随着互联网金融的崛起，支付宝等电商“双11”网购促销引发的交易爆发式增长，更加重了系统的负担，给传统数据库带来了前所未有的挑战，不仅系统资源无法满足高脉冲的冲击，数据库系统本身也存在着潜在的性能瓶颈。
为更好地保证贷记卡授权系统的稳定性，大幅提升系统整体处理能力，笔者团队在原有系统架构的基础上，利用CBASE对高并发业务产生的系统压力进行分流。基于CBASE的新一代贷记卡授权系统具有如下特点。
高并发处理能力：高峰每秒事务处理量（transaction per second,TPS）上万。
弹性扩展能力：系统处理能力可以快速弹性扩容。
高可用性：保证业务系统7×24 h在线服务，该系统经受了“双11”时业务量的考验，成功分流了高并发时的主机压力。
在银行的多个关键系统试点过程中， CBASE架构逐渐成型，功能逐步完善，性能逐渐提升，可靠性逐步增强，向着产品化方向稳步发展，取得了良好的社会效益和经济效益。未来笔者将继续扩大CBASE试点范围，充分发挥分布式数据库的技术优势、成本优势。
5 结束语
针对金融行业的业务需求，笔者团队对数据库系统架构、功能和实施方案进行了重新思考。为了满足金融互联网化对系统可扩展性和事务处理的双重要求，在借鉴开源分布式系统的基础上，实现了面向金融行业应用需求的新一代NewSQL数据库——CBASE，并将其成功应用于交通银行多个关键业务系统中。国内外流行的同期数据库产品包括以HBase为代表的NoSQL和以VoltDB为代表的NewSQL。前者为了获取高可扩展性和可用性，降低了对数据一致性的要求，这与金融行业系统的需求相悖；后者为了追求对写负载的高性能而牺牲掉其他负载的能力，而金融行业体系非常复杂，需要数据库能够同时应对多种负载和应用需求。因此，无论是NoSQL还是已有的NewSQL，都难以满足金融领域复杂的业务需求。CBASE成功填补了这一空白，并在交通银行的关键应用中得到了充分验证。
| 
