本文依据安信证券资深数据库架构师李轲在 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）共同，削减开发的杂乱度，确保数据的准确性。
写在最后，自主创新之路的确会呈现许多大大小小的问题，这也需求咱们一同去协作解决和攻克这些阻碍。
道阻且长，行则将至。行而不缀，未来可期。
