分布式数据库TDSQL金融应用指南

2024 年 版权声明 ©2018-2024 腾讯云 版权所有 本文档著作权归腾讯云单独所有，未经腾讯云事先书面许可，任何主体不得以任何形式复制、修改、抄袭、传播全部或部分本文档内容。 商标声明 及其它腾讯云服务相关的商标均为腾讯云计算 ( 北京 ) 有限责任公司及其关联公司所有。本文档涉及的第三方主体的商标，依法由权利人所有。 服务声明 本文档中的信息，腾讯云不作明示、默示的保证。本文档基于现状编写，在本文档中的信息和意见，均可能会改变，恕不另行通知。 本文件未授予您任何腾讯产品的任何知识产权的法律权利。 目录$0/T&/TS 架构选型01 概述逻辑架构部署架构010204 资源评估02 资源评估方法配置建议1011 开发规范03 模型设计SQL 编写规范数据安全136871 运维及优化04 运维监控性能调优77118 设计与使用05 设计指南使用指南127127 实践案例06 银行业典型应用实践案例证券业典型应用实践案例保险业典型应用实践案例泛金融典型应用实践案例129134136137 01架构选型 （一）概述 1.TDSQL 特点 腾讯云分布式数据库 TDSQL 管理系统（以下简称 TDSQL）是腾讯打造的一款企业级数据库产品，其定位是基于互联网分布式架构的金融级数据库。TDSQL 全面兼容 MySQL、 PostgreSQL 语法，高度兼容 Oracle 语法，兼容 SQL2016 标准，支持 JSON、空间等数据类型；兼容常用的数据库客户端、中间件；可部署在国产硬件和操作系统，且 TDSQL 的分布式数据库集群可分配集中式数据库实例；支持完整的 DDL/DML/DCL 数据库定义、操作、控制语言，支持视图、存储过程等数据库高级特性；支持强一致分布式事务，分布式联合查询，数据强一致能力。TDSQL 具备 TDStore 敏态扩展、HTAP 混合负载能力、领先的分布式架构，支持自动水平拆分、不停机弹性扩展、强同步复制、超高性能等特性。TDSQL 可提供公有云和专有云部署形态，支持企业级的数据安全能力，支持专有云集群扩展能力。同时，TDSQL 提供智能 DBA、自动化运营、监控告警等配套设施，为用户提供完整的分布式数据库解决方案。TDSQL已广泛服务腾讯集团内部，以及金融、政务、社交、电商、交通、游戏等行业的 50 多万家用户。 2. 应用场景 （1）银行业应用场景 国内商业银行常见的业务系统主要包括 : 渠道类系统、交易类系统和管理类系统。其中，渠道类和交易类系统多具有以下特点：一是业务数据规模巨大，核心交易数据更新极为频繁，交易热点集中；二是业务并发量大，除了传统的 ATM 和柜面交易，还有线上的网上银行、手机银行，以及各类三方支付等系统带动的交易；三是数据重要性高，安全等级要求高；四是业务可用性和可靠性要求高，相关建设成本高。 所以，银行业对分布式数据库的需求可大致概括如下：首先支持业务系统安全稳定的运行是重中之重；其次是可承载多类型的海量数据，同时还可处理高并发的事务，可支持弹性扩容；再次是开发和运维成本要相对可控等。 （2）证券业应用场景 证券业务系统的特性主要包括如下几个方面：一是高并发，证券业务系统需要处理大量的交易请求，因此需要具备高并发处理能力。二是实时性，证券交易是实时的，系统需要能够快速响应并处理交易请求。三是安全性，证券业务涉及到大量的资金交易，因此系统的安全性是非常重要的。四是稳定性，证券业务系统需要保证交易时段不间断运行，不能出现任何故障。 对于分布式数据库的需求，证券业主要有以下几点：一是高可用，分布式数据库需要保证在任何情况下都能提供服务，不能因为单点故障而影响整个系统的运行。二是高性能，分布式数据库需要能够快速处理大量的数据请求，满足证券业务的实时性需求。三是数据一致性，分布式数据库需要保证数据的一致性，确保所有的交易数据都是准确的。四是易扩展，随着业务的发展，分布式数据库需要能够方便的进行扩展，满足业务的发展需求。 （3）保险业应用场景 保险业务系统具有如下特点：一是业务系统相对集中，但是业务逻辑中心分散，按省或按区域具有差异性。二是互联网渠道保险占比逐年上升，小额且频次高，数据库负载呈现爆发式增长。三是活跃数据存储周期长，如寿险、健康险通常是按若干年为周期计算，对于数据一致性、数据可靠性、历史数据校验的需求极高。四是渠道系统、周边支持系统与核心系统数据交互较多，保险公司往往存在复杂的数据同步逻辑。 保险业对分布式数据库的需求包括：扩展性要求高、数据实时性需求强、满足多业务隔离等。 （4）泛金融业应用场景 泛金融业包含丰富多样的金融业态，例如消费金融、支付、财务公司等等。其中财务公司的业务系统以加强企业集团资金集中管理和提高企业集团资金使用效率为目的，需要进行资金异常监督预警、资金数据穿透分析，对成员单位的资金情况实时掌握，及时防控风险。 财务公司对分布式数据库的需求包括：国产自主可控、高性能数据存储与管理、实时数据处理与查询、灵活扩展、便捷运维等。 （二）逻辑架构 1. 系统架构设计 TDSQL 系统架构设计的核心思路是：标准化、模块化。例如 TDSQL 的模块设计是充分解耦的，彼此之间通过接口衔接，用户可以自行组装或用自己现有模块替换；又比如在设计部署架构时，用户可在成本（自身数据中心建设情况）、业务数据安全可靠性、业务可用性三者之间做不同的平衡选择，可以做到 N 地 N 中心的部署，如金融行业常见的同城双中心、同城三中心、两地三中心、两地四中心等高可用容灾部署架构，数据副本亦可做到一主 N 备（N ≥ 0）；甚至在设计读写分离机制时，只读账户可根据主备延迟状态，选择是从备机读取，还是从主机读取，还是直接返回错误；类似这样的设计贯穿 TDSQL 的整个研发过程，给予用户足够的灵活性和选择权。 TDSQL 基础系统架构图如下： 数据节点：数据库模块，实际数据存储节点，主备方式部署。 计算节点：Proxy，也叫 sql 引擎，位于接入层，承接应用数据请求，主要负责账号鉴权、管理连接、SQL 解析、路由转发、分布式事务支持、数据聚合、读写分离等功能。本身无状态，没有主备之分，一般采用多节点部署分担请求压力。 旁路模块：Agent 为无状态部署，负责监控 DB 的存活状态，执行切换、备份、分布式事务容灾等任务。 决策集群：Zookeeper 高可用和一致性集群，提供配置维护、选举决策、路由同步等功能，并能支撑数据库节点组的创建、删除、替换等工作。 调度模块：Manager/Scheduler 可调度集群系统帮助用户自动调度和运行各种类型的作业。如数据库备份、收集监控、生成各种报表、主备切换、扩缩容、资源管理或者执行业务流程等。 接口模块：OSS 负责接收用户的请求，使用 HTTP 的 POST 协议，主要实现端口监听，解析 POST body，根据用户请求调用对应的流程，封装获取的结果，返回给用户。接口作为 TDSQL 后台和 web 前台的桥梁，通过可视化管理台操纵 TDSQL。 赤兔管理台：TDSQL 可视化运营管理平台，从管理员视角，提供 TDSQL 的全部运维功能，可管理 TDSQL 集群的物理资源、调度决策系统、备份与恢复系统、可用区管理、实例管理、智能性能分析与监控告警等。 赤兔通过调用 OSS 接口进行任务下发到 ZK 组件进行任务节点创建，由 Scheduler 组件进行监听，当监听到相关任务节点后，调用Manager 组件进行具体任务执行，并更新 ZK 任务节点，赤兔运维平台通过 OSS 查看任务进度状态。 SET 机制：TDSQL 所有的高可用机制均是在 SET 之内实现，每个 SET 之内多个数据节点（1 主 N 备），主备之间可以是强同步复制机制，也可以是异步复制机制。在主机出现故障的情况下，在调度模块的协助下，基于数据一致性原则和同机房优先等主备切换策略，将最符合要求的备机按照规定流程提升为主机，快速恢复业务，确保数据零丢失，全程无需人工干预。 水平扩容机制：分布式实例对外呈现为一个完整的逻辑实例，后端数据实际分布在若干 SET 分片上（独立的物理节点）组成。逻辑实例屏蔽了物理层实际存储规则，业务无需关心数据层如何存储，也无需在业务代码中集成拆分方案或再购买中间件，只需要像使用集中式（单机）数据库一样使用即可。同时支持实时在线扩容，扩容过程对业务完全透明，无需业务停机，扩容时仅部分 Set 分片存在秒级只读（只读是在做数据校验），整个集群不会受影响。 2. 产品架构 产品架构图如下： （1）系统可靠性 各种异常灾难情况下，例如主机故障、网络故障、数据中心故障等，都能确保系统安全可靠。 （2）数据一致性 基于数据多副本主备之间的强同步方式，系统保证在各种异常灾难情况下的数据零丢失、数据节点之间自动切换，并可根据用户不同的数据可靠性级别，快速恢复可用，把不可用时长降至最低。 （3）高性能 对 MySQL 深度优化发展而来的 TXSQL 内核，使得在主备网络延迟 3ms 的情况下，能做到跨 IDC 强同步性能相较于异步同步零损耗。 （4）水平扩展性 提供 Auto Sharding 机制，可实现实时在线无缝扩容，确保集群性能和容量呈线性增长；同时提供健壮的分布式事务机制，在性能损耗极低 ( 损耗 15%) 的情况下，大大降低了传统业务迁移分布式架构的难度。 （5）自动化运营 提供完善的运营体系，自动化运营发布平台，机器资源自动管理，智能监控平台及展示，数据库智能诊断等。 （6）配套设施 TDSQL 还提供 DBbridge 数据库同步工具、DBBrain 数据库智能管家等配套系统，供用户选择。 （三）部署架构 1. 部署架构 基于成本因素考虑，用户可根据自身业务数据的容灾要求，以及数据中心分布情况，选择不同的部署方案。TDSQL 可以针对用户不同的数据中心架构，在数据可靠性与可用性上做出权衡，做到灵活部署。 数据库节点配置： 1）数据库生产部署：TDSQL 实例，一主五从（2+2+2，三个中心分别 2 副本），同中心异步跨中心强同步，可退化模式 (RTO 优先 )。 2）数据库容灾部署：TDSQL 实例，一主一从，强同步可退化（容灾数据库通过 DCN 和生产数据库同步）。 1）数据库生产部署：ZK 三中心，5 个节点（2+2+1）配置部署，其他组件三中心各 1 个节点配置部署。 2）数据库容灾部署：ZK 一中心，3 个节点配置部署；其他组件一中心，2 个节点配置部署。 数据库节点配置： 1）数据库生产部署：TDSQL 实例，一主三从（2+2，两个中心分别 2 副本），同中心异步跨中心强同步，可退化模式 (RTO 优先 )。 2）数据库容灾部署：TDSQL 实例，一主一从，强同步可退化（容灾数据库通过 DCN 和生产数据库同步）。 1）数据库生产部署：ZK 三中心，5 个节点（2+2+1）配置部署，其他组件两中心各 1 个节点配置部署。 2）数据库容灾部署：ZK 一中心，3 个节点配置部署；其他组件一中心，2 个节点配置部署。 数据库节点配置： 1）数据库生产部署：TDSQL 实例，一主两从，强同步，可退化模式 (RTO 优先 )。 2）数据库容灾部署：TDSQL 实例，一主一从，强同步可退化（容灾数据库通过 DCN 和生产数据库同步）。管理节点配置： 1）数据库生产部署：ZK 一中心，3 个节点配置部署；其他组件一中心，2 个节点配置部署。 2）数据库容灾部署：ZK 一中心，3 个节点配置部署；其他组件一中心，2 个节点配置部署。 数据库节点配置： 1）数据库生产部署：TDSQL 实例，一主三从（2+2，两个中心分别 2 副本），同中心异步跨中心强同步，可退化模式 (RTO 优先 ) 。管理节点配置： 1）数据库生产部署：ZK 三中心，5 个节点（2+2+1）配置部署；其他组件两中