共计 6091 个字符，预计需要花费 16 分钟才能阅读完成。
作者介绍：刘宇，天翼领取资深架构师。
天翼电子商务有限公司（翼领取）成立于 2011 年 3 月，是中国电信股份有限公司的全资子公司、中国人民银行核准的第三方领取机构、中国证监会核准的基金领取结算机构，是中国电信布局互联网金融的重要板块，是行业当先的创新型金融科技企业。业务覆盖全国近 400 个次要城市，注册用户超 5 亿，单干商户超过 1000 万，笼罩餐饮、娱乐、交通出行、电商购物、民生缴费，通信交费等多个生存场景的便民服务。秉承“响应监管、服务民生、资源共享、单干共赢”的理念，致力于打造平安、便捷、时尚的领取解决方案。
为了在无限的工夫里，让大家理解更多的内容，本次分享将依照数据库架构的演进思路，来介绍 TiDB 在翼领取的演进过程。心愿能够给大家在应用分布式数据库 TiDB 的时候，可能提供帮忙或者启发。如果当中有存疑的中央，欢送大家来多斧正、多交换、多探讨。
原有数据库架构与数据库评估模型
先看一下咱们当初的数据库架构：
依照业务次要分为四层：
首先是业务层，业务层的含意就是指本身为具体的产品或者工艺模块，须要调用外围电路或者外围平台来实现本人的性能。这部分的架构次要是采纳了 X86 服务器和低端存储介质 +MySQL、Redis 开源的产品，这一层在实现业务注册的同时会最大水平的缩小老本。
第二层是外围领取链路层，是业务的核心层，如果呈现问题，将会导致整个平台的交易失败，因而这层会最大保障数据安全、数据可用性以及一致性。它的架构次要用小机 + 高端存储，以及 Oracle 来实现的。
第三层是外围平台层，指的是辅助外围领取链路实现整个交易流程的平台，或者是本人具备一些本身能力的平台，该层在保障性能及稳定性的同时会缩小高端存储的应用老本。
最初就是离线的归档层。依据咱们目前的架构划分在 TiDB 的落地过程中，咱们抉择的路线是从业务层开始，到外围平台层，再往外围领取链路层。目前，业务层以及外围平台层都进行了 TiDB 的推广应用，在过程中，尽管遇到了一些小问题，但总体来看，在数据一致性等关键点都是没有呈现过问题的。其它对于性能解读和参数调优问题也都失去了妥善的解决。并且，在推动过程中，咱们针对分布式数据库建设了一套利用标准，包含最佳研发的利用实际、新老架构并行计划等来升高危险，保障运行。
上图就是咱们建设的用来疾速进行数据库选型倡议的数据库评估模型。当初对于新采纳的我的项目，在关系型数据库的选型上，曾经不再思考应用 Oracle 了，而是在外部的 RDS、Sharding-Sphere、TiDB 中做架构的选型。进行了大量的测试，包含 TPCC、Sysbench、业务测试以及充沛的和原厂进行沟通后，最终确定了中国电信翼领取基于业务场景的数据库选型评估模型。
上面这个表里显示的，咱们次要就是三类技术站，依照容量阀、性能阀、大表的数量、分区规定、HTAP，以及拓扑构造这几个纬度进行筛选。
- 首先是容量上，比如说我的容量小于 3T，QPS 小于 20000，大表小于 10 个，这种场景就会应用 RDS；
- 如果是 3T 到 10T 之间，QPS 超过 20000，大表比拟少，有明确的分表规定，没有统计类的查问的场景，会抉择 Sharding-Sphere；
- 容量大于 3T，QPS 至多大于 20000，大表数量也比拟多，而且分片规定也很难定义，或者是一些混合场景，这种就会抉择 TiDB。
这里就是咱们前面进行案例抉择时可能做出疾速选型的一个倡议。
数据库演进门路
在业务选取和利用上，咱们从边缘做起，首先从历史归档库进行产品的根底性能和性能验证；而后从外围切入，比如说选取对立音讯、营销业务进行理论业务切入；而后再向重要的业务进行过渡，比方选取征信业务、账单业务、账目、以及结算的对账类的业务进行推动，这些是咱们当初曾经推动的内容。接下来咱们布局的要做的就是向外围进发，在 CIF、领取、交易、账务体系中选取试点业务。
在业务利用和切换的原则上有如下几点：
- 采纳业务双写，对利用和数据库的适配层进行革新，并行运行，逐渐进行流量切换；
- 对数据要求是不能丢也不能错；
- 敏感服务在双写验证后，须要疾速的切换到 TiDB 的架构上；
- 迁徙的过程中，随时可能切换到原有的架构；
- 对局部分库分区的表要进行合表。
上面就具体介绍下在 TiDB 应用过程中的实际和优化。TiDB 在翼领取的利用场景次要包含 OLTP 和一些混合场景，大部分场景都是在 TB 级数据库的业务规模。
对账平台零碎利用
对账平台（领取零碎与渠道间的对账）包含两个纬度，一是信息流的勾兑，即业务对账 / 交易对账，次要是就收单交易的领取信息与银行提供的信息流文件进行勾兑。信息流的勾兑能发现领取零碎与银行零碎间的掉单，两边因为零碎间的起因导致同一笔交易领取金额不统一或者领取状态不统一。二是资金流的勾兑，即资金对账，次要就收单交易的领取信息与银行提供的资金流信息进行勾兑。资金流的勾兑能发现领取零碎在银行的帐户资金理论产生的变动与应该产生的变动的差别。这个零碎波及到多张表，单表的规模超 10 亿，整体数据规模在 8T+，业务利用的逻辑绝对简单，并发场景中等，依据架构选型图及评估模型来抉择的话，是比拟实用于 TiDB。
对账平台的利用详情
这是它的数据流向图，首先是外围领取零碎产生交易流水，通过文件模式传输到文件解析服务，文件解析服务将数据的解析后果保留到分布式数据库，对账零碎基于分布式数据库实现对账的流程，同时向 WEB 端提供查问页面和查问服务。
上面两个监控图是对账平台上线后的监控图，日常的（TPS）和响应工夫，目前 TPS 日均在 7000 以下，相应的响应工夫也满足咱们的须要。
对账平台零碎利用价值
对账单零碎平台咱们选取的三个最罕用的对账渠道来进行的比拟：
- 银联支付宝通道，以前应用 MySQL 整体的用时是两分钟，当初应用 TiDB 整体的用时是 40 秒，性能进步了 300%。
- 银联无卡快捷通道，原来应用 MySQL 用时是 3 到 5 分钟，目前应用 TiDB 是 1 到 2 分钟，性能晋升也达到了 200% – 300% 的晋升比。
- 微信领取，原来用 MySQL 用时是 3 分钟，目前应用 TiDB 大略是 1 分钟，性能也晋升了 300%。
这个零碎当初对财务部门经营的解决能效都失去了很大的晋升，大大降低了技术团队的工作复杂度。咱们上线当前，外部对 TiDB 目前的体现还是比较满意的。
集体账单零碎利用
集体账单零碎在翼领取 APP 客户端内为个人用户提供所有交易的账单数据的治理、查问性能，以及数据的分类和统计性能，以便用户能更好的把握本人通过翼领取所做的所有的交易。
数据起源次要来自于 kafka 队列的接管，来源于交易系统。
集体账单数据原来是存在 MySQL 中，应用 MyCat 进行分库分表的策略，然而依然解决不了日益增长的数据和存储空间有余的问题，只能保留一年的数据。同时集体账单数据的主表数据量大略在 80 亿，无论是加列加索引，应用在线的 pt-online-schema，或者 gh-ost 都会面临着拷贝一张长期表工夫过长，面临磁盘打满，或者是两头解决的工夫过长的问题。
依据评估模型，也是属于典型的一个 TiDB 的实用场景，依照利用切换准则短时间内进行了利用切换和迁徙工作。
这里是集体账单的数据流向图。首先是交易系统会把交易的信息同步到 kafka 里，而后会生产到集体账单零碎外面，通过集体账单零碎的解决展现到 APP 端。这里咱们选用了 TiDB 的 DM 进行了 MySQL 迁徙到 TiDB，DM 工具既能够反对全量备份文件，将 MySQL 的数据导入 TiDB，也反对通过解析执行 MySQL binlog 的形式来增量同步到 TiDB，同时它也满足了咱们多个 MyCat 的分库分表，须要合并到同一个 TiDB 一张表的场景。DM 提供了比拟好的反对，大家能够看一下 DM 的工作原理图，下面就是数据的全量迁徙的性能，上面的数据流就属于一个增量数据同步的过程。
对于全量的数据迁徙，DM 首先应用了 dumper 单元从上游的 MySQL 将表构造与数据导成了 SQL 文件，而后通过 loader 单元读取这些 SQL 文件并同步给上游的 TiDB。增量同步的局部首先应用了 relay 单元作为 Slave，连贯到上游的 MySQL 并拉取 binlog 作为 relay log 数据导到本地，而后通过 syncer 单元读取 relay log 并解析成 syncer 的语句同步到上游的 TiDB，这个增量的过程就和 MySQL 的主从复制很类似。
咱们的迁徙是等 DM 把全量数据以及增量都同步到 TiDB 后，通过多种验证它的数据一致性，之后选取一天进行了短暂的写入暂停（大略是 10 分钟左右），交由业务时业务其实是做了一个双写的革新，这时把双写开关关上，同时会写 TiDB，逐渐写把读缓缓切过去，同时会校验 TiDB 和 MySQL 在双写时的数据是否统一，确认没有问题的时候，后续就把 MySQL 的同步断掉，而后就实现了一个迁徙。
集体账单利用状况
大家能够看一下监控图，下面的是从 Zabbix 上取出来的，因为它原来应用的是 MySQL 所以咱们最早应用的是 Zabbix 的监控，QPS 平时最大的大略达到 3 – 4 K，上面的是 TiDB 的图。大家能够看，平时 QPS 是差不多的，然而在流动的时候 QPS 会减少好几倍，这时应用 TiDB 也没有发现问题，阐明在流量减少好几倍的时候也是能够应答这种零碎解决的。
显著晋升了用户体验，减少用户使用量，缩小因追溯交易产生问题失落的用户，减少了用户活跃度，解决了原有分库分表在容量、存储周期、查问效率等纬度的问题。
反洗钱零碎利用
随着监控数据的数量和类型产生许多变动，反洗钱业务需要数据日益增大，监控的范畴一直的扩充，目前平台面临以下几个方面的问题：
- 数据库批量解决零碎呈现显著性能瓶颈；
- 统计分析零碎不满足响应反洗钱监管的时效性要求；
- 数据库性能无奈进行性能扩大。
监管部门对解决工夫的要求是 T+1 的工夫内必须要实现可疑的规定和危险评级的计算要求。目前跑批单的工作工夫大略都在几百分钟，整体工作每天解决的工夫都会在 15 小时，随着数据量越来越大，就满足不了这种性能需求，所以就有革新的须要。
因为监管的严格要求，所以反洗钱零碎在性能上也提出了比拟强的要求：
- 满足 SQL2003 的规范；
- 多表关联，可能查问数据集 1 千万以下，响应工夫 5 秒以内；
- 数据文件批量加载，20G 大小，大略不能超过 30 分钟；
- 亿万数据中要删除 50 万数据，响应工夫要在 10 秒之内；
- 3 亿数据中删除两千万，也要有 10 秒之内的响应工夫；
- 3 亿数据量更新 100 万，响应工夫 5 分钟左右。
评估下来应用 TiDB 是可能实现这种性能要求的，所以就抉择了 TiDB 的计划。
咱们依照 TiDB 的模式进行架构降级，从原来的 Oracle 同步到 TiDB 应用的是（OGG for MySQL client ) 来实现的。还有一部分数据是在大数据平台，咱们应用大数据的公布性能，从 Hive 间接去同步到 TiDB。
这里咱们在反洗钱零碎上做了四项性能比照的测试，包含反洗钱查问业务性能比照、反洗钱插入业务性能比照、反洗钱更新业务比照，以及反洗钱的删除性能比照。 从测试后果来看，整体跑批性能进步了 3 倍以上，跑批工夫也缩短到原来的 ⅓，平台整体无效解决能力晋升到 5 倍以上，进一步满足了反洗钱的需要。
向外围进发
最初介绍咱们下一步的指标。下一阶段咱们将会扩充利用范畴，把业务倒退快、规模大的外围链路的零碎逐渐往 TiDB 迁徙。次要是目前外部环境产生了很多的变动，将来可能在数据库上也会做很多的限度，所以咱们必须提前做一些筹备。
另一方面也是出于性能的思考。大家能够看这个监控图，是翼领取的一个流动中，外围零碎的 QPS 和 CPU。能够看进去，在流动的顶峰咱们应用的零碎是两台高端的小机和高端存储，其中一个单节点的执行量大略在 8 万 4，这时候 CPU 的最小奉献在 10%，阐明咱们的性能曾经根本达到下限了，一旦前面有业务增长，数据规模再增长的时候，性能可能会呈现一些瓶颈，小机设备难以扩容，这也是外围链路上思考分布式数据库的起因。因而咱们能够利用 TiDB 的分布式个性进行程度的扩大，使业务失去一个疾速的扩容。以后还处于一个调研阶段，因为外围系统对稳定性和性能的要求也是对 TiDB 数据库的挑战，这是咱们下一步的指标。
咱们目前的外围库都会有上亿数据量的规模，单库总数据量 10T 以上，在摸索的过程中，咱们也产生了很多的构想，次要是外围业务可能停机工夫十分短或不能停，难度会十分高。
这方面咱们可能须要在开发模式上进行更新，包含：
- Oracle 和 TiDB 共存的双模式开发；
- 灰度或者双写的切换过程；
- 具备业务校验能力；
- 模块和批次进度的设计。
在运维治理上也会有一些更高的要求，包含窗口的切换操作的过程、回退的预案等。
携手趟坑
最初，分享一下这些年跟原厂一起趟过的坑，心愿大家能够给大家参考，防止走一些弯路。
1.insert 周期性超时。
晚期 2.0 版本某业务呈现过 TiDB 的 insert 约每秒 2W 周期性零星 200 毫秒的超时，排查起因因为 Region 数量疾速上涨，Raftstore 单线程工作带来性能瓶颈，长期减少 Heartbeat 的周期来解决，前期降级到 3.0.8 的版本，通过 Raftstore 多线程工作已解决此问题。
2. 执行打算不准，走错索引。
晚期的 2.0 版本呈现过若干次 TiDB 的统计信息不准导致执行打算出错，业务受影响。咱们尝试在每小时进行一个全库表的剖析，然而这个问题依然会间歇性的呈现。目前是通过降级到 3.0.8 根本解决掉了。
3. 备份并发数过高，导致备份工夫的业务偶发超时。
在某个业务应用 TiDB 3.0.8 版本，库容量约 8T，凌晨 3 点发动备份，造成业务偶发超时。经排查发现是备份引起，因为 TiDB 大于 TiKV 备份时占用业务网带宽太大，通过减小备份并发来解决。
4.TiDB+keepalived 的问题。
TiDB 的负载平衡策略应用 HAproxy+keepalived 计划，keepalived 应用 2.0.18 的版本发现偶发丢包，造成业务超时。起初替换为低版本的 1.2.8 后解决，这块倡议心愿 TiDB 能对立拜访层也能本人实现，多一个内部组件就多了一个故障点。
5. 乐观锁和乐观锁的问题。
TiDB 3.0.8 之前的版本应用乐观锁模型，从 MySQL 迁徙过去的利用，在事物中执行 DML 语句时不像 MySQL 那样应用行级锁锁定相干记录行，只有在事物真正提交时才会查看写抵触，这些尽管能够通过利用革新来解决，但也的确造成了迁徙老本的进步，对开发人员造成了一些困扰。但 TiDB 4.0 版本的乐观锁个性比拟成熟，也让咱们对外围迁徙有更多的期待以及更好的根底。
最初援用鲁迅学生的一句话，世上本没有路，走的人多了便成了路。架构落地的过程摸索是十分艰苦的，但这也值得每一个企业去做，在当下这个时代，不论企业的规模如何，都要学会借助开源的力量，防止去反复的造轮子。如果企业规模小，能够间接用开源软件来解决痛点，如果企业规模大，能够投身进入开源者软件的开发，成为贡献者，同时也解决本人的问题。
每一个看似轻松的背地都有鲜为人知的致力，每一个看似光鲜亮丽的背地，都有鲜为人知的付出。分布式数据库建设之路道阻且长，咱们翼领取的人有信念也有能源把他做好。
本文整顿自刘宇在 TiDB DevCon 2020 上的演讲。
