分布式数据库助力金融行业数字化转型

1、腾讯云分布式数据库助力金融行业加速数字化转型技术创新，变革未来1金融行业的转型2金融应用分布式实践目录CONTENTS目前国内大中型银行主要以国外厂商提供的大型主机和数据库解决方 案来进行系统构建。由于近年来金融业务量的不断增长，以及银行数 字化转型成为必然趋势。目前以国外大型主机和数据库为核心的架构 已无法满足大规模交易和数据处理的需求。一方面：性能无法满足业务不断激增的处理需求，存在系统过载风险； 另一方面：本身价格比较昂贵，维护成本居高不下。以手机银行、网上理财、互联网保险等为代表的金融业务创新 快速发展，推动新技术正以前所未有的速度与力度发生深层次 变革。这些技术发展，对金融服务模式带

2、来重大影响，使得金融行业 向数字化、分布式转型成为必然趋势，金融业务创新与科技创 新正在相互促进，重塑金融行业系统能力。月活用户达10.82亿 交易笔数超过4600亿笔7000万微粒预授信3800万开通用户6000亿累计放款额200亿账户（含合作伙伴）500亿+日均请求平均5毫秒响应微信支付图webank微粒贷微车贷金融行业现状现在：过去：核心系统对外国厂商依赖度超过90%硬件：小机、大机软件：自主研发+国外厂商技术支持/咨询 技术：技术架构与硬件耦合性强核心系统硬件、软件100%XXX硬件：虚拟化X86分布式服务器/云容器 软件： XXX +国内厂商技术支持/咨询技术： XXX +分布式数据

3、库+微服务架构信息技术创新的大势所趋多种架构长期共存Shared-Nothing&Shared-storge多种技术栈卡位竞争兼容MySQL&Oracle&PG厂商的互相PKDBDBDBDBDiskDiskDiskDisk负载均衡器Shared-NothingDB Engine (master)CynosFSBlock APIDB Engine (slave)CynosFSBlock APIDB Engine (slave)CynosFSBlock APISeg SegStorage ServiceSeg SegSeg SegStorage ServiceSeg SegSeg SegStora

4、ge ServiceSeg SegRWROROContinuous BackupCold Backup StorageWallog Sync Wallog Sync storage cluster managerdb instance managerPool分布式数据库领域的百家争鸣质量可靠团队建设持续演进服务能力在国内主要地市建立健全分销 体系、培训能力、服务团队。 不仅包括数据库， 更能覆盖金 融全技术栈的服务能力。背靠优质平台或生态， 产品可 以持续演进发展； 厂商拥有一 流的研发团队和长期投入。0201建立能用， 会用， 用好国产数 据库的人才队伍； 形成一支具 备高水平维护能力的队伍

5、。0403产品应该成熟可靠， 经过大规 模业务持续验证， 拥有较多的 客户案例和I S V 集成经历。金融客户应该如何选择分布式数据库腾讯云分布式数据库解决方案 自有业务打磨 产研结合 产用结合TDSQL TBASETencent Cloud Enterprise月活用户达10.82亿交易笔数超过4600亿笔7000万微粒预授信3800万开通用户6000亿累计放款额200亿账户（含合作伙伴）500亿+日均请求平均5毫秒响应微信支付图微粒微1金融行业的转型2金融应用分布式实践目录CONTENTS金融客户主机下移引起的思考其他典型场景分布式数据库如何适配分析与恢复事务实时强一致数据冷热分布数据弹性

6、如何选择分布式技术栈如何设计信息技术创新节奏 如何使用分布式数据库新老系统的切换分布式的扩展容灾方案如何对国产数据库进行运维分布式技术栈的选择：对主流方向都有布局和应用微信支付等“ 互联网” 通用方案：已经形成可铺开的经验和方法论（ 书籍、文档或代码等）已有大量的应用代码、SQL改造案例成熟的数据迁移、同步工具社区、高校、培训机构大量相关课 程。互联网厂商十余年来的人才输出。微信支付商户系统的“ 互联网” 通用 方案； 常见于基于Postgre SQL或国内 自研Oracle兼容类数据库， HTAP数据 库等复用Oracle现有SQL，一定程度降低ISV改造成本。复用PostgreSQL社区的

7、经验和方法论。数据迁移、同步相对方案简单。成熟分布式技术栈易于团队建设降低迁移门槛降低改造成本典型产品：腾讯TDSQL（MySQL技术栈），腾讯TBase（Oracle兼容技术栈）MySQLOracle兼容五年计划原则： 建立一支熟悉分布式数据库技术栈的技术团队。根据业务重要性， 分批分阶段改造业务系统。技术方案应在不影响宏观稳定， 确保业务与数据库磨合。该技术应该是可以复用或容易建立的。应该是在完全磨合好以后， 再全量切换。技术 团队分批 改造业务 磨合技术 复用全量 切换20182019 团队招聘与培养202020212022确定基于oracle+MySQL实现双技术栈 团队建设，并选择互

8、联网银行业务选 择开源MySQL方案打磨团队。（试点）核心系统改造团队对MySQL熟悉后，实现核心业务系统基于腾讯云TDSQL上线并开始运营新老系统并行剩余系统改造老业务系统不下线，数据保证实施同 步回老业务系统，如果新业务系统一 旦故障确保老系统可用。最终核心交易全量切换在运行一段时间后，确保新系统完全 稳定后，再封存老系统。技术创新节奏：某大型银行客户的主机下移“五年计划”化，问题攻坚监管机构专家评审2018.4-2018.5选型进行POC测试2018.5对腾讯TDSQL进 行深入测试2018.6-2018.7进一步探讨分布式 数据库的落地方案2018.8-2018.10中间业务系统及EC

9、IF系统 TDSQL配套改造并完成上 线2018.10-2019.1新核心适配性改造及 TDSQL优化升级和功能增 强2019.1-2019.7成立攻坚小组，进行 深入的验证，业务优2019.42019.5监管机构验证汇报，现场 验收，得到XXX认可2019.5决定使用TDSQL投产2019.5-2019.6扩大压测范围， 至500个交易2019.7生产机器性能论证2019.8项目投产初步验证可行性验证系统适配性全面验证2019.5-2019.6对集中式版本进 行2轮专题测试技术创新节奏：某银行客户传统核心业务系统改造过程数据层下移的拆分策略：水平拆分&垂直拆分SOA时代，按业务维度垂直拆分分

10、布式改造 数据水平拆分不是所有都需 要进行分布式 改造！拆分方案通常分为按客户维度拆分按分公司（法人）维度拆分按时间维度拆分其他数据层下移的拆分策略：水平拆分的主要方案直观需求为数据： 1TB单表： 千万级并发： 10K/s通用性 容量伸缩数据分片-1数据分片-1业务模块数据分片-n数据水平拆分策略：按客户维度进行拆分pn逻辑表物理表p 0p 1p 2hashp3数据特点客户规模较大客户无明显分布性单笔交易金额小、笔数多常见对私业务数据层水平拆分策略：按分公司（法人）维度进行拆分分公司1分公司3业务模块分公司2SET-1分公司4SET-2分公司1 分片a分公司1 分片b分公司1分片c数据特点业

11、务按分公司维度开展。交易/清算等以该维度展开不同分公司交易规模区别明显总部搭建业务系统和数据收口分公司总数少，但交易数量多分公司5分公司6SET-3vSET-1vSET-3分公司2 分片a分公司2 分片b分公司1 分片cvSET-2Group-SET-1vSET-1vSET-2Group-SET-2vSET-3Group-SET-3分布式计算层分布式计算层分布式计算层业务模块常规方案腾讯方案数据层下移的拆分策略：按时间维度进行拆分历史库DTS业务模块分布式计算层分布式计算层分布式计算层二级拆分 基于时间一级拆分数据特点业务按时间（年/月）分布不同时间区间交易规模差异较大（如 京东618）历史数

12、据规律性搬迁/删除常见于订单类业务分析库大数据第三方系统迁移需求沟通迁移开发& 测试迁移实施资源准备服务交割客户架构师 或ISV：腾讯技术人员：方案评审结果确认完全切割商用数据库腾讯分布式腾讯云数据库应用迁移服务工具服务数据迁移工具迁移评估方案设计改造建议优化建议数据验证工具迁移评估工具新老系统的切换：DTS-DBBridge数据验证工具迁移评估 报告新老同步或 双写助力用户现场保障实例概览，宏观把握全局全实例监控，轻松发现隐患帮助用户快速恢复业务7*24实时异常诊断SQL限流提供快速降级国产数据库的运维：DBBrain&分布式数据库管理系统分布式多活多SET化扩展容灾方案传统两地三中心的痛点

13、1、容灾需要人工干预2、备机房常态下无流量，利用率较低。3、切换时无法确保备机房100%可靠，检查和决策时 间长。4、单机房系统容量有限，A业务 SET2A业务 SET4B业务 SET6IDC 1综合SET1SET2 DBSET4 DBSET6 DBSET1 DB(主)综合SET1B业务 SET7A业务 SET6IDC 2A业务 SET6SET1 DB(从)SET4 DBSET6 DBSET1 DB(主)A业务B业务业务网关业务网关A Relay ProxyB Relay ProxyIDC 3第三方SET1第三方SE2公共SET(主)公共SET(备)强同步SET1 DB(从)数据双向同步典型场

14、景：异常场景的恢复&全局一致性数据分析主实例交易系统分析程序分布式事务补偿分析实例恢复到23:00对账系统优势：数据库默认可回档到 X天以内任意时间；如果对 账错误，可以重新发起。 劣势：特殊异常场景下，恢 复时间可能较长。方案一方案二主实例分析快照交易系统分析程序GTS绝对时间戳 数据多版本控制交易数据全局一致性快照恢复到专用分析实例中清算、结 算系统优势：快照理论上恢复时 间可控，快照更加精准。 劣势：全局一致性快照有 且只有一个，如果遇到对 账错误，需要综合方案一 处理。分析数据分析数据对账系统清算、结 算系统恢复的实例即可以用于分析，也可以用于异常情况下快速回退事务A:Balance

15、+= 5B:Balance -= 5prepar epreparecommitDB1DB21010155AB设置一致性标签：事务栅栏（transaction barrier）barriercommit1barrier1事务A:Balance += 5B:Balance -= 5prepar ecommitpreparecommitDB1DB21010155AB全局最大一致时间戳：GTS0100200300典型场景：分布式事务实时强一致事件中心小商户热group大商户热group小商户冷group大商户冷group连接池40w+商户账单查询 连接池容灾副本案例特征支持业务：商户交易订单写入、实时

16、查询、订单 退款等写入：事件中心通过消息队列写入，连接池实现进一步连接做连接收敛 查询：提供商户查询订单事务：依赖完整事务特性，数据一致性高 要求稳定性：2016年上线稳定运行至今多维度数据治理冷热存储分离，大小商户分离业务负载日交易量XXX亿+，月增长XXX读XXX w/min（ XXX /min峰值）， 写XXX w/min（ XXX /min峰值）容灾策略采用同城两中心三副本+周期冷备+WAL实时归档典型场景：渠道类业务冷热数据不均TBL_A(f1-分布列, f2)TBL_B(f1-分布列, f2)select * from tbl_a, tbl_b where tbl_a.f1 = tbl_b.f2;TBL_A.f1 = TBL_B.f2CNDN1TBL_A.f1 = TBL_B.f2DN2TBL_A.f1 = TBL_B.f2DN3TBL_A.f1 = TBL_B.f2节点级并行进 程 级 并 行典型场景：复杂SQL处理（跑批等）富途证券 基于TDSQL搭建整体分布式业务中台单日查询峰值超XXX亿次，单日每分钟读请求峰值超千万次典型场景：分布式弹性彻底解决数据一致性问题实现自动化运维 管理节省大量运维成本业务扩张更有弹 性更安全稳定大幅