共计 5143 个字符，预计需要花费 13 分钟才能阅读完成。
本文依据安信证券资深数据库架构师李轲在 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）统一，缩小开发的复杂度，保证数据的准确性。
写在最初，自主翻新之路的确会呈现许多大大小小的问题，这也须要咱们一起去合作解决和攻克这些妨碍。
道阻且长，行则将至。行而不缀，将来可期。