银行业业务场景与数据库选型分析

银行业业务场景与数据库选型分析

​金融行业，作为数据使用的“高地”，长期以来非常重视数据技术发展。作为金融行业的重要组成部分，银行业一致致力于构建稳健的数据基础设施。作为数据的主要载体，数据库在其中扮演着非常重要的角色。随着近些年来，以分布式、云原生、多模异构等为代表的新型数据库产品出现，银行业正在经历新的一轮技术迭代更新周期。但因银行业务系统非常复杂，很难找到一种“完美”产品覆盖所有业务场景。如何根据金融业务场景，找到最适合的数据库成为广大金融从业者需面对的问题。本文，尝试从银行业业务特点出发，从业务特点、技术特征、技术路线等角度，阐述如何解决这一问题。

1. 银行业业务场景分析

银行业务非常复杂，在一个中等体量的银行中，会存在数百上千的业务系统。这些系统可按照其业务特点进行分类，不同分类的业务系统的使用人群、访问特征、可用性等乃至对底层基础设施的要求也有所不同。下面针对业务系统本身，做个简单分类。

2. 业务场景技术特点分析

1)业务应用分类

银行业务非常复杂，在一个中等体量银行中，会存在数百上千业务系统。下面从业务应用角度对系统做个简单分类。

流水型系统

流水型系统实现实时支付、证券交易、订单等业务的发起方和接收方之间的转接功能，典型的流水型系统是银行渠道系统、转接清算系统、非银行支付机构的快捷支付（协议支付）系统等。对于此类系统，业务请求和业务请求响应需要实时转发至业务发起方和业务接收方，对系统的实时性有较高的要求，但关键数据（如交易涉及的账户数据）的一致性由业务发起方和接收方保证，流水型系统对业务的流水信息进行记录。流水型系统的幂等性处理是架构设计的重点和难点，可采用多层幂等保障机制，如用户发起业务流量环节幂等、实时业务处理环节幂等、交易对账环节幂等。

账户型系统

账户型系统主要实现账户信息、用户信息等业务数据的处理和记录。此类系统需要优先保障关键数据的一致性，当灾难或故障发生时，应在达到关键数据一致性的前提下，实现业务可用性。账户型系统的数据一致性是架构设计的重点和难点，应结合业务模型选择解决方案，如关键数据采用同步复制等手段、将只读数据和可写数据分离、业务处理层与数据存储层协调工作等。

计算型系统

计算型系统实现清分清算、风险控制、商户结算等相关的计算，还包括金融领域的各种科学、工程、数据分析、音视频处理等相关的计算。此类系统对输入的业务进行计算，并将结果输出至其他系统，计算过程所需数据全部来源于单次计算业务请求或外部系统。此类系统重点保障计算应用的可用性和准确性。采用多活技术的计算型系统，可实现多点计算、多点输出结果。这样可将多个子信息系统的输出结果相互核对，提高准确性，还可在部分多活子信息系统出现灾难或故障时，直接取用其余多活子信息系统的计算结果

查询型系统

查询型系统实现对用户提供各种用户信息、交易记录、交易行情、订单记录、发布信息等相关查询。此类系统中的查询应用不会对系统存储的数据进行修改（或者查询业务流量比率远远大于有数据写入和修改的业务流量的系统），数据主要由外部系统导入。此类系统重点保障查询应用的可用性，以及被查询数据的多副本存储、被查询数据的多副本之间的一致性，以保证各多活子系统查询结果相同。采用多活技术的查询型系统，可实现多点查询。多个子信息系统之间可分担查询流量，并且在部分多活子信息系统出现灾难或故障时，可通过其他多活子信息系统查询信息。

典型场景介绍

日间联机业务（OLTP）

聚焦到银⾏核⼼就是客⼾账户查询、存/取/汇/贷款业务、小额⽀付业务、代收代缴费批量处理场景等。这类场景特点是业务时效性要求高、不同业务类型SQL混合请求、强事务⼀致性，小事务高并发。

日终批处理业务（OLTP+OLAP）

例如计提结息、总分核对、会计科⽬记账、借贷平衡检查这类时效性要求低⼀点的业务。在业务时效性要求相对较低，批量提交SQL，单位时间内对单个数据表读写量大，大事务高并发。处理上，⾸先要做分布式处理，然后进⾏分布式聚合处理、查询，最后按系统测算量和现有数据量的⼤⼩分批提交事务。

2)场景技术分类

根据上述不同要求，根据业务场景从技术角度进行分类。可按照如下维度进行区分。其中重点从数据规模、事务一致性、负载特征、数据分析能力、应用适配能力等角度进行对比，并给出建议架构。

3)技术指标分类

上述场景比较抽象，可再从场景的技术指标角度进行分类。下面的适配系统仅为参考，还需看业务系统的具体特点。如下图

3. 分布式技术方案推荐

近些年来分布式数据库非常活跃，很多银行也在做分布式数据库选型或者已采用分布式数据库。分布式数据库的实现路线有多种，主要有以下几种。

1)分布式技术路线

分布式中间件+单机数据库

这类产品，一般采用了典型的“Share Nothing”架构，实现存储与计算分离，通过上层无状态的计算节点提供弹性可扩展的计算能力，下层通过增强单机数据库提供基础存储能力及本地算力。这一架构通过硬件堆叠，可近似线性地提供计算性能和存储容量，具有可支持超大规模集群的能力。

原生分布式数据库

这类产品，一般也是采用“Share Nothing”架构，实现存储与计算分离。与上面不同的是，底层多采用自研或裸存储引擎，数据按规则打散并存储多个副本，通过paoxs/raft等分布式协议保证多个副本间数据一致。上层实现数据库基础的优化器、执行器等组件，对分布式事务、全局MVCC等支持更为彻底。此外，由于其底层的存储引擎不是依赖某一产品，可根据需要组织数据，因此在适配场景上更有优势，例如在某些分析类场景可选择列存。

云原生数据库

在某种程度上讲，云原生数据库也是一种分布式，但与前两者区别是非Share Nothing架构，而是Share Everything模式。其底层是与分布式云存储，本质上来说仍然是一种集中式架构。上层的计算部分，是无状态的一组结点组成。针对这种架构不足展开说明，原因是这种方式是需要对底座有比较重的依赖，无法在金融行业相对要求独立环境中部署，除非整个底层都更换。因此，使用选择上存在一定困难。

2)分库分表类推荐场景

下面针对第一种架构，即“分布式中间件+单机数据库”，结合之前谈到的场景及技术特点，描述下这种架构的适用场景的技术特点。这里说明下，此类产品演进迭代很快，功能也在不断增强，下面观点仅代表个人观点，不代表全部产品能力。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。