共计 4296 个字符，预计需要花费 11 分钟才能阅读完成。
本文依据 PingCAP DevCon 2021 上来自微众银行资深数据库架构师黄蔚的分享整顿而成，次要论述 TiDB 在微众银行的利用实际，包含微众银行抉择 TiDB 的背景和 TiDB 的部署架构，以及 TiDB 在贷款外围批量场景的利用，最初分享了基于 TiDB 优化计划的最佳实际和将来布局。
TiDB 的产品劣势
从 2018 年底微众银行开始接触 TiDB 的团队，到 2019 年上线，TiDB 在数据库的选型之中展示了很多独有的劣势。
TiDB 兼容 MySQL 协定，同时也兼容 MySQL 的生态工具，比方备份、复原、监控等等，不论是利用自身还是运维或是开发人员，从 MySQL 迁徙到 TiDB，其老本和门槛都较低。对于 TiDB 原生的计算、存储拆散的架构，用户将不用放心容量或者单机性能的瓶颈，某种程度能够把 TiDB 当作一个很大的 MySQL 来应用。同时 TiDB 的数据多正本强统一的个性对金融场景来说非常重要，TiDB 还人造反对多 IDC 的部署架构，能够反对利用做到同城多活的部署架构。此外，TiDB 开源社区的经营也十分沉闷，比方在 AskTUG 平台能够看到很多用户的典型问题的解决办法，蕴含大量的贵重教训能够借鉴，能够进一步升高用户应用 TiDB 的门槛。
当初应用 TiDB 的用户越来越多，不论是互联网头部厂商或者金融行业用户都在大量应用，这也是 TiDB 产品越来越成熟的体现，也给更多用户应用 TiDB 带来了更强的信念。
TiDB 在微众银行的部署架构
TiDB 的个性是否可能满足金融机构高可用的架构需要？
这是 TiDB 在微众银行的部署架构，如图所示，首先 TiKV 抉择三正本，别离部署在同城的三个数据中心，这样能够实现 IDC 级别的高可用，同时在每个 IDC 部署了一套 TiDB Server，通过绑定到负载均衡器提供 VIP 服务，这样使得利用能够做到多活接入的模式。这套架构也禁受过 IDC 级别的实在故障的演练验证，将其中一个 IDC 的网络全副断掉，察看到集群能够疾速复原，咱们认为 TiDB 可能合乎金融场景高可用的要求。
外围批量核算场景
贷款外围批量核算是金融行业比拟经典且十分重要的场景，咱们将其接入到了 TiDB。下图是之前微众银行贷款外围批量利用场景的架构，右边这部分有很多业务单元，相当于把用户的数据做了单元化拆分，每一个单元化数据可能不一样，但架构和部署模型是一样的，底层用的是单实例数据库，同时批量是在每一个单实例数据库下面运行，最终把批量后果 ETL 到大数据平台给上游应用，那么这个架构有哪些瓶颈或者优化点呢？
它是一个纯批量的利用，意味着有大量的批量的写入、更新以及运算，而且数据量都特地大，亿级或者十亿级别以上，随着业务疾速发展，借据数、用户数和流水数据也在继续增涨，如果应用单机数据库来承载，首先受限于单机数据库的性能下限，跑批耗时会越来越长，而且之前单机数据库负载曾经很高，IO、CPU 曾经达到 70% ~ 80%，如果想晋升跑批效率，利用通过减少并发的形式是有危险的，因为数据库负载太高可能造成主备复制提早或者遇到故障无奈进行疾速主备切换，所以效率很难晋升；其次单机数据库对这种亿级或者十亿级的表加字段或者数据管理难度十分大，尽管微众银行日常会用 online DDL 工具比方 pt-online-schema-change 来做表变更操作，但也会有小概率锁表危险。另外基于资源利用率思考，批量零碎和联机系统复用了同一套单机数据库，所以如果批量工作造成高负载，很可能会影响联机交易。基于这些背景问题，微众银行借助 TiDB 做了架构优化的降级。
降级革新后的架构如下图所示，能够看到微众银行把各个业务单元的数据通过 DM 工具把数据实时同步和汇总到 TiDB，而后批量 APP 间接基于 TiDB 做批量计算，再把后果传到大数据平台，相当于借助了 TiDB 的程度扩展性来达到批量效率的程度扩大。之前是传统的 MySQL 主备架构，会要求 APP 服务器 要跟 MySQL 的主节点是部署在同一个 IDC，而如果是跨机房拜访，网络延时会比拟大进而影响批量耗时，所以其余 IDC 的 APP 服务器 就处于 standby 的状态，会有肯定的资源节约，而 TiDB 架构的所有 TiKV 节点能够同时读写，所以能够多个 IDC 同时启动批量工作，最大化资源利用率。
价值收益
TiDB 在微众银行贷款外围业务场景中的应用，总结有三个次要的价值收益。
1. 批量效率的进步。下图右边是微众银行其中一个贷款业务的账单日的批量耗时比照，能够看到在单实例架构上面，批量大略是跑三个多小时，而微众银行通过借助 TiDB 进行架构的降级优化后，耗时缩小到了 30 分钟左右，有相对效率上的晋升。
2. 线性程度扩大。微众银行的需要不仅仅是效率晋升，而且要求其做到程度扩大，也就是弹性伸缩。因为随着业务倒退，借据量包含用户量在持续增长，如果存在热点或者其余瓶颈，当前想持续晋升将十分困难，下图左边是展现其批量耗时的比照状况，在初始的一个资源状况下大略跑 25 分钟，如果数据量翻倍，耗时减少到 50 分钟，如果想把这个耗时降下来再把资源也翻倍，能够发现耗时又降回到 26 分钟左右，可见曾经具备线性扩大能力。所以除了效率上的晋升，线性扩大能力的一大益处就是随着业务继续的倒退，借据数、借据量都在快速增长，这套架构将无需放心业务快速增长可能呈现的技术瓶颈，业务能够更加聚焦于产品自身，这是 TiDB 带来的一个实实在在的业务价值。
3. 批量零碎与联机交易系统拆散。后面提到跟联机系统是因为资源的思考做了一个复用，当初拆分之后实际上跟联机就曾经齐全剥离了，并且没有像单机数据库的主备复制提早，能够最大化资源利用率来晋升批量效率。
基于 TiDB 的优化
以上这些收益能够看到比拟显著的成果，那么微众银行做了哪些优化或者遇到了哪些问题呢？
1.SQL 模式优化。TiDB 因为自身分布式架构其单条申请时延会绝对比 MySQL 更高，所以须要去把一些跟数据库频繁交互的申请进行打包，尽量减少交互，比方把多个 select 改成 in 的形式，把 insert 多条改成 insert 单条多 values 的形式，把多个 update 改成 replace 多条 values 的形式。此外，因为把多个单元化的数据全副汇总到一个 TiDB 集群，那么它的单表数据量肯定十分十分大，如果跑了一个比拟低效的 SQL，很容易把这个集群搞垮，比方存在着 OOM 的危险，所以须要特地留神 SQL 的审核和调优。再比方晚期版本会呈现执行打算不精确的问题，在 4.0 版本反对 SQL 执行打算绑定，能够对一些高频的 SQL 进行绑定，使其运行更加稳固。因为微众银行接入 TiDB 比拟晚期，所以次要应用的是乐观锁模式，利用也做了很多适配，目前适配乐观锁模式的代码曾经固化为一个通用模块，新零碎接入时间接拿来用就能够了。
2. 热点与利用并发优化。应用 TiDB 比拟多的用户可能会对热点这个问题比拟相熟，后面提到弹性伸缩，而要做弹性伸缩，数据必须足够离散，所以微众银行在后期接入 TiDB 的时候也发现像在 MySQL 上的 Auto Increment 个性，可能会存在热点问题，还比方像用户的卡号、借据号也可能是一些间断的数字，所以微众银行针对这两块做了一些调整或优化，比方把它改成 Auto Random，而后把一些卡号，依据它的数据分布法则，通过算法提前把这些数据的分布区间算进去，再通过 Split Region 打散性能进行预打散，这样大批量刹时写入时就能够充分利用每一个节点的性能；另外也对低频批改、高频拜访的小表进行了利用内的缓存解决，缓解热点读问题。除了数据须要足够离散，利用同样也要做分布式革新优化，因为利用是分布式的，所以须要一个 App Master 节点来做数据分片的工作，而后把分片工作平均摊派到每一个 App 上做运算，运行期间还须要监测每个分片工作的状态和进度；最终通过数据和利用的协同优化，达到整体具备的程度扩大能力。
3. 数据同步与数据校验优化。这就是后面提到微众银行通过 DM 工具把各个业务单元的数据汇总起来，晚期应用的 DM 1.0 版本不具备高可用个性，这在金融场景下是比拟致命的。而在 DM 2.0 版本上包含高可用性，兼容灰度 DDL，易用性等等几个个性都已稳固上线。此外是数据校验局部，因为是外围批量场景，数据同步必须做到数据不丢、不错，所以利用也内嵌了数据 checksum 的逻辑，比方在 MySQL 入库时先对数据进行分片，而后把各个分片的 checksum 值写到表外面，再通过 DM 同步到上游 TiDB，最初利用在跑批期间从 TiDB 把各个分片加载进去，而后再跑一遍对应分片的 checksum，再对上下游的 checksum 值进行比对，通过这样的校验机制以确保数据的一致性。
4. 故障演练与兜底预案优化。这个零碎之前是基于 MySQL 的批量零碎，迁到 TiDB 后有一些故障场景体现可能会呈现非预期的景象，所以微众银行做了大量故障演练，第一是模仿各个 TiDB 组件节点异样，确保利用能够兼容，同时当呈现批量中断后，利用也反对断点续跑；第二是整批次重跑，因为可能会遇到程序 bug 或者非预期问题导致整个批次须要重跑，为了疾速复原重跑现场，利用开发了疾速备份和 rename 闪回的性能; 第三是针对极其场景的演练，比方假如 TiDB 库呈现了整体不可用，微众银行联合 Dumpling 和 Lightning 进行了整集群的疾速备份和复原，难点包含 DM 同步的还原点疾速确认、大表人工预打散等等，最初验证的后果合乎正确性和时效性的要求。因为这个架构波及到较多数据流转，所以针对故障场景做了大量的演练以及对应预案 SOP 的编写。
将来布局
微众银行从 2018 年开始调研及 POC，2019 年上线了第一个 TiDB 的利用，以后 TiDB 在微众银行的应用领域已笼罩了贷款、同业、科技治理、根底科技等等，以后还有多个外围业务场景在做 POC 测试。针对将来的布局有五个方面：
1.TiDB 的云原生 + 容器化。能够带来比方自动化运维能力的晋升、资源调配的能力等等。
2. 基于 Redis + TiKV 的长久化计划。次要是替换 Redis + MySQL 的兜底计划，借助 TiKV 人造的高可用个性来做长久化的计划。
3. 基于 SAS 盘低成本利用。微众银行在行内有很多归档场景，数据量特地大，因为受监管要求须要保留很长时间，针对这种存储容量要求高但低频拜访的场景，TiDB 基于 SAS 盘低成本的方向也会做一些试点。
4. 国产化 ARM 平台的 TiDB 利用。去年微众银行曾经有业务上了 TiDB ARM，将来随着国产化的趋势，这块将会被持续加大投入力度。
5.TiFlash 的评估与利用。TiFlash 提供的是 HTAP 的能力，尤其像实时风控以及轻量 AP 查问的场景会带来很大帮忙，这也是微众银行将来的重点布局方向。
