TiDB 在立刻消费金融核心帐务系统归档及跑批业务下的实践

做者介绍：

康文权，立刻消费金融总帐高级研发工程师。

李银龙，原腾讯云运维工程师，立刻消费金融容器云 TiDB 负责人，西南区 TUG Leader。

背景介绍

立刻消费金融于 2015 年 6 月营业，截止到 2020 年 1 月，历经 4 年多风雨，总注册用户数 8000 万，活跃用户数 2500 万，累计放贷 2900 多亿元人民币。公司于 2018 年 6 月增资到 40 亿，成为内资第一大的消费金融公司。

在业务爆发式增加的 4 年多里，立刻消费金融的数据库经历了从单表数十 GB 到数百 GB 的过程，单表的数据量正在往 TB 级别演进。基于数据量的升级变迁，咱们的数据库也经历了 2 次架构迭代，并在探索

第三代数据库架构：

• 第一代数据库架构——核心系统以 Oracle 为主，MySQL 为辅的时代。
• 第一代数据库架构——核心系统以 Oracle 为主，MySQL 为辅的时代。
• 第三代数据库架构——核心系统以 MySQL 结合 NewSQL 为主，NewSQL、MySQL、NoSQL 并存的时代。

立刻金融第二代数据库架构痛点

海量数据 OLTP 场景需求痛点

截止目前帐务系统的核心表累计数据量已达到单表 15 亿行以上，还在高速增加中。监管要求金融行业历史数据至少保留 5 年以上。这给数据库系统带来了巨大挑战：

1. 海量的历史交易与帐务数据堆积在 MySQL 数据库中，使数据库臃肿不堪，维护困难（在线 DDL 变动、数据迁移、磁盘容量瓶颈、磁盘 IO 瓶颈等）。
2. 用户对历史交易订单的查询（OLTP 场景）是必备功能，这些海量的历史数据会根据用户需求经过 Web 页面、APP 终端等渠道进行实时查询（内部、外部用户）。此场景决定了不能经过传统的离线大数据方案来知足需求。须要一种偏向于前台、中台的数据治理方案。

传统分库分表解决方案痛点

根据立刻金融的经验，MySQL 单表在 5000 万行之内时，性能较好，单表超过 5000万行后，数据库性能、可维护性都会极剧降低。当咱们的核心帐务系统数据库单表超过 100GB 后（截止 2018 年 10 月该表累计已达到 528GB），经技术架构团队、业务需求团队联合调研后，选择了 sharding-jdbc 做为分库分表的技术方案。

此方案的优势很是明显，列举以下：

1. 将大表拆分红小表，单表数据量控制在 5000 万行之内，使 MySQL 性能稳定可控。
2. 将单张大表拆分红小表后，能水平扩展，经过部署到多台服务器，提高整个集群的 QPS、TPS、latency 等数据库服务指标。

可是，此方案的缺点也很是明显：

1. 分表跨实例后，产生分布式事务管理难题，一旦数据库服务器宕机，有事务不一致风险。
2. 分表后，对 SQL 语句有必定限制，对业务方功能需求大打折扣。尤为对于实时报表统计类需求，限制很是之大。事实上，报表大多都是提供给高层领导使用的，其重要性不言而喻。
3. 分表后，须要维护的对象呈指数增加（MySQL 实例数、须要执行的 SQL 变动数量等）。

传统 MySQL 在线 DDL 痛点

对超过帐务系统的 528GB 大表分库表成 16 张表以后，每张表有 33GB，仍然是大表。咱们采用了 gh-ost 工具进行加字段 DDL 操做，可是，业务仍然会有轻微感知。所以，必需要将大表的 DDL 操做放到凌晨来作，对业务的 7*24 小时服务有较大限制。

原生 MySQL 的 HA 机制不完善痛点

MySQL 的集群基于 Binlog 主从异步复制来作，切集群主从角色以 instance 为单位，很是僵化。一旦主库出现故障，须要人工重建 MySQL 集群主从关系（也能够把人工操做落地成程序，好比 MHA 方案），截止目前（2020 年 1 月）原生 MySQL 仍然没有成熟可靠基于 Binlog 异步复制的 HA 方案。基于 Binlog 异步复制的 MySQL 主从架构实现金融级高可用有其本质困难。

立刻金融 NewSQL 技术选型

基于立刻金融第二代数据库架构的核心痛点，咱们须要探索新的数据库技术方案来应对业务爆发式增加所带来的挑战，为业务提供更好的数据库服务支撑。

恰逢 NewSQL 愈渐火热，引发了咱们的极大关注。NewSQL 技术有以下显著特色:

• 无限水平扩展能力
• 在线 DDL 操做不锁表
• 分布式强一致性，确保金融数据 100% 安全
• 完整的分布式事务处理能力与 ACID 特性

在帐务系统研发团队、公共平台研发团队、DBA 团队等联合推进下，咱们开始对 NewSQL 技术进行调研选型。

在 GitHub的活跃度及社区贡献者方面，TiDB 与 CockcoachDB(CRDB) 都是国际化的全球开源级项目，是 NewSQL 行业中的表明性产品。

因为立刻金融的应用绝大部分对 MySQL 依赖较高，在协议兼容性方面，咱们毫无疑问地将 MySQL 兼容性列为必选项。

TiDB 从项目发起之初就将 MySQL 协议兼容性列为最 basic 的战略目标之一。而 CRDB 在项目发起之初，考虑的是兼容 PostgreSQL 协议。

基于此，咱们优先选择了 TiDB 技术产品。

立刻金融实践案例分享（两则）

案例一：核心帐务系统归档场景

立刻消费金融帐务系统归档项目是公司第一个持续实践 TiDB 的项目，也是第一个对 NewSQL 技术提出迫切需求的项目，上线后 TiDB 架构以下：

上游分库分表的 8 套 MySQL 集群经过 DM 聚合到一套 TiDB 里，TiDB 对外提供历史归档大表查询服务。

应用架构关键机制：

• 读写分离。经过 sharding-jdbc 实现应用程序读写分离，将历史数据查询请求分发到 TiDB 集群。
• 熔断机制。应用架构设计了熔断机制，当请求 TiDB 超时或者失败后，会自动将请求从新转发到 MySQL，恢复业务。

经过熔断机制可确保万一 TiDB 出现异常时，能快速恢复业务，确保业务的可用性。

帐务 TiDB 集群天天业务高峰期将会承载约 1.3 万 QPS 的请求量（以下图所示），在作活动期间，请求量能冲击到近 3 万 QPS。

通过接近 1 年的不断优化提高，TiDB 集群表现愈来愈稳定，大部分请求能在 50ms 内返回：

研发同事对 TiDB 的 Latency 与 TPS 的性能表现比较满意。

在 2019 年 4 月，帐务系统 TiDB 项目已将 MySQL 数据库 2018 年之前的历史数据删除。极大地下降了帐务系统 8 套 MySQL 数据库集群的 IO 压力。这部分历史数据仅保存在 TiDB 集群内，对业务提供实时查询支持。

案例二：总帐跑批业务场景

立刻消费金融总帐项目是公司第一个彻底运行在 TiDB 的项目，也是第一个从项目上线之初就放弃 MySQL，坚决不移选择 TiDB 的项目。

总帐项目部分模块关键流程示意图以下:

立刻消费金融总帐项目是公司第一个彻底运行在 TiDB 的项目，也是第一个从项目上线之初就放弃 MySQL，坚决不移选择 TiDB 的项目。

总帐项目部分模块关键流程示意图以下:

• 数据量基数大。总帐项目吸纳了公司核心帐务系统以及其余关联系统的全部数据，数据基数很是巨大，要求至少 10TB+ 空间，将来 2 年内可能会增加到 20TB 以上。这个基数 MySQL 难以承载。
• 每日批量时限短。总帐项目服务于管理层，每个月初呈现公司当月的营收核算等信息。在总帐项目数据量基数巨大的前提下，日增量 5 亿到 10 亿，但愿天天能在 3 个小时内完成跑批，用 MySQL 单实例跑不下来。而分库分表技术方案对于总帐系统出报表需求又具有其客观难题。

TiDB 是分布式 NewSQL，计算与存储分离，且计算节点与存储节点都具有水平扩展能力，特别适用于总帐项目的大数据量、大吞吐量、高并发量场景。

项目上线已稳定运行半年左右，目前集群规模以下：

• 8 TB+ 数据量
• 12 POD TiDB 节点
• 24 POD TiKV 节点
• 跑批期间峰值超过 10 万 QPS

总帐项目目前完成了第二期开发，随着项目的继续发展，将来第三期的 ngls 正式接入后，数据量与并发量将再次成倍增加。

总帐项目上线后，跑批期间 QPS 以下:

跑批期间的 SQL 响应时间以下:

跑批期间的 TiKV CPU 使用率以下:

跑批期间事务量与性能以下:

立刻金融 TiDB 经验总结分享

TiDB 切入点经验

TiDB 是一个新潮的 NewSQL 数据库。想要将 TiDB 运用到生产环境，解决 MySQL 数据库面临的历史难题（而不是把问题搞得更大），并非一件简单的事情。

时至今日（2020 年 1 月 14 日），TiDB 已经在数千家企业有实践经验，其中不乏大型银行核心系统 TiDB 实践经验。且 TiDB 3.0 GA 以后，TiDB 在性能、稳定性方面比起以前版本都有了很大的提高。

这意味着已经有数千家企业在向 PingCAP 官方反馈 TiDB 的各类问题并持续获得修复。在这样的背景下，TiDB 能在生产环境中稳定运行并持续为企业创造价值已经是毋庸置疑。

对于企业而言，当前的关注焦点可能再也不是 TiDB 是否稳定可靠，而是怎么才能快速获取到 TiDB 的最佳实践经验，将其归入企业基础技术栈以内。

那么，如何才能快速实践 TiDB，积累到第一手经验，使企业尽快享受到 TiDB 带来的福利呢？

建议从两个方面切入:

• 选定一个归档项目着手尝试： 参考咱们的帐务系统 TiDB 归档技术方案做为企业的切入点。经过此方案，你们能够快速上手 TiDB，在技术风险可控的前提下积累到 TiDB 实践经验。
• 联系官方或者 TUG 组织获取资源：TiDB 是一个全新的分布式数据库，整个体系架构的相比于 MySQL 要复杂得多。而截止目前（2020 年 1 月 14 日），TiDB 官方提供的文档相比 MySQL 等传统数据库要简陋得多。官方文档是入手 TiDB 的必读资料，可是，仅仅依靠官方文档是不充分的。最好能联系官方同窗或者各地的 TUG 组织得到支持。

TiDB 服务器硬件实践经验

从咱们过去近两年实践经验看，TiDB 是否能在生产环境运行稳定，硬件规划是相当重要的先决条件之一。其中，硬件规划最重要的环节包括两个：

• 存储设备规划。TiDB 官方建议使用 NVME 协议的 SSD，时至今日（2020 年 1 月 14 日），主流的服务器 NVME 协议接口已再也不是 pcie 口，而是 u.2 口。这个是你们都知道的，本无需赘言。真正须要关注的是 SSD 的品牌、型号。咱们建议选择 Intel p4510 这一款 SSD，这款 SSD 的读 IOPS 理论值达到 60 万以上、写 IOPS 理论值达到 8 万以上，在生产实践对比结果来看，是 TiDB 的最佳搭档。
• 网络设备规划。服务器、交换机都采用万兆网卡，比较简单，但很是重要。

TiDB 相关软件实践经验

tidb-server 优化经验

tidb-server 可能发生性能异常的地方主要是 CBO 统计信息失效问题与索引设计不合理问题。这两个点并不是 TiDB 独有的问题，MySQL、Oracle 等也有相似的问题。对于前者，建议对关键表定时作 analyze，以确保统计信息准确性。而索引相关的问题，根据常见的数据库优化技巧处理便可。从 3.0 版本开始，TiDB 支持 SQL 查询计划管理功能（SQL Plan Management），对这类问题提供了另外一套解决方案。

tikv-server 优化经验

TiKV 第一个最多见的问题是内存消耗过多被 OOM kill 的问题。TiDB 3.0 之后对 TiKV 内存配置作了优化，官方推荐将 block-cache-size 配置成 TiKV 实例占据总内存的 40%，咱们在实践中发现，40% 的参数值在数据库压力极大的状况下仍然可能会出现 OOM 现象，须要基于 40% 继续往下调整才能找到与业务场景真正匹配的参数值。

TiKV 另一个问题是乐观锁适配问题。Oracle、MySQL 采用悲观锁模型，事务在作变动以前须要获取到行锁，而后才能作变动，若是没有获取到行锁，则会排队等待。而 TiDB则相反，采用乐观锁模型，先更新记录，在提交事务时，再作锁冲突检测，若是冲突了，则后提交事务的会话会报错 Write Conflict 错误引发应用程序异常。这个错误须要从 2 个方向进行处理。在 TiDB 3.0 版本下，默认关闭了事务提交重试功能，须要手工设置 tidb_disable_txn_auto_retry 参数，才能打开事务失败重试功能。另外，TiDB 的乐观锁模型决定了其不擅长处理事务冲突较大的场景，好比典型的“计数器”功能，这类场景最好将技术器功能放到第三方软件来实现会比较合适（好比 Redis）。另外，从 3.0 版本开始，TiDB 已经开始支持悲观锁功能，这个功能预计在 4.0 GA，咱们也开始了这一块的测试工做。

DM 实践经验

到目前为止（2020 年 1 月 14 日），DM 仍然没有发布高可用机制版本，官方正在紧锣密鼓实现高可用机制，咱们建议将 TiDB 用作归档场景做为实践 TiDB 的起点，而不将其做为最终的目标。实践 TiDB 的目标是将 TiDB 做为对前台应用提供 OLTP 服务的数据库。

使用 DM 的关键是有效规避 MySQL 到 TiDB 同步的异常问题，使同步能持续稳定运行。对于刚接触 TiDB 的同窗而言，建议从最简化的方式使用 DM:

• 保持 MySQL 到 TiDB 同步的逻辑结构一致。也就是说，MySQL 里的库表是什么样子，DM 同步到 TiDB 就是什么样子。不作分表聚合。分表聚合长期实时同步有其本质困难，不适合做为初学者的目标。
• 语法预验证确保兼容性。TiDB 与 MySQL 是“高度兼容”的，但没有人能承诺 100% 兼容（其余数据库也同样不敢夸口 100% 兼容 MySQL）。也就是说，若是一些生僻的 SQL 语句在 MySQL 上执行成功了，经过 DM 同步到 TiDB，可能会执行失败，引发同步中断异常。这类问题的最好解决方法是先将变动的 SQL 语句在测试环境 TiDB 执行一遍，确保正确后再到生产环境的 MySQL 执行。

TiDB 热点数据优化实践经验

TiDB 根据表主键 ID 作 range 分区，将数据拆分到各个不一样的 region 内。当某个 region 的数据量达到最大 size 限制后，将会进行分裂。感性来看，一旦某个 region 分裂成两个 region 后，读写压力也会拆分到两个不一样的 region。可是，假设一种场景，当咱们不断对一张表进行 insert 操做，并且这张表是自增主键。那么，应用插入的数据永远会落在该表 range 范围最大的 region，永远处于“添油战术”的状态，最大 range 范围的 region 所在的 TiKV 实例一直处于高负载，整个 TiKV 集群的压力没法均摊下去，出现瓶颈。

这类场景在跑批应用中比较常见。咱们的优化实践建议以下：

• 确保表主键是整形类型。
• 确保表主键离散随机生成，而非自增。

经过以上两种机制能确保批量 insert 操做的写压力随机分摊到各个 region 中去，提高整个集群的吞吐量。

关于 Cloud TiDB 技术方向引子

坊间传言咱们是国内第一家将全部 TiDB 都运行在 Kubernetes 容器云上的（金融）企业。咱们地处西南，平日疏于与业界优秀数据库同行交流心得，是否第一不得而知，但咱们的 TiDB 确实都运行在 Kubernetes 容器云上。

将 TiDB 所有运行到容器云上主要是为了提高软件部署密度，充分利用服务器硬件资源，为往后大规模部署 TiDB 集群打下基础。

根据咱们的实践经验，基于物理服务器部署 TiDB 集群，至少 6 台物理服务器（ pd-server 与 tidb-server 混合部署）起才能部署好一套生产环境 ready 的集群。

当咱们将 TiDB 所有迁移到容器云平台后，最小 TiDB 集群资源从 6 台服务器下降成了 2 pods tidb-server、3 pods pd-server、3 pods tikv-server，硬件成本下降为原来的 30% 左右。

立刻金融 TiDB 项目将来展望

到目前为止，咱们对 TiDB 技术的储备已经持续了近 2 年时间。咱们积累了帐务归档、总帐跑批等大数据量、高并发量的 TiDB 实践经验。咱们还将全部 TiDB 运行到了 Kubernetes 容器云平台之上，使数据库真正得到了 Cloud-native 能力。

将来，咱们将探索更多适用于 TiDB 的核心业务场景，提高 TiDB 在公司内基础技术栈的覆盖面，尤为对 TiDB 即将正式推出的 True HATP 功能充满了期待。咱们将继续深度使用 TiDB，使其为消费金融行业赋能增效增效，共同创造更深远的社会价值。