Q1、传统核心架构向分布式双活架构迁移过程中，应该考虑哪些关键因素？

【问题描述】目前我行设想将核心系统由传统架构迁移至分布式微服务双活架构，作为操作系统低层运维人员，需要关注哪内容？

@lulihuan1987 张家港行 数据库管理员：

您说的这个情况是核心应用层面的集中式向分布式微服务架构转型的场景，目前核心应用微服务架构是个必然的趋势，而且有不少成功的案例。

应用微服务架构这块不是太专业，我谈谈我个人的理解，不够全面，希望对您有帮助。

对于系统运维人员，主要关注微服务框架行业应用情况、微服务架构的高可用情况（RTORPO）、灾备方案（或双活）、组件部署方案（云、虚拟机、容器等）、监控和管理平台情况以及与行内运维平台对接情况、应急预案等；

对于应用运维人员，除了要关注典型业务场景、业务流程外，微服务架构特有的业务拆分场景、异常情况下一个交易多个事务的一致性等问题。

对于数据库人员，主要关注微服务架构采用的数据库情况，如果采用分布式数据库，可以参照我们本次讨论的核心与分布式数据库适配的相关问题。

Q2、如何实现核心业务系统的传统数据库架构向分布式数据库转型？分布式数据库在解决高并发和高扩展性上有哪些优势？

@JanXC nec 系统架构师：

回答这个问题得需要勇气啊，核心业务系统的数据库，重中之重啊。

对于这个问题，我觉得分两方面，一方面需要从业务体量及发展上来看，是否需要这也做，承担分布式数据库架构相比传统架构在横向扩展方面有先天优势，但我们的业务是否到了需要横向扩展是否到了需要频繁扩容的地步，另外分布式数据库在简单事务处理方面的性能是低于传统的集中式数据库的，这个需要注意。

最后，是怎么做的问题，我可以很明确的指出，传统数据库架构改为分布式数据库，系统架构方面一定要重构，代码进行改造，当你要对系统重构的适合，对业务进行模块化拆分，程序方面的拆分以及数据库方面的拆分优化，一个大的集中式数据库拆分为低耦合的小数据库，那是否还有必要进一步使用分布式的数据库架构呢，这个我认为必要性不大。

Q3、分布式数据库建立的必要性？

【问题描述】分布式数据库带来人员成本和设备成本的上升。而带来的性能的提升有时是不足以cover住这些成本的。请问，如何评估企业的业务是否适合于部署分布式数据库？

@lulihuan1987 张家港行 数据库管理员：

我们目前采用的是TDSQL（MySQL版本）数据库，其提供了分布式版本和非分布式版本，分布式版本是数据分片的，非分布式版本是数据不分片，为集中式数据库主备集群，两种数据库统一由管理平台管理，均实现自动化运维和智能运维。

我们根据我们行的业务规模，对一般业务系统，单节点的物理机性能足以满足其未来3-5年业务发展需求的，我们会采用非分布式版本；对于关键业务系统，像核心系统、互联网类、支付类、信贷类，后续随着业务的发展单节点（也受物理硬件限制）是无法满足业务发展需求的，会结合业务发展进行节点扩容的，我们通常采用分布式版本；

所以我们主要看几方面：业务系统等级、业务系统性能要求、业务系统扩展性需求、数据库所在物理设备性能极限，优先采用分布式数据库。

这里顺便提一下，2019年中国人民银行印发《金融科技（FinTech）发展规划（2019-2021 年）》（银发〔2019〕209 号）金融科技发展三年规划中提到的“加强分布式数据库研发应用”的要求，目前已经接近收关，同时人民银行目前在进行XC试点，其涉及分布式数据库的应用，所以2022年明年起的分布式数据库应用的推广的力度可以大胆的预测一下，到时候看性能和成本可能只是一方面了。

@fanyqing 厦门银行 系统架构师：

是否要建立分布式数据库，还是要基于场景和具体的业务需求，不能一概而论。分布式数据库本质上是物理上分散而逻辑上集中的数据库系统，利用分布式事务处理、数据自动分片、数据多副本存储等技术，将分散在计算机网络的多个逻辑相关节点连接起来，共同对外提供服务，因此，具有良好的扩展性，适用于大并发和海量数据的处理。但因分布式数据库将数据分散到各个节点上，需要利用分布式事务来保证数据的一致性，因此，必然会带来额外的开销，这就要求在数据库设计时，必须充分考虑应用产生的数据特点，合理选用分区键和数据分布策略，尽量减少跨节点的分布式事务，以提高数据库性能。故对设计人员的要求也较高。所以,如果应用系统需要处理的数据量不大，可用传统的集中式数据库，而不需要分布式数据库。

@赵海 技术经理：

这是大家在分布式转型的时候，面临的首先要问题。也就是说我们为什么要进行分布式的转型？其实这个问题我觉得取决于两点：

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

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

如果没有以上问题，那么建设分布式数据库的步伐可以放缓，或者作为试验田。

@JanXC nec 系统架构师：

主要还是业务需求和系统架构吧。业务数据量非常大，每天的计算和落库数据很多，集中式数据库的锁等待问题严重，则有必要，但是如果应用尚未支持，则单纯数据库分布式意义也不大。所以还是得从当前数据库的数据量、并发以及吞吐等情况综合衡量，当真的集中式满足不了的时候，提前规划。

@孔再华 中国民生银行 数据库运维工程师：

分布式数据库通过横向扩展资源来实现性能的扩展和高可用性的提升。所以看起来这项技术就是未来发展的方向，而当前也确实涌现出很多的优秀的分布式数据库产品。然而作为新兴的数据库技术，分布式到底能解决什么性能问题，是否也会存在新的瓶颈，带来新的损耗？分布式数据库的技术复杂性又会带来运维成本的提升，那么这些提升又是在什么方面呢？是不是预示着数据库运维已经面临一次很大的变革转型？下面仅仅代表个人的看法：

1、 分布式的性能不是万能的，但是必须的

从金融业内对分布式数据库技术的测试来看，采用不同分布式技术的数据库产品在测试里普遍出现了性能偏好。也就是使用的数据库技术主要是为了解决一类问题。面向tp的分布式数据库解决大表和热点数据等问题，通过数据分片和事务分发实现性能提升。面向AP的分布式数据库通过算子优化计算下推等方式，充分利用节点的分片计算性能来提升AP业务的速度。而部分存储计算分离的分布式数据库主推运维便利性。但是这些分布式技术可能带来延时变长，交互瓶颈和数据重分布等可能出现的分布式环境特有的问题，所以还需要搞清楚这些分布式数据库的缺点，避免踩坑。

所以面向特殊性能需求，选择合适的分布式数据库，这是最切合实际的做法。

2、 分布式数据库的复杂性对于运维带来的不仅是挑战，也是运维模式的改变。

分布式数据库的运维存在两面性，一方面新的技术复杂，另一方面运维分布式数据库的方式也在发生根本的改变。为了充分利用分布式数据库的能力，相信很多的客户更愿意使用多租户的方式来管理业务对数据库的需求。未来分布式数据库应用的分水岭不仅仅是性能，还在于这种多租户的管理能力。而分布式数据库的集中式运维，与数据库上云后的智慧运维其实是相似的。所以大家都要开始新的运维模式转变，不如从分布式数据库开始做起。

3、拥抱分布式，拥抱云，现在就开始

分布式数据库和数据库上云一定是趋势，现在正是熟悉这些技术并掌握的时候。如果等到不得不面对的时候，反而困难重重。因此不如从现在就开始挑选合适应用尝试使用分布式数据库，在实践中积累产品技术和运维经验，积硅步以至千里积懈怠以致深渊

@luxh08 某互联网银行 科技部门副总：

技术服务业务，用什么数据库架构是业务发展带来的，很多银行为了技术先进性使用分布式数据库，明明oracle等单机关系数据库能搞定的事，一定要不顾成本的改造应用去适配分布式数据库，由于自身技术欠缺，还需要购买三方的服务，这种政绩式的项目也不需要去评估成本收益性。我们需要考虑在一些海量数据、海量用户的业务场景考虑分布式数据库，是因为在这种业务场景中，分布式数据库的性价比要远远高于单机关系型数据库，适不适合采用分布式数据库架构，完全由业务场景决定的。

@韩成亮 KE 数据库管理员：

首先请问什么叫必要性？如题所说分布式数据库带来不少成本上升，而关心的却是性能是否cover住成本，这个其实有一点问题，不在点上，从性能而言，分布式其实并不好 需要知道分布式解决的问题是扩展和容灾，首要考虑的是数据强一致 而不仅仅说把分布式数据库当成分片数据库。

@libai21 海通证券 软件架构设计师：

我觉得分布式在架构方面是优于集中式的。分布式数据库和集中式相比，性能肯定是下降的，分布式的事务成本太高了。但是在扩展性和可靠性上会比集中式好很多。这两种架构各有优劣。分布式天然的支持DBaaS，也是一个明显的优点。可以把分布式和数据库上云这两件事一起做了。我觉得云化以后，硬件的成本应该差不多。

Q4、分布式数据库与云原生分布式数据库，分布式数据库未来的发展方向?

【问题描述】2019年以前，IT业界都在围绕分布式数据库/关系型分布式数据库进行研发和实践，这一阶段的分布式数据库主要是指分布式数据库是基于分布式存储的、而不是分布式计算的，这一阶段的分布式数据库从行业实践来看，效果实际上不太理想、银行核心系统很少有实际应用。从2020年开始，IT业界开始转向云原生分布式数据库，也许分布式数据库的成熟和应用就在云原生分布式数据库这一阶段？以上是个人的一点理解，请各位专家发表意见和看法，共同讨论、学习和成长。

@lulihuan1987 张家港行 数据库管理员：

从数据库技术发展趋势来看，云原生数据库，计算和存储真正解耦是数据库发展技术趋势……

云原生数据库也是从AWS aurora开始，国产TIDB、腾讯CynosDB、阿里的PolarDB是国内云原生数据库的代表。

像目前在金融行业规模在用TDSQL、GOLDENDB、OB的版本，基本都是基于分布式存储的、而不是分布式计算的，这类数据库近几年在银行其实已经被广泛落地并成功实践了，包括银行最重要的核心系统……

Q5、分布式数据库结合两地三种架构怎么规划，和测试节点间性能？

@lulihuan1987 张家港行 数据库管理员：

两地三中心的话，同城两中心既可以双活接入业务也可以互为热备，异地三中心与主中心数据库进行数据同步，作为异地灾备。

对于核心交易型数据库（OLTP型），这里需要关注好网络延迟和网络质量，分布式数据库数据是分散在各节点的，节点间会有数据交互，一旦业务的事务较大，那么网络延迟对事务的影响可能会越明显，即一个事务，应用和数据库要交互越多越明显，所以在设计同城双中心双活的时候，一方面要保证双中心间的网络质量，另一方面要减少跨中心的业务流向，比如同中心的应用去访问同中心的数据库，中心间的流量尽可能是数据节点间的同步流量为主。

比如我们优化时有个贷款类业务，一个事务600多次数据库操作，每次要经过应用、数据库网关负责均衡器、数据库网关、数据库存储节点，如果网络延迟较大，那交易耗时在网络上的耗时就会很明显。所以网络质量对交易型分布式数据库还是比较重要的。

Q6、引入分布式数据库的核心系统，IT投入成本每年能下降多少？

【问题描述】在核心系统引入分布式数据库后，IT投入成本每年能下降多少？毕竟除了号召国产化的同时，成本预算这块肯定要考虑的。首次分布式架构的改造成本以及未来每年的节约成本，能有个数据能更好地进行成本估算。

@lulihuan1987 张家港行 数据库管理员：

对于这个问题，我们在和领导汇报的时候必然需要准备的。建议可以从如下几个方面进行对比分析：

1）硬件投入对比：分布式数据库通常都是通用X86或者ARM服务器，集中式数据库通常需要高端小型机、SAN、高端存储以及存储双活同步等，考虑集群加灾备，基本上是要考虑三套。

硬件成本投入的优势比较大。

2）数据库软件授权对比：这个看怎么谈了，通常分布式授权也不一定特别便宜。

3）应用适配投入：这块集中式数据库比较有优势，应用适配分布式数据库的改造可能会增加费用，这个也是看怎么谈，如果应用做过相关适配案例了，那这块成本会低一些。

4）咨询和测试投入：基本差别不大。

5）运维投入：分布式数据库通常自带自动化运维平台，是不是需要另外采购，看商务，集中式数据库运维工具和平台可能需要额外采购；至于运维人员的培养，笔者认为做核心必须在整个过程中培养几个对分布式数据库掌握程度非常高的DBA，这块应该算成本，不算投入。

6）后续扩容：这个跟软件授权差不多，看怎么谈，最好要在初期就要明确，各家差别也比较大。

基本分布式数据库的投入肯定是要低于集中式数据库的，互联网企业早期去O的重要原因就是成本投入驱动。当然，金融行业国产化进程会越来越快，安全自主可控越来越重要。

@eximbank 某金融企业 系统架构师：

这个问题不能就数据本身来回答，一定是围绕应用生命周期来汇总汇总回答；要不然就会偏颇。数据库、X86、信创或开源等，都是为了企业等业务战略，业务周期性、整体整体性投入，比如比如资产生命周期、空间、电力、人力、研发、运维等诸多诸多IT投入，按照时间不同阶段进行综合对比才算科学。粗旷的描述，至少至少不够严谨，也不能最为决策依据。

Q7、分布式数据库效率和性能如何提升和优化？有哪些具体方法？

【问题描述】对于多表关联的效率低的问题，有哪些方法可以优化；月季度结息等批量业务如何设计；另外，对于一些热点账户如何进行优化提升效率等等。

@lulihuan1987 张家港行 数据库管理员：

（1）分布式数据库数据是分布在多个节点的，当需要进行多表关联时，往往很难避免数据在节点间流动，导致查询效率较低。建议从以下几个方面进行优化：

1）合理进行表设计，尽量避免跨节点表关联：

a) 对所有的库表进行重新设计，合理设置分区键，分区键也是表的字段，表根据分区键字段将数据打散在各个节点，因此分区键设置时要从全局和交易局综合考虑，将交易中经常用来关联的字段设置为分区键，比如客户账户。

b) 对于更新评论较少且数据量不大的表，建议设置成全局表，即每个数据节点保存该表的全量数据，这样分片表和全局表进行关联时，也不会有节点间数据流动。

2）对于跨节点关联的改造：

a)对此类SQL进行拆分，拆成多个单表SQL或者节点内关联SQL。无法拆分过程中可以考虑使用临时表（中间表），将中间数据放到临时表，中间表进行承上启下的关联。

b)对交易业务逻辑进行重新设计，改造复杂 SQL 。

总的就是交易中必须避免节点间数据的流动，以免影响系统并发性能和扩展性能。

（2）月季度结息逐笔进行，根据一定的规则进行分组，并发执行，然后，优化好每笔结息事务，进行SQL优化，比如优化跨节点多表关联，确保可以通过高并发实现快速结息，同时保证后续的可扩展性，较好适配分布式数据库。

（3）对于热点账户，建议设置为异步模式，即先记账，定时扣款，减少互锁，提升性能；为防止账务风险，可以设定阈值，账户余额低于阈值时，开启同步模式，高于阈值时开启异步模式。

Q8、分布式数据库事务管理器是如何满足核心业务系统需求的？

【问题描述】众所周知，分布式数据库虽然在资源扩展与高并发性能方面有着独特的优势，但是不同行业核心业务系统对于事务性要求也是不同的，分布式数据库的事务管理器是如何满足核心业务不同的事务性需求的？

@lulihuan1987 张家港行 数据库管理员：

以金融行业来说，对分布式数据库分布式事务要求应该是非常高的，不同数据库实现分布式事务的机制有所不同，以我行采用的TDSQL数据库来说，分布式事务主要实现方式如下：

1）分布式事务是二阶段提交，组件proxy是事务协调者，启动事务时分别在每个分片节点上启动子事务，

在prepare commit时，proxy向gtid_log_t中记全局事务日志，全局事务日志保存在gtid_log_t（分片表），（通过交易的第一条SQL访问的SET记录全局事务日志）；

2）prepare commit完成后，进入COMMIT阶段。

3）如果prepare commit 过程中发生异常时，各个set上的子事务回退。

4）进入COMMIT阶段，在COMMIT阶段的问题不会回退，会重复自动retry 提交，如果自动retry 提交超时，会在控制台出现一个事务提交报错，需要手工提交。

5）回退或retry提交都是依赖全局事务日志gtid_log_t。。全局事务日志保存在gtid_log_t分片表，依赖TDSQL一主多备确保零丢失。

6）主备之间的binlog传输是在prepare commit阶段完成。这样进入commit阶段，如果主节点故障，也不影响备节点retry提交事务。

7）全局一致性读，依靠TDSQL全局MC的组件，一个基于时间擢的全局序列，确保全局事务ID单调递增和唯一。

我们通常会通过破坏性测试来测试其分布式事务可靠性，例如一个表由ID和value组成，分布式事务是ID1+1，ID2+3，ID3+7，ID4-2，ID5-4，ID6-5，并发开启分布式事务，外部程序一定时间不断杀数据库DB进程，导致数据库故障主备切换，验证程序则不断地查分布式数据库整表sum(value)，查到的数值不会变化。

Q9、核心业务系统采用哪种分布式数据库更好一些？

@lulihuan1987 张家港行 数据库管理员：

目前国内分布式数据库产品很多，需求量也在逐步增加，随着XC工程推动，未来3年内会有越来越多的分布式数据库将适配到金融行业的关键核心业务系统，实施案例多效果好成熟度高的分布式数据库会脱引而出，所以银行核心系统选择一个实力和潜力强的数据库尤为重要，所以选择的时候首先看厂商的背景和实力；第二，看产品应用情况，重点互联网、金融领域；第三，调研核心案例情况；第四，产品的发展演进路线和潜力；第五，根据以上几点选取产品进行现场POC测试，性能测试（数据加载、查询性能、事务性能），功能测试（易开发、易运维以及安全性）；

选定数据库后，核心应用和数据库的适配实施必然会有一定适配改造，这部分需要提前评估；

最后，核心系统非常重要，必须控制实施风险，必要时需要配置后备库，确保万无一。

@一力搜索 股份制银行 数据库架构师：

看你的分布式数据库产品。我们核心交易系统在用，一个多亿用户。不过定制化优化必不可少，监控运维系统得跟上。

Q10、迁移到MySQL性能上是否有保证，是否有验证过的可行方案可供参考？

【问题描述】目前我们的数据量大概是150张表，其中大概30张表达到千万级，并且涉及DML和查询并行，Oracle中我们使用索引+表分区来保证性能，迁移到MySQL性能上是否有保证，是否有验证过的可行方案可供参考？

@lulihuan1987 张家港行 数据库管理员：

从Oracle迁移到MySQL的话，同档软硬件条件情况下，无并发基准查询速度肯定是下降的，毕竟Oracle的查询优化器做的非常好；

如果是迁移到基于MySQL的分布式数据库，通过合理的适配改造，无并发基准查询的速度可能也没有Oracle快的，而分布式数据库易扩展特性，通过增加节点提升性能，整体性能是完全可以超过原Oracle的。

所以您的性能通过合理的适配改造是可以保证的。

@一力搜索 股份制银行 数据库架构师：

你这些数据量和表数量都挺小的。MySQL同样也有表分区的，往深里说，改innodb页大小也可以让b+深度不增加。

Q11、分布式数据库品牌多，如何选型？

【问题描述】分布式数据库品牌多，好多都是基于开源产品改装而来，未经过大规模使用验证，现有的长期稳定使用关系数据库，可以了通过分库分表，通过mycat等中间件增强分布式性能 分布式数据库优势和稳定性能全面超越吗？选型又主要考量哪些方面？

@lulihuan1987 张家港行 数据库管理员：

目前用于银行核心交易系统的分布式数据库主要有基于开源数据库内核的数据库（如TDSQL、GoldenDB）和原生纯自研数据库（如OceanBase），像TDSQL、GoldenDB已经有银行核心系统成功案例，像OceanBase、TDSQL都是经过互联网海量数据流量验证的，所以内核成熟度都是能满足核心业务系统业务连续性要求的。

基于中间件分库分表实现分布式的数据库也可实现分布式架构，通过合理的架构设计和业务设计，性能非常卓越的，但是其对业务的侵入性比较强，对架构设计和业务设计要求较高，无论是分库分表还是分片式分布式数据库，在银行核心系统都有应用案例，笔者认为只要设计得好，自身开发和运维能力能跟上，符合自身技术发展路线，两种数据库均是可选项。

核心分片式分布式数据库选型时可以考虑几点：

1）产品行业应用情况，核心应用情况

2）厂商实施团队情况，对该项目的重视情况和资源投入情况

3）产品POC测试情况，例如基本技术指标、sysbench压力测试、TPCC测试情况、自动化运维管理工具、异构数据库同步工具、产品手册完善情况等

4）建设和运维成本投入，后续扩容投入

5）是否满足XC要求

6）行内领导的支持

@Ocean_ it 华为 技术咨询顾问：

在讨论如何做数据库选型之前，我们必须了解几个问题，否则选型这两个字就无从谈起。第一个问题是你的需求是什么？你用数据库来干什么，用到了数据库的哪些特殊的功能？你的业务需求是什么？只有真正的回答好了这些问题，真正的了解了你的应用，这样你才能有更准确的选择。了解了这一切后，你可能了解到你的数据库就是用来存放数据的，每天插入几百万条数据，删除几万条数据，修改十来万条数据，另外就是对一些千万级的表做一些统计查询。这样的系统恐怕一台虚拟机上的MYSQL或者PG数据库就完全胜任了。

第二个问题是你需要了解硬件的真实能力，一台两路服务器的配置是什么样的，处理能力可以达到多少，一块SATA SSD盘的IO性能是一块普通HDD的多少倍？万兆网络上能跑多少流量，IO延时大概是多少？可能很多DBA干了一辈子都对这些数据不甚了解。只有了解了这些问题，才不会问出“我的数据库每天要新增上千万条记录，得多少个节点的分布式数据库才处理的过来？”这样的问题。在数据库领域，能用硬件解决的问题，尽可能让硬件来解决，和能够提供的性能来对比，多花的这点钱简直不要太值了。

第三个问题是你的企业的IT基础架构与应用架构的发展策略是什么，今后企业是走云平台还是容器化为主的技术路线？集中式的大型数据库还是分散的小型数据库？业务规模的发展是什么样的？这些都会对你的数据库选型产生重要的影响。适合你的企业的IT发展是数据库选择前最重要的需要分析的问题之一，只有回答好了这个问题，后面的数据库选型才真正有意义。

第四个问题是了解你的备选数据库的基本特性，这些数据库的架构是什么样的，技术特征如何，技术指标与参数如何，与Oracle的兼容性如何等等。在回答第四个问题的时候，我们需要从下面的几个方面去考虑。这些选择数据库的选择分析并不一定十分科学，只是这些年工作经验的总结，算是一家之言，仅供大家参考。

•通用性与适用性

•部署便捷性

•使用与维护成本

•高可用/备份/容灾等方案的完整性以及实用性

•接口完整性

•工具完整性

•生态完整性

•与主流商用数据库的兼容性

•原厂服务能力与第三方服务能力

•原厂的规模与企业稳定性

•市场与行业应用效果与销售规模

•DB ENGINE流行度排名

Q12、企业引入分布式数据库的安全问题？

【问题描述】众所周知，分布式数据库无论是newsql型（tidb，oceanbase），还是传统的mysql分片式（TDSQL、OceanBase），安全问题都很难完美解决。不同于Oracle等传统商业数据库，分布式数据库厂商将大量的精力用于功能的完善，对安全问题往往淡化，比如数据的分散部署难以加密、备份的明文等等。请问，如何解决这个问题？

@lulihuan1987 张家港行 数据库管理员：

数据库安全问题选型时也要考虑

例如产品是否符合国家相关信息安全标准，是否通过等保X级（至少3级），以及其他国家和国际认证，选型时同时让厂商提供以下几个方面的支持和实现情况：

（1）ssl连接加密

（2）数据透明加密，密文物理存储；

（3）ip黑白名单，允许白名单的客户端访问；

（4）sql防火墙，阻止不符合要求的sql访问，以及sql注入等

（5）安全审计

（6）其他的内核级的安全

Q13、如何应对外围系统到核心系统取数的问题？

【问题描述】核心系统不是独立的系统，会与外围系统进行大量的数据交互，例如数仓卸数和实时数仓，如何给这些系统供数，如何既能保证数据实效性又能对不影响核心系统正常运行？

@lulihuan1987 张家港行 数据库管理员：

核心系统与外围系统进行数据交互，根据场景，可以通过如下方案解决：

1）T+1应用:卸数，通常需要取多个表的全量数据，取数量大，时间长，建议通过只读账户直接从备库取数。

2）实时应用：例如实时数仓，需要实时取数，可以通过数据准实时同步到消息队列（例如kafka）方式与大数据实时计算平台对接，同时不影响生产，建议从备机同步。

@alphaaries 华为 技术总监：

1. 传统意义上的核心系统与外围系统的数据交互有，但不应该太多。从本质上来讲，核心系统主要的任务不应该是交易，而更多的应该是批量、清算等。

2. 数仓与包括核心系统在内的交易系统进行交互时，主要是通过卸数+导入的过程来实现，可以考虑建设ODS数据平台，各系统将数据统一卸载到ODS平台，再导入数仓。

3. 实时数仓可以通过读写分离的方式来减少性能影响。

@一力搜索 股份制银行 数据库架构师：

这些场景完全可以读写分离。备库做就行，脚本自动寻找备库。

Q14、分布式数据库核心难点之乐观锁适配问题探讨？

【问题描述】在金融领域，绝大多数的银行业应用设计都是基于传统单机关系型数据库，没有从整体应用架构考虑与第三代分布式数据库进行适配，尤其在银行核心系统应用第三代分布式数据库案例甚少，没有可复制的成功经验可以借鉴，从数据库自身机制和核心系统应用等方面，面临核心难点之乐观锁适配问题：

乐观锁在事前对表不会加锁，只在提交的时候比对提交版本号，不能保证每笔交易都能提交成功，在高并发的金融记账业务场景里，会造成大量的交易超时，出现用户短款现象，不能满足银行业务连续性和数据“强一致性”的要求。

大家针对这个核心难点问题有何解？有什么比较好的方法和经验吗？欢迎谈谈！

@wanglaye 某大型金融机构 项目经理：

不知道“金融记账业务”是否指的是账务核心系统？我们对于账务核心没有做分布式数据库改造，对于记账来说，一致性放在第一位。我们在选择哪些系统使用分布式数据库时，主要根据系统交易量是否具有明显波峰波谷特点、是否对可用性要求很高、数据增长是否非常快速这几个方面。分布式数据库的弹性扩缩容、高可用机制可以更好适配这些场景，提高行内资源使用率，保证重要时期系统稳定性。主要是面向网络交易的系统在用。你说的乐观锁无法做到强一致性的，所以这块是很难做到的，除非能牺牲少量一致性原则，否则……

@lulihuan1987 张家港行 数据库管理员：

乐观锁和悲观锁应用的场景不同，悲观锁更注重数据安全，更新数据前，读取数据时先利用数据库的锁机制将该数据行进行锁定，直到事务提交才释放，强调安全性，持有锁时间长，并发效率在某些场景效率不高；

乐观锁在最后提交的时候才去比较数据版本号，锁持有时间短，并发效率高，但是如果出现大量的数据冲突，会导致大量交易失败，所以乐观锁应用的前提应该是该业务场景下数据冲突的概率很小。

所以还是要结合业务场景和特点，在安全性保证的前提下，考虑使用乐观锁还是悲观锁，我们行大部分业务场景都是采用的悲观行锁，通过其他途径去提升并发效率，比如大事务改小事务，事务中锁尽量往后放等。

分布式数据库比集中式数据库有个全局一致性读的特殊性，现在分布式数据库通过增加全局时间戳组件实现了全局一致性读，能满足数据“强一致性”的要求。

@johncyj 农信：

乐观锁确实会出现成功率不高的问题，那就换悲观锁呗，那么带来了新的问题，多个会话同时更新一条数据，势必会带来争抢，tps也上不去，不如牺牲一点点性能，采用分而治之的思想，将账户按一定的规则拆分一下，成为多个子账户，会话按照一定的规则去访问子账户，这样就降低了争抢；不过...现在的分布式数据库还存在这个情况？

@t3573393 兴业数金 研发工程师：

按照互联网的内存数据库方案能极大的提高性能，参考OceanBase的内存是最新的，增量刷新数据到盘里面。由于内存更新极快完全可以通过队列串行的方式修改一条记录。

Q15、分布式数据库跟其他数据库之间的数据同步问题？

【问题描述】当前分布式数据库方兴未艾，进步很快，但是其生态仍需要不断完善，比如分布式数据库跟传统的数据库，或者其他的分布式数据库之间的数据同步问题，目前市场上支持这种异构数据库的t数据同步工具还很稀缺，即使有，也是漏洞百出，远不如传统数据库完善。

@lulihuan1987 张家港行 数据库管理员：

我行当初上线时采用的分布式数据库和集中式数据库数据准实时同步的方案，这个方案是更加数据库提供的同步工具设计的，当然同步工具也做了适配改造。具体的可以参见文章 《银行核心系统采用分布式数据库的探索》

像TDSQL、OceanBase等数据库都有对应的异构同步工具，而且也有案例，使用上可能没OGG之类的成熟，但是总体来说还是可用的，从可用到好用，国产数据库未来可期。