面对今天的互联网大环境，越来越多的企业IT部门开始探寻一条属于自己的互联网IT架构之路，首先遇到的抉择就是分布式架构的选择，尤其是分布式数据库的抉择。金融行业在面临这个新选择的时候，首先是覆盖范围的问题，究竟是全新改造还是混合并用？其次是选型问题，究竟该选择什么样的分布式产品，用在什么样的业务场景?再次是如何用的问题，是直接应用到数据库上，还是需要应用、中间件、存储侧的统合改造? 面对这些问题，社区近日组织交流活，召集金融同业来共同探讨，以下是活动中的分享，以问答形式总结如下。活动嘉宾专家及总结者：赵海

　　1. 关于金融行业分布式转型的必要性

　　【典型问题】

　　Q：金融行业把交易型业务使用数据库从传统的商业数据库切换到分布式数据库，可行性和现状？

　　Q：金融行业的分布式数据库转型必要性？提纲挈领的建议？

　　Q：金融行业的分布式数据库应用有没有必要性的场景？

　　【问题解答】

　　这是大家在分布式转型的时候，面临的首先要问题。也就是说我们为什么要进行分布式的转型？

　　其实这个问题我觉得取决于两点：

　　1.现有的数据库系统是不是已经无法支撑由于互联网业务转型带来的一系列需求？例如并发性，扩展性和灵活性？如果是那么分布式数据库无疑是我们应该研究的东西。

　　2.传统架构下的一些平台是不是伴随着业务的不断更新，出现了新的数据类型或者数据结构变得复杂化了，比如说一些新的非结构化、半结构化影像数据？

　　如果没有以上问题，那确实没有必要改。

　　结合以上的问题，我们觉得在金融行业当中，首先面临分布式转型决策的场景：

　　1.与互联网渠道业务息息相关的一些渠道类业务系统，它们所面临的并发和扩展性压力远大于事务性要求，因为他们的数据库当中多数存的是客户的流水、交易过程、签约数据。

　　2.随着手机业务的普及和升级，通过手机实现影像数据存取办理业务的场景越来越多，比如保险的理赔业务，这样的平台在这种情况下面临的是并发的压力，读写效率的压力，数据复杂化的压力，海量数据的压力，同样也是分布式数据库的首选应用场景。

　　3.前置系统的缓存，过去我们通过几个一两个中间件服务器就可以实现前置系统的一些缓存的处理，现在随着在线并发业务的增加，这一两个服务器已经成为瓶颈，这就需要我们寻找新的分布式架构来支撑缓存的处理。

　　2. 关于金融行业分布式数据库应用场景

　　【典型问题】

　　Q：保险行业分布式数据库的应用场景有哪些？

　　Q：证券行业分布式数据库应用场景有哪些？

　　Q：在金融行业，分布式数据库适合的应用和业务类型？

　　【问题解答】

　　我们觉得在金融行业当中，首先面临分布式转型决策的场景：

　　1.与互联网渠道业务息息相关的一些渠道类业务系统，它们所面临的并发和扩展性压力远大于事务性要求，因为他们的数据库当中多数存的是客户的流水、交易过程、签约数据。

　　2.随着手机业务的普及和升级，通过手机实现影像数据存取办理业务的场景越来越多，比如保险的理赔业务，这样的平台在这种情况下面临的是并发的压力，读写效率的压力，数据复杂化的压力，海量数据的压力，同样也是分布式数据库的首选应用场景。3. 前置系统的缓存，过去我们通过几个一两个中间件服务器就可以实现前置系统的一些缓存的处理，现在随着在线并发业务的增加，这一两个服务器已经成为瓶颈，这就需要我们寻找新的分布式架构来支撑缓存的处理。

　　保险行业当中有一个非常重要的业务，那就是如何根据客户的多维度信息来计算客户应该交纳的保费，还可以对客户进行精确划分。比如车险业务，传统的方法就是根据车型、车龄、历史年度理赔情况等等这些信息来判断这个客户的保费，这种算法模型显得有些粗放。还有一点，目前很多保险公司的各类系统数据不能很好整合，相互独立，导致客户的信息不够完整统一。所以，未来利用大数据的思路来整合各个系统的数据，甚至结合公有云电子商务平台的相关数据，一起来进行分析计算，设计针对客户的个性化保险方案是一个发展方向。那么，由于数据类型、复杂程度、获取源头、数据量各方面的复杂性，显然分布式数据库会更适合这样的场景。

　　关于证券行业，就说一个场景吧，大家买基金股票，看大盘的投资客户端，有没有发现互联网平台的从速度和实时性上都要比普通证券公司的APP要好一些？关键原因是不是在数据库架构上？

　　3. 关于金融行业分布式数据库转型的选型策略及关键点

　　【典型问题】

　　Q：对于开源分布式数据库怎么看?如何挑选和管理好开源分布式产品？

　　Q：金融业挑选分布式数据库应该看中什么能力？

　　Q：金融业目前优秀的分布式数据库产品方案有哪些？

　　Q：银行保险行业的影像平台如果希望从内容管理平台产品转向分布式数据库，该如何选型？

　　【问题解答】

　　面对众多的开源或者以开源为基础的分布式数据库，我觉得得从以下几个方面考虑：

　　1.产品的生态如何？供应商在产品的生态圈当中所占地位以及贡献比例是不是可以支撑产品的持续性发展，在生态圈内产品是不是算得上主流的技术和架构。

　　2.产品的服务体系如何？是不是有完备的成体系的服务框架，是不是可以引领产品的迭代更新。

　　3.产品有没有同行业同场景的现实案例？

　　4.产品本身的技术架构是不是适合业务场景？比如从用途上（缓存？影像？分析？）、数据结构类型（健值？文档？表？网页内容？）、存储引擎特点（B+？B？Hash？）等各个方面来评估是不是适合自己的业务场景。

　　那么在分布式转型的过程中，包括选型及运维的考虑，我觉得需要从以下几个方面去考虑：

　　1.质量：产品应该成熟可靠，经过大规模业务持续验证，拥有可信落地案例；

　　2.团队：建立能用、会用、用好国产数据库的建设运维团队；

　　3.持续：生态持续性要好，产品可以持续演进发展；

　　4.服务：不仅包括数据库，更能覆盖金融全技术栈的服务能力。

　　毕竟，金融行业并不是技术企业，技术是为了业务服务的，大多数中小企业没有必要花费巨大的代价去搞一套自己企业独有的分布式技术框架，利用现成的就好，只不过需要仔细去评估。至于行业标准，现在还没有看到一套正式的标准，但是先行的企业经验可以作为参考。

　　如果从转型过程或者前期的技术规划上，我觉得从上到下都需要关注。

　　1.从应用层面来讲，将将数据库处理的任务从一两个节点分散到多个处理节点上来达到提高性能的这个目标，是需要原有的业务逻辑上进行相应的适配，对业务系统进行分层解耦，确定应用层、服务的边界，评估原有业务的状态特性，改造相应架构以适应系统弹性扩展的需求，例如缓存层的设计，业务无状态的改造等等。

　　2.是数据分区的问题，分布式数据库要对数据进行分区，比如按照数据时间字段特性做分区、按照记录的某特征值做HASH分区，按照数据记录的区域特性分区等等。无论用什么样的分区策略分区，都需要考虑分区的大小、分区数据的热点程度、分区数据的增减平衡性，才能更好的实现系统的均衡调度以及扩展性。当然不同的分布式数据库有不同的切分算法和扩展算法，需要根据实际情况评估选择。

　　3.充分理解分布式数据库的工作逻辑，从业务上要尽量利用分布式的并行处理能力，将不同的任务并行处理，从而提高系统整体的吞吐量和效率。那么在数据更新写入的时候，一定会涉及到数据完整性和事务方面的考虑，存储层面的数据写入和更新的机制与分布式数据库的并发控制机制是否和谐？尤其是加锁的机制、数据粒度方面的协同性。

　　4. 关于金融行业分布式数据库转型的关键技术

　　【典型问题】

　　Q：分布式数据库如何保证业务数据的完整性和一致性？

　　Q：分布式数据库对传统数据库支持如何？

　　Q：系统中越来越多的数据库该如何管理和架构设计？

　　Q：与传统数据库相比，分布式数据库的事务算法应用于传统金融业务系统有什么优缺点？

　　【问题解答】

　　分布式数据库与关系型数据库相比而言，事务一致性是其的一个弱项。但是现实业务当中，其实有很多场景对事务的要求并不是极端的苛刻，只是我们没有好好去挖掘业务的特性。也有一些业务场景是可以接受经过算法改良之后的分布式事务机制的。例如：

　　1.两阶段提交（2PC）：两阶段提交是一种提交协议 ，在这种协议下，事务的实现被拆分成了几个不同的模块，一般分为协调器和若干的事务执行者。事务跨越了多个节点的时候，通过协调者，能够掌控到所有节点的执行结果，最终保证事务的ACID特性 。

　　2.最终一致性：业务特性不需要追求整个操作过程中每一时刻的强一致性，转而追求最终结果的一致性。也即是说，在整个事务执行的流程中，我们是可以接受的短暂的数据不一致的，只要最后的结果没问题就行。

　　如果某一个分布式数据库产品具备类似以上的事务处理机制，无疑是可以作为我们某些业务系统的备选方案。

　　关于应用迁移是否可以做到应用无感知？

　　这个有点困难，尤其在金融行业。Oracle 转 Mysql 的时候，会因为二者之间的存储引擎的差异，事务处理机制的差异以及表、块、锁等机制的差异导致一些莫名奇妙的问题。大家只能事先尽量系统化设计考量，过程中遇到问题逐一解决，最终达到稳定过度。这是一个长时间的事情。

　　关于OLTP和OLAP共用的设计是否合理？

　　共用可以，从设计角度来讲这是一个失败的设计。各有各的特点，OLTP并发高，锁粒度小但是频繁。OLAP没什么并发，以全表读写为主要特点。这二者混为一起，参数调优都没法儿干。

　　关于数据库系统架构管理的复杂性问题及解决方法。

　　其实这个问题，很多企业都会遇到。企业的数据库系统少则几十套，多则成千上万。数据库类型也是五花八门。DBA往往需要好多个，针对不同的数据库系统去做变更、配置、优化。这个问题我相信没有一种产品或者架构能够完全解决。只能通过我们对数据库管理的策略和思路来尽量优化。也就是 “数据库的整合”。

　　我们可以通过对业务系统对数据存取特点、业务重要性、业务相关性、数据量的规模等等维度把数据库系统进行统合分类，通过这样的手段把数量庞大的数据库个体划分为几个范围。那么同范围的系统是不是看可以考虑数据库的管理策略标准话，数据库的架构采用资源池架构，数据库的配置和变更可以采用同一个平台。例如：有的企业通过业务重要性和数据量的基础维度将数据库进行分片划分，然后采用Oracle 资源池的架构来解决一大堆中小数据库的整合问题。

　　5. 关于金融行业分布式数据库转型的过程管理

　　【典型问题】

　　Q：如何从传统数据库模式过渡到分布式数据库？

　　Q：从传统OLTP数据库转到分布式数据库，大家踩过哪些坑？

　　Q：分布式数据库转型过程当中需要关注的要点有哪些（应用层面、数据层面、存储层面等）？

　　【问题解答】

　　某银行转型的具体经过：

　　2018~2019 年，确定基于 Oracle+MySQL 实现双技术栈团队建设，并选择互联网银行业务选择开源 MySQL 方案；

　　2020 年，试改造， 团队对 MySQL 熟悉后，实现核心业务系统基于分布式数据库上线并开始运营；

　　2021 年，新老系统并行，数据保证实施同步回老业务系统，如新系统故障确保老系统可用；

　　2022 年，最终核心交易全量切换，封存老系统。

　　金融行业的分布式转型，这是一个漫长的过程。如果要选择分布式数据库进行升级换代，那么也必须是从应用、中间件、数据库等纵向全部改造之后的系统才能采用分布式数据库。

　　在这个过程当中，大家会遇到很多问题，不同的企业、场景、技术架构都会遇到不同的问题。不同的产品有不同的缺陷。

　　在设计和实时过程当中来讲，就关系型数据库，Oracle和MySQL本身的存储引擎是不一样的，对事务的处理机制也是有区别的，所以更多的是要看这些细节的区别可能导致的具体业务系统的问题。当然有些问题可以提前判断，然后通过应用改造避免。有些问题还真就得结合具体应用，实践当中碰到逐一解决。

　　传统集中式架构向分布式架构转型的过程中，企业需要应用的上层到下层进行一个全方位的思考和设计。

　　1.应用层面：将数据库处理的任务从一两个节点分散到多个处理节点上来达到提高性能的这个目标，是需要原有的业务逻辑上进行相应的适配，对业务系统进行分层解耦，确定应用层、服务的边界，评估原有业务的状态特性，改造相应架构以适应系统弹性扩展的需求，例如缓存层的设计，业务无状态的改造等等。

　　2.数据分区：分布式数据库要对数据进行分区，比如按照数据时间字段特性做分区、按照记录的某特征值做HASH分区，按照数据记录的区域特性分区等等。无论用什么样的分区策略分区，都需要考虑分区的大小、分区数据的热点程度、分区数据的增减平衡性，才能更好的实现系统的均衡调度以及扩展性。当然不同的分布式数据库有不同的切分算法和扩展算法，需要根据实际情况评估选择。

　　3.并发控制：充分理解分布式数据库的工作逻辑，从业务上要尽量利用分布式的并行处理能力，将不同的任务并行处理，从而提高系统整体的吞吐量和效率。那么在数据更新写入的时候，一定会涉及到数据完整性和事务方面的考虑，存储层面的数据写入和更新的机制与分布式数据库的并发控制机制是否和谐？尤其是加锁的机制、数据粒度方面的协同性。