TiDB 在安信证券资产中心与极速交易场景的实践

Posted 2023-02-28 TiDB_PingCAP

本文根据安信证券资深数据库架构师李轲在 DevCon 2022 上的分享整理，主要讲述了 TiDB 在安信证券的资产中心与极速交易场景的实践经验。主要包括三部分内容：第一是国产化信创改造总体情况，第二是 TiDB 在安信证券的一些实践情况，第三是实践过程中我们遇到一些问题的反馈和建议。

安信证券股份有限公司（以下简称“安信证券”）成立于 2006 年 8 月，并先后于 2006 年 9 月、12 月以市场化方式收购了原广东证券、中国科技证券和中关村证券的证券类资产。安信证券总部设于深圳，全国设立 50 家分公司，320 家营业部和 370 个营业网点。安信证券现为全牌照综合类券商，多项业务排名进入全国前列，连续 10 年获得 A 类 A 级以上行业分类评级，其中 2011 年至 2013 年达到行业最高的 A 类 AA 级。2020、2021 年安信证券连续获评 A 类 AA 级。

今天分享的议题主要是 TiDB，所以就给大家介绍一下 TiDB 这个产品，TiDB 是原生分布式数据库架构设计，是由 PD 以及 TiDB 和 TiKV 组件组成。PD 层主要是作为数据调度、事务调度以及 TiKV 的元数据的存储。TiDB 层是无状态的 SQL 计算引擎，因为它是无状态的，所以对于后期的扩展需求有良好的支持。第三层的 TiKV 负责具体的数据落地存储，TiKV 节点之间通过 Raft 协议进行数据同步，所以 TiDB 整体架构是以 TiDB 作为 SQL 计算引擎，TiKV 作为落地存储的存算分离架构。

安信证券的国产化改造的架构选型，服务器采用了 Taishan 服务器，底座我们是选用了鲲鹏 920 CPU 搭载运行的是麒麟 V10 操作系统，在上面运行分布式数据库 TiDB，整体架构是基于 ARM 体系。在硬盘的选择上，因为 TiDB 对读写性能要求比较高，所以在 TiKV 和 PD 节点选择了额外的 NVMe 盘作为存储，TiDB 节点使用了传统的 SSD。

下面来介绍 TiDB 实践具体的应用案例。第一个是安信客户资产中心系统，这个系统是一个能够覆盖全账户类型、全产品、全交易行为（1500 多种不同交易行为）、所有交易状态（20 多种交易状态）的数据共享中心，业务范围主要是满足客户的查询账户资产以及了解投资收益的各种场景需求，用数据帮助客户完成自我驱动的财富管理，覆盖了公司 700万+ 的全用户数据，服务查询性能平均响应时间在 50 毫秒以内。这个系统的改造诉求主要是高可用、稳定、落地持久存储这些方面的需求。

整个项目的改造历程分为四个阶段，第一阶段是在 2021 年一季度我们做了可行性分析和验证，包括一些 TiDB 集群性能的初步验证，还有一些数据的同步延时。在去年一年我们做了总体的技术方案设计，包括初步的开发设计、并行验证、初步的系统上线、业务的初步连通性验证和具体实施。在 2022 年一季度，我们做了下游系统的改造，包括一些业务代码以及系统对接等方面的开发。在 2022 年底我们已经完成了全部流量切换和备中心搭建。

可以看到这套系统的改造前后，主要是针对日间变化数据这套原来基于 Lamda 技术架构做了改造，现在换成基于 TiDB 技术架构，下图表示具体的数据链路改造的变化。

左侧初始架构是从 OGG 到 kafka 再到 Spark Streaming 的流式处理，最后到 redis 进行落地存储的消息流处理模式架构, 右侧则是改造后的由四个组件现在简化成由 AR 数据导入导出的同步工具，再最终落地到 TiDB 进行数据存储。

改造的目的主要是出于五个方向考虑，总体也可以分为运维角度和业务两个角度。

第一，降低运维难度。原架构的数据链路比较长，设计上是从原来的柜台 DB 到 OGG 然后再到一系列的大数据组件，最后落地到 redis。随着组件的增多，出问题的概率会比较大一点，并且对运维人员技术栈的储备要求较高，后续的运维难度也比较大。大数据开源组件的特性在使用中有可能造成在一些业务场景数据的丢失，会影响到客户的使用体验。现在升级改造之后，数据链路换为柜台 DB 到 AR 数据同步工具，然后再落入到 TiDB ，极大地简化了一个数据流转链路，也简化了技术架构，相较之前运维也较简便。TiDB 是一个关系型数据库，对 DBA 来说运维技术的过渡转换也是十分方便的，加上 TiDB 的强一致性也可以保障写入数据的高可靠。

第二，性能容量提升。原有架构以 redis 作为最终数据落地存储，设计初始更多的是基于高可用的出发点进行设计，用了哨兵模型进行部署。而证券行业特点使流量负载和流量峰值很难预测，原有的架构设计在一些业务峰值的数据承载以及性能上会有一定的瓶颈，特别是在数据峰值比较大的时候，如果需要扩展，对架构的改动较大，风险也相应提高。原有架构在线水平横向扩展能力上不足，缺少对逐渐增加的业务流量承载能力。TiDB 可以支持在线水平弹性扩展，最主要的特点就是弹性扩展对业务是无感知的，如果说缺少计算方面的能力，那么直接扩展 TiDB 节点即可，如果数据量增多，可以直接扩展 TiKV ，并且扩展只需增加节点数，不需要对原有架构进行改动。

第三，缩短应急处理周期。之前的架构因为大数据组件比较多，特别是 kafka 的消费以及重试机制，如果出现问题的话，因为其流式架构设计，出现故障的时候第一我们要定位，第二在时间点的处理方式上我们可能会基于更早的时间点去进行消息重放，需要有一定的时间去进行消息处理，从而进一步拉长应急处理周期，降低故障处理速度，我们发现在一些应急处理场景并没有达到预期。改造后，在出现故障的时候可以通过 AR 导数工具快速将指定时间的数据恢复到下游 TiDB，能在很短的时间内将业务恢复，提高系统的运维连续性和可用性。

前三点主要是从运维角度出发的，后两点更多是从业务和开发角度去进行改造。

也就是第四点，简化数据流转复杂度。之前是使用 redis 作为最终的数据落地存储，这块第一我们在一开始设计的时候没有打算做长期的存储保留，而源数据端柜台 DB 是传统型关系数据库，例如 DB2、Oracle 以及 mysql，从柜台数据同步到 redis 会经过一些数据转换，从结构化数据转换到 KV 结构数据，对于下游的开发、设计也会增加了复杂度。现在转为 TiDB 后，同样都是关系型数据库架构，从柜台 DB 到 TiDB 的数据结构对于开发团队来说没有什么太大的区别，直接进行开发使用，简化数据流转复杂度，提高开发的灵活度。

第五点，支持历史查询以及复杂分析。随着业务发展不断增加的需求，例如报表分析等。原来的架构无法满足我们将来的一些复杂分析以及客户的特定需求，业务痛点基于原有架构很难去解决。改造成 TiDB 之后，首先单集群能够支持 200TB 以上的数据量，可以进行历史数据的长期存储， TiFlash 分析引擎可以很好地支持复杂分析，OLTP 和 OLAP 事务分离，也可以跟我们的大数据栈进行无缝衔接，支持后续业务发展。

接下来我们来看实时资产项目的部署架构，2022 年南方主中心生产上线，每台机器上部署了两个 TiKV，是一个 32 的架构，PD 和 TiDB 采用混合部署，也是 3(1PD*2TiDB) 的架构设计，在 TiDB Server上层做了 HAProxy ，负责流量的接入以及负载均衡的调度。2022 年底已完成部署深圳备中心。TiDB 数据主要是通过 binlog 方式将主中心的数据进行同步。

以上就是客户资产中心系统的改造总体情况，接下来介绍 ATP 极速交易系统。

ATP 极速交易系统作为安信证券首批的交易系统改造是比较慎重的。对这个项目的系统改造要求也比较特殊，这套系统改造是一个全面的国产化改造，要支持国产化服务器、操作系统甚至是路由器，包括一些前端应用全部都是国产化的设计。作为交易系统所以改造的最终诉求就是适配性好、业务改造简单，而源端的数据库原来使用的是 MySQL，TiDB 对 MySQL 的兼容性好，可以降低原有开发团队的适配难度，只要把数据直接导入再进行相应的适配开发。交易系统的定级也需要满足证券行业的两地三中心的技术要求。

ATP 的整体项目进度还处在上线及试用阶段，预计要在 24 年中才会根据改造进度和业务需求进行大规模的客户迁移和流量接管。

ATP 极速交易业务架构是采用三中心部署。项目比较有特点的地方就是它是一个自底向上全国产化方案，一般的项目改造可能只是针对服务器以及数据库进行替换。而 ATP 系统是从底层网络的交换机到服务器以及 CPU，还有操作系统和数据库全部采用产品。在上层应用，也采用华锐的 ATP 国产化版本，包括机构交易平台和分布式高性能计算平台。

这套系统主中心的应用组件采用主备高可用部署方式，组件间实时同步保持强一致性，只要有单点故障的出现，可以实现自动切换，满足 RPO=0，RTO<10 秒的要求。也能支持系统的水平扩展，作为一个极速交易系统，核心诉求就是快，进行国产化改造之后，需要保证交易时延也要与原来的系统一致。所以在低时延这块，也能做到微秒级的全链路时延。

接下来看具体的部署架构。以南方主中心，深圳科技园备中心，上海金桥灾备中心形成一个两地三中心，一主两备的级联部署。备中心和灾备中心的配置类数据是通过 TiDB 本身数据库的 binglog，以异步同步的方式进行数据同步。考虑到时延和性能， 各机房会处理自己的交易类数据，然后直接落盘到本地库，这样可以保证交易数据快速地入库以及对外提供服务。

在网络环境上采用了华为的交换机，接入交换机是采用双机的组网，配置 V-STP 模式对外提供服务，同时配置了双活网关，对于业务网络来说，把交换机链路单独划分出一个 VLAN，专门用来业务网络使用。交换机三层与核心交换机进行互联，通过静态以及动态路由实现两地三中心业务的互通。

TiDB 的整体使用收益，我们从两个业务场景看。第一个是资产中心，资产中心受益的地方，就是极大地精简了数据流转链路，把原来多个大数据组件的一套架构，改造成 TiDB 一个国产化数据库，承载的功能不变。数据处理流转比较简单，从传统的柜台关系型数据库到 TiDB 是关系型到关系型，对于开发使用也比较友好。TiDB 提供数据的强一致性保证，支持后续的高并发联合查询、水平扩展、复杂分析、开发需求等等。对于极速交易来说，TiDB 首先满足全栈国产化和全功能兼容的要求，从原来的 MySQL 切换到 TiDB，功能上和兼容性来说是都是不错的。其次，TiDB 支持两地三中心的高可用部署，也满足高可用需求。

最后分享一下 TiDB 在安信证券实践过程中遇到的一些问题，以及具体是我们怎么做的，希望这些能给大家一些启发。

首先第一点，就是数据读写热点。TiDB 的底层存储 TiKV 的数据是以 region 为单位进行存储，在 region 上按照 key 值有序追加，如果不做特殊处理的话，数据会一路往后面追加，在高并发场景下比较容易产生读写的热点。因为数据比较集中，读事务与写事务都会集中在一块资源上，会产生读写热点。对于这个问题，我们的建议是在进行表结构设计时，尽量使用 Auto Random 方式的自增主键，把数据打散，分散存储，可以减少热点冲突的现象。

第二点就是 TiDB 内部组件资源争用的现象。这个场景比较特殊，因为我们的业务场景是有很多的 DDL。在大量 DDL 场景操作下，TiDB 的 region cache 可能会因为某些内在机制没有及时清理，后续的 SQL 查询语句进来的时候，可能会找到实际上已经不存在，但是它认为没有被清理的region。当SQL语句发现数据不存在时，就去寻找下一个可能存在的region，这种情况导致 SQL 执行时间就被不断拉长，使SQL 执行效率下降进而影响到集群的其他语句，最终表现形式就是业务处理性能下降。我们的处理方式是将 DDL 的应用与其中的一个 TiDB server 进行绑定，也就是将 DDL 场景以及语句进行聚合，尽量争取是在一个 TiDB server 进行处理，然后其他的业务 通过 HAProxy 进行负载均衡，把其他的一些读事务分发到其他的 TiDB server 进行处理，减少 DDL 事务与读事务之间的影响，从而保障读性能。

第三就是锁冲突。大部分企业都是从传统的 Oracle、MySQL 以及 DB2 等数据库进行改造。而TiDB 的锁处理机制与传统数据库不一样，其同时存在乐观事务和悲观事务。对于开发团队来说，一些 SQL 的执行在原来数据库上的执行结果与现有的 TiDB 的执行结果可能会出现差异。建议在改造迁移的时候，比如说从 MySQL 等数据库迁移，在开发的时候要重视开发规范，比如严格使用事务显式声明，像 begin 加上需要执行的SQL语句，加上 commit 的方式，特别是对于 DML 语句，尽可能保证这个事务机制与原来的传统关系型数据库（像 MySQL）一致，减少开发的复杂度，保证数据的准确性。

写在最后，自主创新之路确实会出现许多大大小小的问题，这也需要我们一起去协作解决和攻克这些阻碍。

道阻且长，行则将至。行而不缀，未来可期。