共计 4226 个字符，预计需要花费 11 分钟才能阅读完成。
作者介绍
陈培新，参加国信证券根底平台研发工作（DevOps、微服务治理、Serverless）
国信证券是一家全国性大型综合类证券公司，在 118 个城市和地区共设有 57 家分公司、185 家营业部，依据中证协公布的数据，近年来国信证券的总资产、净资产、净资本、营业支出、净利润等外围指标排名行业前列。
国信证券从 2020 年 6 月开始接触 TiDB，从技术预研到第一个业务上线大概花了半年工夫。第一个上线的业务是金太阳帐单，前面陆续在数据中台、服务观测等零碎中利用。从只在东莞主机房的 TiDB 部署到 2021 年 9 月实现 TiDB 多机房的部署，并启动国产海光 x86 服务器的试点工作，国信证券在开源 NewSQL 数据库的摸索和利用层面，积攒了丰盛的实践经验。目前，国信证券共有 7 个 TiDB 集群，节点数量 109 个，最大表 100 亿，撑持了托管、经纪和自营等业务。
从 0 到 1，国信金太阳引入 TiDB
国信金太阳提供证券交易、理财和资讯相干的服务。咱们应用证券软件最次要的性能就是交易，在做交易的时候会比拟关注收益率以及什么时候交易股票。以后国信金太阳的用户数大略有一千万左右，在国信有一个大数据平台，存储了所有用户历年的交易数据，账单存量数据有一百多亿，清仓股票数据量大略是十亿，整个帐单和清仓股票增量数据大略是二十亿每年。
下图是国信金太阳大略的服务架构。金太阳 App 间接连金太阳后端，后端架构基于国信自研的 gRPC 微服务框架构建。跟大多数券商零碎一样，金太阳后端对接柜台零碎，外面有交易、帐户、清理等各种后盾利用。所有数据最初会推送到数据中心，数据中心每天或每周都会做跑批。跑批完之后，会将相干的数据推送到前端的数据库中，App 端通过查问服务来查问这个数据库，从而获取相干的帐单以及清仓股票的数据。
图：国信金太阳数据服务架构
整个账单经验了三个版本，账单 1.0 咱们能够称它为刀耕火种的时代。在 1.0 版本的时候，只反对一年账单的查问，应用的是单库单表 SQL Server。具体是怎么实现的？首先，数据中心每天会将数据同步到一张长期表中，而后进行数据转换，这个长期表的通过转换后的数据会追加到正式表外面，正式表外面保留的是一年的数据量。在单库单表的状况下，通过一个两头程序将所有一年的数据都压缩到某一列外面去，外面是一个 JSON 字符串，存的是一年 365 天的数据。那如果新一天有新数据来了怎么办？后盾会起一个定时工作，将新的一天推过来的数据压入到这个 JSON 外面去，再倒推 365 天，把以前最早那天的数据革除，最初再写到正式表外面去。能够看到，这其实是一个十分原始的实现。为什么要应用 JSON 这种格局？因为咱们的数据用户量大略有一千多万，如果是每天存一行的话，用单库单表必定是 hold 不住的。所以一开始，咱们用了一个十分取巧的形式，将 360 多行给它并了一行，这样的话整个表的数据量将近有一千多万，查问效率还能够。
图：账单 1.0 单库单表实现形式
这种形式面临的问题是：业务上，用户心愿查问更长时间的数据，比方五年，应用单表的话，这个需要是难以满足的。技术上，数据查问以及后续的更新压力大，难以扩大，有时候会呈现数据更新出错，第二天用户来查问的时候，查到的数据就不精确了。为了应答这些业务和技术难点，国信在账单 2.0 版本应用 sharding-jdbc 来做分库分表。在引入这个技术的时候，咱们也据说了 TiDB，思考到 证券业务对稳定性要求较高，过后对 TiDB 稳定性还有肯定的担心，所以抉择了 sharding-jdbc。做了分库分表之后，能够反对 5 年帐单的查问，应用了 16 台 MySQL，总共分了 512 张表。数据中心与分库分表是如何进行同步的？数据中心还是和以前每天一样，先把数据写到长期表，转换服务会配置分库分表的规定，从长期表外面取数据，最初写到正式表外面。数据中心有个 ETL 工具，然而它不反对扩大，所以就没有间接写入到正式表。
图：账单 2.0 分库分表实现形式
大略跑了两年工夫，咱们发现了新问题，分库分表尽管能够满足业务需要，但在扩展性方面有很大的束缚，这些束缚包含：第一，字段扩大艰难，咱们分了 512 张表，如果要有新业务上来，须要新增一个字段，这个时候 DBA 就会很苦楚，须要到每个分表新增字段。第二，扩容极其麻烦，数据一开始预估不精确的话，前面分库分表的规定就肯定要变，从一开始 512 张表要变到再乘以 2，变到一千多张表，DBA 迁徙的工作十分繁冗，而且很容易出错。第三，同步还须要两头表，所以数据同步的工夫也还是一样的慢，并且制约零碎上线工夫。第四，分表的定时创立跟清理也比拟繁琐，每天会将一些日表删掉，比方五年前的表，而后还要去创立第二天的表，在开发的时候，始终是要应用这个定时器来做清理和创立。第五，运维方面，也要运维多个数据库。
分库分表制给开发和运维带来了额定的累赘，故咱们把 TiDB 引入到国信外面来，应用 NewSQL 数据库来反对 5 年账单查问，解决分库分表带来的问题，账单跨入 3.0 时代。在这个架构下，数据中心每天间接将数据推到正式表外面，查问服务间接查问 TiDB，在查问服务之上加了缓存。引入 TiDB 后每天同步入库的效率较以前晋升了大略 70% 左右。以后 TiDB 曾经在国信三地机房外面做了部署，同时在东莞机房最近也在做国产海光 x86 服务器的试点。
图：账单 3.0 TiDB 分布式数据库实现形式
接下来谈谈一年多来 TiDB 相干的应用心得。从开发角度来看，首先是大数据量删除，一开始没有教训，还是依照以前老的套路，比方要删除指定某一天的数据，间接就是 DELETE SQL WHERE =“某一天”，过后是周六，运维告警显示 TiDB 的机器顺次一一地挂掉，经排查发现是 DELETE SQL 波及的数据量太大了。后续把事务大小调到 10G，TiDB 机器的内存扩大到 64G，这部分是零碎层面的扩大；另外一方面咱们也在应用程序侧做对应革新，进行分批的删除。在有大数据删除的状况下，可思考应用 Range 分区表，间接 truncate 或 drop 分区即可。
第二个教训是对新上 TiDB 的业务，尽量要应用 AUTO-RANDOM 作为主键，对那种继续大量的插入场景，很大状况下能够防止插入的热点。对于多机房数据同步，TiDB 须要主键或者惟一索引，无主键或者惟一索引会造成同步程序的 OOM。在表已有大量数据的时候，如果要加这个主键，整个过程也会比拟麻烦。
三地高可用容灾架构的实现
一开始只在国信东莞主机房作为试点去做 TiDB 的部署，后续运维要求 TiDB 要做容灾部署相干的工作，利用要实现三地的高可用多活。之前每个机房的利用是拜访本人本地的 TiDB，每个季度会做灾备演练，验证东莞整个主机房故障之后，异地上海与同城福田灾备的可用性。
PingCAP 的老师一开始给了三个计划。第一个计划是最简略直白的，在三个机房都部署一套独自的 TiDB 集群。东莞机房做读写，用 TiCDC 或者 binlog 将对应的数据同步到其余两个机房的灾备集群。这个计划的长处是比较简单，做灾备演练的时候，如果东莞主机房挂了，其余两个机房的利用基本上不必做什么操作，还是能够持续应用。这个计划存在问题是正本数比拟大，须要有 9 个正本，同步的时延可能也会大一点。
第二个计划是比拟经典的 两地三核心 ，这个计划对于网络的要求比拟高，而且如果东莞机房挂了，福田机房要做一下手动复原。第三个是 同城双核心，把东莞跟福田当成一个集群，将数据同步到上海灾备集群，也就是两个集群。但这个计划在做灾备演练的时候做复原也会比较复杂。
图：多机房计划比照
通过三个计划的比照，最初国信还是采纳了最简略的 binlog 同步计划，每个机房部署一个 TiDB 集群，当然这也是依据业务特点来实现的。国信的业务基本上应用查问，不会存在多个机房同时写入，所以最初采纳了这个最简略的办法。在多机房部署实现的过程中做了一些迁徙导入的工作：一开始 TiDB 只在东莞机房部署，因为对于 TiDB 的应用不相熟，有一些业务表是没有加主键或者没有惟一索引。福田机房搭建新的 TiDB 集群之后，咱们发现在做两地集群同步的时候，同步器就间接 OOM 了，这是因为没有加主键或惟一索引导致的。过后有一张最大的表曾经到 60 多亿了，如果间接在表上加主键或者惟一索引的话其实是不可能的。
那咱们是怎么做到的呢？首先应用 Dumpling 将这个表导出到 CSV 文件，这个 CSV 文件的命名是带有表的名称的，在导出实现之后在原来的数据库下面去创立新表，外面加上主键或者惟一索引，再把导出的这两个 CSV 文件重命名跟新表一样，而后通过 Lightning 把数据导入到这个新的表外面，最初把旧表和新表给重命名，把这张新的表命名为正式表，正式表重命名为备份表，这样做的话能够尽量的缩小对业务的影响，在导入导出的过程中，用户基本上是无感的。图：无主键表处理
服务可察看的摸索
最初谈谈在金太阳 服务可察看 方面的摸索。利用在应用了微服务架构之后，部署的节点会十分多，而且调用链整个过程也非常复杂，这个时候想定位一个问题就会很简单，依据业界以后比拟风行的“服务可察看”概念咱们做了一个利用来辅助开发的问题定位。这个“服务可察看利用”次要是蕴含三个局部，一个是日志，第二个是指标，最初一个是跟踪链。咱们针对日志局部做了加强，把零碎的申请和响应日志通过 ETL 工具转换到 TiDB 外面，而后做了可视化相干的工作。
图：金太阳服务的可察看性
可视化 局部是开发始终提的需要，采集了日志个别都是在 ELK 的 Kibana 外面看，都是一些文本，这是十分不直观的。咱们做的优化是对于每个微服务的申请跟响应日志咱们都导入到 TiDB 外面，用“服务可察看”利用去做展现。如果客户有什么问题，输出客户的手机号就能够很直观地看出这个客户在某个时间段做了什么操作，从而能够很快定位问题，同时咱们也将内容和响应进行可视化，看起来更加不便。过后在做 TiDB 入库也遇到一些问题，因为这个业务特点跟账单不一样，账单基本上都是每天晚上做插入，白天用户做查问操作，然而该日志可视化则是在开市期间（上午九点到下午三点多）会做继续大量的插入，查问操作较少，有问题的时候才下来做查问。这是一个运维相干零碎，所以没有用很好的磁盘，零碎上线后就发现整个 TiDB 变得十分卡，一开始认为是插入的程序或者查问程序有问题，咱们做了很多优化，发现还是不行，最初降级完磁盘之后发现整个性能取得了间接的晋升。咱们失去的教训就是上 TiDB 的话，肯定要抉择好的磁盘，这样能力确保解决效率。
