关于数据库:TiDB-常⻅架构应⽤场景

作者介绍：黄潇，TUG 北京区 Leader，TUG 2020 年度 MOA。

现在分布式数据库百花齐放，在做数据库架构选型时应该从哪些方面进行思考？在 TUG 陆金所企业行流动上，TUG 北京区 Leader 黄潇分享了 TiDB 的常见架构利用场景，以下内容整顿自当天流动分享实录。

本文次要分为以下三局部：

1. 当今分布式数据库产品出现百花⻬放的状态
2. 在这种场景下数据库架构选型的一些思考
3. TiDB 常⻅应⽤场景

分布式数据库产品百花⻬放

从墨天轮公布的国产数据库风行度排行榜中能够看到，TiDB 排在首位。第二位到第五位别离是老牌的国产数据库 DM，GBase，OceanBase，PolarDB。从上图的曲线趋势能够看出，国产数据库目前处在一个蓬勃发展的期间。对于分布式数据库来说，目前咱们最为关注的有以下五点：

• 能够解决海量数据；
• 数据库高可用；
• 易扩大，像以前的拆库拆表、利用革新，老本很高，合并起来也十分麻烦；
• 强统一；
• OLTP。

数据库架构选型的思考

对于一个线上高并发的服务来说，要思考以下几点：

• 稳固。对于任何一个线上服务来说，能够容忍交易略微慢一点，但肯定不可能容忍频繁宕机。稳固是第一要务，脱离了稳固，效率没有任何意义。
• 效率。在零碎十分稳固的状况下，速度越快，就意味着用户体验越好。比方外卖下单，秒接单的用户感触肯定很好。如果 30 分之后才接单，用户会想到底是零碎出了问题还是外卖小哥偷懒。
• 老本。当稳固有了，效率也有了，就要思考花的老本值不值？因为老本降下来能力赚到收益。
• 平安。平安是一个大家都绕不开的问题。凡是做交易，大家都放心本人的数据被泄露。

所以在数据库下面，咱们最关注的就是保稳固、提效率、降老本、保平安。除了这四项之外，还有就是开源。在做技术选型时，我心愿这个数据库是开源的，因为当我遇到一些问题，是有社区反对的。另外当我想为产品做一些奉献时，是能够和社区一起迭代的。在 稳固方面，咱们会思考这几方面：

• 这个数据库能不能做多活，是否有一些附加诊断以及高可用能力？
• 运维时，做监控告警是否容易？
• 是不是平滑滚动的降级？对业务有没有影响？
• 做数据迁徙的时候，有没有问题？
• 数据校验好不好做？
• 运维上弹性扩缩容的效率如何？

性能方面，咱们最关注四点：

• 第一，低提早。
• 第二，事务模型是不是咱们平时应用的。大家都晓得 MySQL 是一个乐观事务模型，我心愿的是迁徙到新型的数据库上，还能放弃原来的应用习惯。
• 第三，高 QPS。就是说这个数据库是否反对高的访问量。比方做一个流动，今晚流量涨了三倍，这种状况数据库能不能抗得住？抗不住会有什么样的场景？是齐全挂掉还是服务端有主动的性能爱护机制。
• 第四，能撑持海量数据。如果不能撑持海量数据，意味着须要提前跟业务沟通根底设计，确定是否先分库分表以及相应的分片数量。

老本方面，次要思考三个方面：

• 第一，利用接入老本，指接入数据库容易不容易，是否须要提前沟通跟培训。
• 第二，硬件老本，就是 CPU + 内存 + 磁盘。像有一款分布式数据库，它是一个 Scale up 类型的数据库，它要求的内存是 384 G，但并不是所有的互联网公司都能累赘这种高配机型的老本。家喻户晓，在个别的机型上大略要花费四万多老本，像互联网行业罕用的机器，大略 128G 内存，30 核 CPU 或 40 核 CPU，带一张 3.2T 的 PCIE 卡。但如果采纳高密度机型，其价格会呈指数级上涨。所以在这种场景下，所选型的数据库会导致十分高的硬件老本。
• 第三，网络带宽。

平安方面，有三点须要思考：

• 第一，数据库是否有审计性能。拿金融行业数据库举例，用户必定心愿能审计进去谁拜访了这些数据，以及对这些数据做了什么操作。
• 第二，数据是可复原的，不论用户做了什么异样操作，最初的数据都能够通过备份找回。
• 第三，数据库的权限。咱们要思考的是权限的力度会有多细，因为一些非凡场景下咱们心愿数据库的出现精密到表级别，甚至字段级别。比方个人信息里的身份证信息、手机号，还有明码帐号，这些波及个人隐私的信息是不心愿展现给 DBA 或其余 RD 的。

TiDB 罕用利用场景

业务规模和体量

目前我司的 TiDB 的业务规模大略有 1700 多个节点，集群数百个。单集群最大的节点数大略是 40 多个，单表有最大上千亿条记录。目前处于小规模接入状态，还在摸索更加丰盛的业务场景。访问量方面，每日访问量达百亿以上。单集群的 QPS 峰值大略是 10 万以上。

在什么样的场景下，咱们会抉择 TiDB 数据库？

弹性伸缩场景

抉择分布式数据库是因为它是弹性伸缩的。我心愿它能弹出去，也能发出来，不心愿不停的去拆合。用过 MySQL 的同学都晓得，当流量上来咱们要拆库拆表，一拆二，二拆四，四拆八，越拆这个数量越可怕，老本指数级增长。但流量并不一定是指数级增长。产品流量上涨了你拆吗？拆的老本受不了，不拆外卖小哥就该埋怨以前发单 5 秒内就能接单，当初 10 秒 20 秒都看不到。除此之外，还会面临友商的竞争。所以这种场景下业界次要解决方案就是存储和计算拆散。那这时候其实是因为咱们计算资源有余了，而非存储资源有余。存储我只心愿以 1.5 倍的比例去扩大，然而计算我心愿以四倍的比例去扩大。这样两个其实不那么 match。在不 match 的状况下，把存储计算分给架构来解决这个事件。所以抉择 TiDB 很大一个起因就是因为它是计算存储拆散的架构。

互联网高速倒退的时代，常常会有黑天鹅的事件呈现。然而呈现黑天鹅之后，流量在短期内处在爆发式增长的状态。但流量爆发式增长并不代表你的 DBA 人数暴发增长，也不代表你的机制是爆发式增长，这种状况下，DBA 投入再多人力，也来不及拆。另外从下单订购这个机器，机器到机房压测没问题，真正上线，到你能用的时候，可能至多一个月过来了。所以，咱们遇到的一大痛点就是在 业务爆发式增长的状况下，咱们来不及拆。

在流动大促期间，会呈现一个十分平缓的流量顶峰。而流动之后，这个高峰会立即上来。针对这种状况，DBA 须要在大促前配合业务方进行全链路的流量压测，该拆的拆，该扩容的扩容。如果拆出去的，须要一拆二，或者是一拆四，一拆八。拆出去那些库，最初还须要通过 DTS 把数据导回来。导回来须要思考数据是否统一，无论业务方还是 DBA 都十分苦楚。

所以，从以上三个场景来说，咱们遇到的最大的痛点是存储计算没有拆散。

咱们选型 TiDB 的一个起因是它的存储拆散的计算架构。在存储方面，TiDB 内存次要是负责 SQL 解析以及 SQL 引擎的执行。PD 次要提供元数据信息以及分布式数据库的工夫戳性能。TiKV 提供的是有限扩大的分布式存储性能。

在这种场景下，存储是 TiKV 的一个集群，计算是 TiDB 的一个集群，它们互不关联，它们之间能够独立的扩容或者缩容，齐全不影响其余的组件。这十分完满的解决了咱们的诉求。所以，咱们抉择了 TiDB。

金融级强统一场景

除了弹性伸缩的场景，咱们用 TiDB 还会思考到金融级强统一场景。上面我来解释一下为什么要引进这个场景。

先看一下在 MySQL 上遇到的一个问题。MySQL 5.6 的时候是半同步，MySQL 5.7 的时候是增强型半同步，也叫做 Loss-Less，指更少失落数据的半同步。在 COMMIT 胜利之前，先把事务的 Binlog 日志传输到某一个从库，这个从库返回给我 ACK 之后，才去改主库上的 Innodb 引擎。

但这样会带来危险，相当于这个时候还没有通知业务方 COMMIT 操作胜利了。然而 Binlog 其实曾经发送给了从库。这个时候如果主库 Crash 掉，从库却曾经提交了，这就有危险了。

Loss-Less 半同步复制也没有解决掉数据一致性的问题。

当把半同步的超时工夫调成有限长，也并非一个强统一的场景。

尽管能够把超时工夫调到有限长。在这个时候，如果主从之间网络断了，任何从库都收不到 ACK。MySQL 起初援用了 MGR 来解决这个问题。尽管 MGR 解决了数据的强统一，然而并没有解决数据的扩展性。一个 MGR 最多只能承受九个节点，而且不论 5.7 还是 8.0 版本的 MGR 对网络抖动都是十分敏感的，秒级网络抖动会导致写节点切换。MGR 多写模式在社区外面发现了太多的 BUG，所以目前大家应用 MGR，都是应用单写模式，防止事务抵触，防止触发更多的问题。

MySQL 的半同步是没有解决一致性问题的。而 TiDB 是通过 Multi-Raft 协定来解决这个问题。

在 TiKV 这一层，把数据分成不同的 Region，每一组 Region 有多个正本，而后组成了一个 Raft Group。Raft Group 外面会有一个 Leader，负责读取和写入。这样就保障当这一组 Region 的 Leader 挂了的时候，那么剩下的节点会从新选取出一个 Leader 来，负责读取和写入。通过这种形式保障写到 Raft Group 外面的数据，肯定不会失落。至多单个节点挂了的话，故障是不会失落的。

上面看一下须要分布式事务的典型金融场景。

跨库事务场景

金融体系除了强统一，还要求事务。MySQL 半同步的超时工夫有限长是不行的。

本地生存服务的公司强依赖于商户的履约能力，但商户的履约能力取决于零碎的数据一致性和高可用。以外卖订单举例，订单在别离记录到用户端与商家端，这就波及到了跨库业务，这个时候单纯依赖 MySQL 的数据一致性是搞不定的。

分库分表场景

分布式数据库的一个典型场景就是分库分表。

比方用户维度下的转帐场景，在用户 A 的账户上减了一百元，在用户 B 的账户上加了一百元，他们可能在不同的数据分片上。这个事务必定不心愿一笔提交胜利而另外一笔不胜利。所以这个时候在分库分表的场景下，要放弃分布式事务的一致性。

服务化 SOA 场景

分布式事务典型的场景是服务化 SOA。

如上图所示，在微服务化的过程中，黄色、蓝色和绿色这三个数据库咱们心愿整体放弃一致性。那么，在这种场景下应该如何保障事务整体的一致性？

在没有分布式数据库以前，订单类业务是能够写多笔的，当用户端 MySQL 集群挂了的时候，商家端的 MySQL 集群未必同时挂掉，这个时候通过校验服务能够发现商家端存在这笔订单，然而用户端没有这笔订单，那这时能够通过旁路补单的形式来把数据补回来。但这样的形式十分依赖于业务场景，而且非常复杂。下图是补单的逻辑，首先是轮询集群状态，判断是否宕机。

如果是，则判断是商家端还是用户端。如果是商家端的，就检查用户端，把用户端的数据拉过来补，如果发现是商家端的掉了，那么就在用户端查 Binlog，看是否把 Binlog 拉回来，推动 BCP（Business Check Platform），它相当于是商业上的一个事务校验机制。把 Binlog 解析并弥补到另一个维度，这也是一种补单逻辑。

业界当初推崇的一个概念叫做 BASE 的柔性事务。BA 代表业务的根本可用性，S 代表是柔性事务，相当于单性事务，E 代表的是最终的一致性。在 BASE 场景上，业界根本采纳两种形式。一个是 TCC，即 Try / Confirm / Cancel。这外面有多个参与方，都去试一下，能够做就提交，不能够做就 Cancel 掉。另外当一个事务继续期间很长的话，可能用 Saga 模式去做这个事件。这是业界的一些惯例计划，然而咱们发现订单业务单纯依赖这种补单的逻辑，实现的成果并不好。

比如说在这种场景下，北京的一个机房宕了该怎么办？上海的一个机房网络不好该怎么办？所以这个时候就须要在整个配送链路上做 SET 化。SET 化是指从流量入口就把流量按用户维度进行调配，例如 A、B、C 三个用户全局部到第一个 SET 外面，D、E、F 三个用户分到第二个 SET 外面去。两个 SET 之间通过 DTS 进行双向的数据同步，当一个 SET 出问题，会有短暂工夫不可用，这时能够把全副的流量迁到第二个 SET 上。这样就能保障另外一个 SET 也能够持续下单，服务是可用的。然而 SET 化是一个比拟伤筋动骨的解决方案，因为要从流量入口、以后的业务，数据库进行残缺的革新。

在这种状况下，并不是所有的业务都违心做这个革新，因为这是一件很苦楚的事件。除了订单类的业务，实际上还有一种业务叫做帐户类型的业务。订单类的业务是说下了订单，多个维度都写入记录。但对于帐户类型的业务来说，对于金融层的业务是有强制诉求的。而且对金融来说，有异地多活和异地容灾的强诉求。

这外面有绕不开的三个问题：

1. 余额不能小于零，肯定要是一个刚性事务，数据统一。
2. 遇到 IDC 电力 或者是网络故障，整个机房宕了，该怎么办？
3. 用 SET 化解决订单的业务的时候，单个机房能够用 SET 化来解决，但如果是帐户类业务则解决起来绝对艰难，在 SET 化双向复制场景下，写坏的数据曾经扩散到多个集群。这时想要找回数据是十分艰难的。

以上就是咱们在交易型事务上会遇到的两个痛点。首先是订单类的业务，通过补单的形式成果欠佳，而且业务方不肯定违心去配合做整套批改。其次帐户类型的业务在对数据有强一致性诉求的状况下，不能通过补单，而且数据写坏的状况下咱们该如何去做。这就是咱们对金融级强统一的数据的强烈诉求。

解决方案：Percolator 分布式事务模型

所以，基于上述场景诉求，咱们抉择了 Percolator 分布式事务模型。

在金融级的产品数据库上，倡议抉择乐观模式，因为这和原来的 MySQL 是保持一致的，对业务方的改变量比拟少，更容易做兼容。另外，把 RD 从繁缛的补单逻辑、拆分逻辑外面解脱进去，这样他们就能够专一本身的业务，也节俭了老本。在应用 TiDB 分布式事务时，有两点倡议：

• 第一，小事务打包。TiDB 是分布式事务，要进行十分多的网络交互，如果把小事务拆分成一条条去执行，屡次网络交互会导致网络提早会十分长，对性能影响十分大。
• 第二，大事物要做拆分。事务模型如果特地大，更新工夫就会很长。因为比拟大的事务更新的 Key 比拟多，期间发动的读取要期待事务的提交。这样对读取的响应提早有比较严重的影响，所以倡议大家把大事务进行拆分。

数据中台场景

咱们遇到的第三个场景对数据中台的场景，也就是对于海量数据，其数据的场景开始缓缓的模糊化、复杂化。

这里的模糊化、复杂化是指有些之前偏 AP，或偏数据分析的一些申请，当初心愿可能拿到实时的数据，放在 TiDB 上来实现。

以咱们理论利用的场景为例，当咱们要计算酒店房间价格是否有竞争力时，会抓取大量数据进行计算。要求实时数据，并且计算时也不能影响线上房间的价格。如果不拆分进来，而在同一个库上就会导致实时计算能力不停的拉线上 OLTP 的数据，就会造成肯定的响应提早。

这种场景下，通过 Binlog 同步，把数据拉到 TiDB 外面，在这个集群上咱们进行大量计算、高频点查的操作。对于比拟大的数据量来说，写入量也是十分高的，TiDB 底层的存储 RockDB 采纳 LSM-Tree 模型，对写入来说是敌对的一个数据结构。所以这种场景 TiDB 写入能够满足咱们的需要。

在这样的集群下面也会有大量的报表类申请。第一个就是实时计算的场景。第二个在构建搜索引擎时也是采纳这样的计划来实现。

咱们在金融上有一些付款、收单等凭证相干的生产的数据，咱们心愿这些数据可能从各个系统里抽取进去，汇总在一起造成数据大盘。这份数据造成后，能够屡次应用。比方去做一个经营报表、实时大盘、数据大盘，或者作为一个数据订阅方去应用。数据同步须要染指的零碎是十分多的，通过 Binlog、音讯队列或者业务双写这种形式进行同步都能够。

其余场景

以下是咱们应用 TiDB 的时候可能还会思考的一些其余场景。

第一，数据冷热拆散。咱们的线上数据量随着公司的经营历史数据减少会十分多，咱们会把一部分历史数据导到 TiDB 集群外面去，这样也能适当降低成本。

第二，公司外部的日志类和业务监控的数据。这种是因为 TiDB 是底层的 LSM-Tree 数据模式，对写入十分敌对，基本上能够有限扩容。所以拿这个日志去做剖析是比拟适合的。

第三，MySQL 改表存在十分多的限度条件。这种场景下，为了保证数据不提早，同时可能管制在线改表过程中遇到业务高峰期，或者主从提早时能够暂停改表操作，目前线上大部分还是应用 pt-osc 或者是 gh-ost 进行改表。但分表过多耗时会十分长。或者让业务方承受在顶峰时间段改表，升高写入能力，要不就是想其余方法解决这个问题。所以 TiDB 秒级的 DDL 解决了咱们十分大的痛点。

第四，是一个比拟非凡的场景，即从 ES 或者 HBase 迁徙过去的业务。从 HBase 迁徙的次要问题是 HBase 不反对二级索引，而从 ES 迁徙过去的业务是因为 ES 可用性欠佳，于是就迁到了 TiDB。

第五，是往年比拟火的一个场景，随着 5G、物联网的衰亡，数据量爆炸式增长，咱们会遇到十分多 TP 和 AP 类联合的诉求。这种场景下，咱们其实在一个零碎外面同时实现 TP 和 AP 类的 T+0 剖析需要。比方在做大促流动时会针对优惠券的发放计算流动成果，这其中有十分多的大数据 T+0 剖析诉求，仅仅依赖 T+1 报表是很难实现的，然而如果有 HATP，就能在线上传数据，提供给市场进行判断，升高了试错老本以及营销老本。

以上就是 TiDB 的常见架构利用场景，心愿能对大家有所帮忙。