共计 3848 个字符，预计需要花费 10 分钟才能阅读完成。
作者：张政俊 中欧财产数据库负责人
中欧财产是中欧基金控股的销售子公司，旗下 APP 实现业内基金种类全笼罩，提供基金交易、大数据选基、智慧定投、理财师征询等投资工具及服务。中欧财产致力为投资者及合作伙伴提供一站式互联网财产治理解决方案，自 2015 年成立以来业务持续保持持重的增长。
本文介绍了中欧财产在分布式数据库畛域的摸索历程，以及如何胜利将业务零碎迁徙到 TiDB 平台的实际。文章详述了中欧财产采纳 TiDB 的四个上线阶段，展示了 TiDB 在应答数据增长、解决 DDL 挑战以及优化写入性能等方面的卓越体现。此外，文章还特别强调了 TiDB 7.1 LTS 版本所带来的新个性，包含资源管控、Partitioned Raft KV 等，这些翻新极大地晋升了中欧财产的业务效益和性能程度。
分布式数据库的利用历程
中欧财产从 2021 年开始调研分布式数据库，心愿通过应用分布式数据库来实现原有 MySQL 数据库不能满足的需要，从而解决业务层面遇到的技术难题。期间对 TiDB 做了全方位测试，证实了 TiDB 从架构角度是兼容的、从性能角度是达标的。2022 年，咱们洽购服务器开始部署 TiDB 集群，逐渐将一些周边零碎迁徙到 TiDB 上。往年，咱们做了更具体的测试和验证，将更多更简单的业务零碎切换到 TiDB，上半年上线了四个零碎，下半年打算再上线六个零碎。
中欧财产的分布式数据库上线工作能够分为四个阶段：
第一阶段是业务的深度测试 。通过搭建和生产配置雷同的并行环境，应用生产数据进行深度的测试。每个业务零碎有各自的特点，场景都不一样。每次上线前，必须要保障测试是充沛的：业务层面的测试要保障所有的业务都能够跑通；性能方面，每个业务的性能指标不能低于其原先在 MySQL 上的性能指标。横向对实时业务和跑批工作的效率进行比照，找出慢 SQL 并进行优化。
第二阶段是进行数据的同步 。通过 TiDB 提供的 DM 工具，将数据从生产 MySQL 实时同步至 TiDB 集群。当数据实现实时同步之后，再将原架构中 MySQL 上游的同步链路（MySQL 原生同步、Canal、FlinkCDC 等）全副切至 TiDB（通过 TiCDC 输入），之后进行两到三周的数据同步察看，校验数据的一致性。
第三阶段是利用上线 。个别会找一个小的停机窗口，敞开 DM 同步，确保数据的一致性之后，把利用切到 TiDB 上。
第四阶段就是上线后的保障工作 ，对已上线利用的运行状况和数据库的性能体现做跟踪察看。有些业务上线之后，可能会遇到一些测试上没有遇到的问题，也可能忽然会有执行打算跳变这样的非凡状况，须要人工去进行解决。基本上咱们每个零碎上线，都会遵循这四个步骤去做。
下图是目前中欧财产 TiDB 集群的架构示意图。存储层采纳 3 台 TiKV 每台 3 正本的配置，一共 9 个 TiKV 节点。3 个 TiDB 节点，TiDB 和 PD 采纳混合部署模式。另外筹备了两台内存配置较高的 TiDB 节点，将一些非凡的、较大的 SQL、比拟占内存的 SQL 和慢 SQL 独自扔到这两台 TiDB Server 下来跑，肯定水平上起到资源隔离的作用（生产应用 V6 版本临时没有资源隔离性能）。此外，还有 3 台 TiFlash 节点，两台物理机用做 TiCDC。
上面具体讲下业务的上线步骤。业务 A 和 业务 B 做了一些分表分库，分完库之后还须要做数据聚合，再同步到 MySQL 汇总库。除了汇总库之外，咱们还有大数据平台，通过 Canal 去 MySQL 外面抽一些同步的数据，解决之后扔到大数据库。当要切到 TiDB 上的时候，咱们先把 MySQL 的数据通过 DM 同步到 TiDB，TiDB 再通过 TiCDC 将数据写入到上游的汇总库，另一端输入到 Kafka 同步到大数据库。这个架构跑了一段时间，验证了数据同步是没问题后，就会把业务利用真正切到 TiDB 集群上。切换到时候只须要把 JDBC 链接内的地址配成 HAProxy 的地址，就实现一个业务零碎的上线。
目前，中欧财产曾经在 TiDB 集群上线了多套业务零碎，包含费率零碎、基金数据系统、风控系统、大事件零碎、渠道零碎和会员零碎。咱们打算在下半年上线更多的业务零碎。TiDB 的利用正在向外围场景延长，咱们最新的组合投顾零碎、营销零碎、产品零碎、用户零碎，包含交易系统都曾经在打算之中。
应用分布式数据库的收益
2021 年咱们调研分布式数据库的时候，次要是因为咱们的业务遇到了三个方面的挑战。
首先， 单表的数据增长十分迅速 ，咱们开发和运维常常要配合着做各种分库分表，有些时候一个业务库没方法再分了。分表分库十分消耗人力老本，有些表刚分完没多久，单表数据量又很快增长到 5 亿 +，数据须要再从新分片，这个工程量是十分微小的。
其次，就是 大表的 DDL。上两周就遇到这个问题，某个业务场景产生了变更，须要扩长字段，一张分表的 DDL 就要跑 6 小时，而后一共有十张分表，十分浪费时间。而且 DDL 在业务忙碌工夫还不能跑，所以一个业务逻辑的 DDL 变更，DBA 可能须要拆分成几天，甚至几周去实现，对于运维的累赘十分大。
第三，是 单节点写入 的问题。在 MySQL 传统的一主多从架构下，只有一个主节点能够写入，当遇到清理、调仓、跑批工作时，不能满足业务对写入吞吐量的要求。TiDB 是存算拆散的架构，能在线扩容缩容，能够撑持高并发的 OLTP 场景，且满足金融级的高可用要求。
业务上线 TiDB 后，完满地解决了上述 3 个问题，从人力到老本都获得了十分大的收益。
TiDB V7.1 新个性摸索
TiDB 每次大版本迭代，咱们都会第一工夫关注，因为一些新性能的确能解决一些用户的痛点。像咱们以前用 MySQL 的话，没有遇到劫难级 BUG 的状况下，根本不会去降级 MySQL 的版本。因为咱们感觉很久能带来的收益并不是很大，没必要去冒着危险。而 TiDB 的降级迭代，推出的新性能还是十分吸引人的。
比方 TiDB 7.1 LTS 版本，咱们就发现外面的一些新个性十分有用。于是开始搭建环境进行摸索，这里例举了四个咱们的业务场景比拟看重，而且后续会用到的新性能。
首先， 最重要是资源管控，也就是多租户性能 。数据库集群被划分为多个逻辑单元，能够将多个不同的利用放入一个集群中，即便某个业务利用呈现负载飙升的状况，也不会影响其余业务的失常运行。金融业务场景下，对立集群启用资源管控之后，能够保障在线交易业务不会受批量或剖析类业务的影响。
原有的 MySQL 架构还是一主两从，因为写入量比拟大，而且还开着半同步复制，处理量大的时候，MySQL 主库还是有些提早的，导致读写拆散性能并不实用，两个从库基本上就是做劫难复原用的，所以整体的资源使用率非常低。另外一些业务的流量高峰期是不同的，白天可能大家都在进行交易，或者各渠道在推送数据，到了早晨可能就清理跑批。TiDB 能够通过多租户实现削峰填谷，晋升整体资源使用率，升高运维老本。
另外资源管控还能起到限流的作用。生产上遇到 Bad SQL，或者是超级慢的 SQL 是很常见。如果遇到这种状况，咱们在通过 SQL binding 的性能和资源管控的性能，联合起来应用，就能起到长期限流的作用。一般来说，限流做在 Proxy 层会比拟多一点，然而咱们当初不具备这种能力，如果数据库层遇到突发状况能做一个 SQL 级的、针对单 SQL 的限流，这是十分好的一个性能，不必去改代码重发利用，间接在数据库侧通过简略的 SQL Binding 和资源组就能做到。
第二个是 Partitioned Raft KV，每个 Region 的数据都能够独立存储在单个实例中。这样每个 TiKV 实例能够存储更多的数据，咱们比拟关注的写入性能晋升是十分大的，缩容扩容的速度也失去了显著晋升。
第三个是负载自适应读取 。咱们当初的业务包含之后要上的一些比拟大的业务，都会呈现读热点的状况，之前的打散热点计划都不适宜咱们的业务。有了负载自适应读取性能后，申请能够从其余 TiKV 节点读取正本，无需在热点 TiKV 节点排队期待。热点状况下，读取吞吐量能够晋升 70% 到 200%，这个晋升十分可观。
第四个是全局递增列 。这是 TiDB 6.5 的一个性能，然而咱们生产在应用 6.1.2 版本，还没用上这个个性。全局递增列能保障 ID 惟一且枯燥递增，与 MySQL 的自增键完全一致了。之前预调配 ID 会导致咱们局部业务的分页逻辑无奈实现，须要开发同学对业务逻辑进行调整。有了全局自增列后，前面的业务上线时无需再对分页逻辑进行革新，进一步缩小了开发成本。
将来瞻望
最初谈谈对 TiDB 的将来瞻望。
首先是心愿推出 TiProxy，用来代替咱们正在应用的 HAproxy。当前情况下如果 3 台 TiDB-server 进行降级，利用可能会连断三次，十分不敌对，而 TiProxy 能够做到无损降级或重启。另外能够在 TiPrxoy 加上熔断和限流的性能，让整个架构更加灵便、牢靠。TiProxy 甚至能够抓起整个数据库流量，并重放到其余环境或其余高版本的 TiDB 上，以检测新版本集群的稳定性，尤其在数据库版本迭代疾速的状况下，让用户能更好地评估新版本是否能够用于生产。
第二，心愿 TiDB 能够把性能平台进行集成。TiDB 提供很多工具平台，例如 Dashboard、TiUniManager、DM-web 等都是独立的平台，心愿把这些工具都集成在一个集中管理平台上，甚至加上 TiCDC 的治理，这样对于运维人员的应用来说会更加便捷。
第三，心愿提供巡检性能。零碎上线之后查看问题都是靠人去 Dashboard 或 Grafna 平台查看具体情况，如果有巡检性能的话，能够省去人力开销。联合当初的 AI 技术，让 TiDB 出具一份集群的运行状况报告和优化倡议，对用户来说是十分有意义的。
