核心|金融企业选择与应用分布式数据库的7个核心问题( 三 ) mysql|苏强|分布式数据库|选择

文章插图
第二种是按分公司（法人）维度拆分：如上图所示，主要面向集团，其业务是基于分公司维度展开的，主要有几个特点——业务按分公司维度展开；交易/清算等以该维度展开；不同分公司交易规模区分明显；总部搭建业务系统和数据收口；分公司总数少但交易数量多。所以腾讯提供了一种叫虚拟组的能力，可以在分公司分布的基础上再进行拆分，帮助用户去提升。比如一个发展比较快的东南亚分公司，可能原来只需要一个小的分片，两年后爆发式增长就可以基于这种架构进行快速无缝的扩展。

文章插图
第三种是按时间维度拆分：如上图所示，通常是订单类的系统，而且按时间维度会涉及到大促时期呈峰值增长的问题。这种场景下，腾讯的产品可以提供一种二级分区的能力，可以按照时间分区，这就意味着无论归到历史库也好还是这一时间阶段交易规模比较大也好，都可以均衡地负载性能。
4、新老系统的切换：DTS-DBBridge

文章插图
接下来就会涉及到研发，一旦涉及到研发就要考虑整个业务系统迁移的流程。这个流程从最开始的业务沟通，腾讯就可以开始介入，腾讯的技术人员可以通过我们成熟的迁移工具DBBridge输出对业务系统迁移的评估报告，同时配合开发人员进行业务系统改造、实施、新老系统的并行上线以及到最后的切换，整个服务体系都可以形成一个闭环。
5、国产数据库的运维：DBBrain&分布式数据库管理系统

文章插图
迁移完成后就涉及到如何管理数据库，这里涉及到我们另一个方案DBBrain，它能够帮助用户从全局角度分析分布式数据库运行的情况，其中积累了腾讯海量的运维经验。
6、分布式多活多SET化扩展容灾方案
运维起来以后，随着运行一年到两年，某些核心就要开始考虑是否要符合监管的要求，是否要做两地三中心和容灾，甚至随着金融业务呈爆发式发展，原有的机房已经不能满足需求，需要换多机房方案。

文章插图
传统的两地三中心容灾方案，从金融科技发展角度会呈现出一些小问题，比如容灾需要人工干预，当真的面临事故时，是否敢做切换的决策？实际上很多金融IT从业者都不敢打包票。另外就是备机房常态下无流量，利用率较低，所以现在发展出多活的容灾方案，简单来说就是把业务系统通过一层网关进行一个按SET的划分，每一个SET下面都对应一套数据库，这个数据库既可以是集中式也可以是分布式。腾讯主流金融方案，都是使用多SET的模型。
SET的主从之间是采用数据库的强同步，SET与SET之间同类业务采用数据同步模型，因为上层的SET做了业务拆分，所以两个SET组之间的数据是不冲突的，可以互相进行同步。这类架构目前也在国内的某头部保险公司，同样是腾讯云的客户，已经试验了两地四中心的架构，到目前为止已经稳定运行超过9个月，单个SET能承载的理论容量是10TB，TPS是5000以上，而且性能可以基于SET化的分布式扩展往上加，所以SET化可以扩展的能力是很强的。
7、典型场景
腾讯的产品还有哪些场景真正面向金融行业？下面给大家列举几个典型场景。
1）异常场景的恢复&全局一致性数据分析

文章插图
第一种是异常场景的恢复和全局一致性数据分析，这个场景的功能和模型是差不多的，只是应用场景不一样。举个简单的例子，到年终结算的时候我需要2020年凌晨零点整的全年全部数据的一致性快照，可以有两种方式，第一种是生成一个新的实例，第二种是生成一个新的快照。这里会存在一个问题，因为分布式情况下服务器的系统时钟不一定一致，所以如图中上者需要进行分布式的补查，下者需要一个GTS绝对时间戳来保证数据的准确。
2）分布式事务实时强一致

文章插图
第二种是分布式事务实时强一致的能力，举个例子，假设我有五张银行卡，因为我要还房贷所以钱从这些卡之间转来转去。这时我媳妇正好在我转账时来查账，就会有两种结果：第一，我媳妇过十分钟后来查账，她查询到的就是我转账后的余额情况，这种叫最终一致性；第二，我媳妇在我转账过程中就来查账，这时就叫实时一致性。实时一致性就是要保证在交易过程中，即时随时查账都能得到最准确的结果，这也是我们数据库当前能够支持的一种能力。