乐趣区

关于数据库: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 的常见架构利用场景,心愿能对大家有所帮忙。

退出移动版