写点什么

TiDB 常⻅架构应⽤场景

  • 2022 年 7 月 11 日
  • 本文字数:6610 字

    阅读完需:约 22 分钟

原文来源:https://tidb.net/blog/57026319


作者:黄潇 , 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 数据库?

1. 弹性伸缩场景

选择分布式数据库是因为它是弹性伸缩的。我希望它能弹出去,也能收回来,不希望不停的去拆合。用过 MySQL 的同学都知道,当流量上来我们要拆库拆表,一拆二,二拆四,四拆八,越拆这个数量越可怕,成本指数级增长。但流量并不一定是指数级增长。产品流量上涨了你拆吗?拆的成本受不了,不拆外卖小哥就该抱怨以前发单 5 秒内就能接单,现在 10 秒 20 秒都看不到。除此之外,还会面临友商的竞争。所以这种场景下业界主要解决方案就是存储和计算分离。那这时候其实是因为我们计算资源不足了,而非存储资源不足。存储我只希望以 1.5 倍的比例去扩展,但是计算我希望以四倍的比例去扩展。这样两个其实不那么 match。在不 match 的情况下,把存储计算分给架构来解决这个事情。所以选择 TiDB 很大一个原因就是因为它是计算存储分离的架构。



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


在活动大促期间,会出现一个非常陡峭的流量高峰。而活动之后,这个高峰会立刻下去。针对这种情况,DBA 需要在大促前配合业务方进行全链路的流量压测,该拆的拆,该扩容的扩容。如果拆出去的,需要一拆二,或者是一拆四,一拆八。拆出去那些库,最后还需要通过 DTS 把数据导回来。导回来需要考虑数据是否一致,无论业务方还是 DBA 都非常痛苦。



所以,从以上三个场景来说,我们遇到的最大的痛点是存储计算没有分离。


我们选型 TiDB 的一个原因是它的存储分离的计算架构。在存储方面,TiDB 内存主要是负责 SQL 解析以及 SQL 引擎的执行。PD 主要提供元数据信息以及分布式数据库的时间戳功能。TiKV 提供的是无限扩展的分布式存储功能。



在这种场景下,存储是 TiKV 的一个集群,计算是 TiDB 的一个集群,它们互不关联,它们之间可以独立的扩容或者缩容,完全不影响其他的组件。这非常完美的解决了我们的诉求。所以,我们选择了 TiDB。

2. 金融级强一致场景

除了弹性伸缩的场景,我们用 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 里面的数据,一定不会丢失。至少单个节点挂了的话,故障是不会丢失的。


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

2.1 跨库事务场景

金融体系除了强一致,还要求事务。MySQL 半同步的超时时间无限长是不行的。



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

2.2 分库分表场景

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



比如用户维度下的转帐场景,在用户 A 的账户上减了一百元,在用户 B 的账户上加了一百元,他们可能在不同的数据分片上。这个事务肯定不希望一笔提交成功而另外一笔不成功。所以这个时候在分库分表的场景下,要保持分布式事务的一致性。

2.3 服务化 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 比较多,期间发起的读取要等待事务的提交。这样对读取的响应延迟有比较严重的影响,所以建议大家把大事务进行拆分。

3. 数据中台场景

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



这里的模糊化、复杂化是指有些之前偏 AP,或偏数据分析的一些请求,现在希望能够拿到实时的数据,放在 TiDB 上来实现。


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


这种场景下,通过 Binlog 同步,把数据拉到 TiDB 里面,在这个集群上我们进行大量计算、高频点查的操作。对于比较大的数据量来说,写入量也是非常高的,TiDB 底层的存储 RockDB 采用 LSM-Tree 模型,对写入来说是友好的一个数据结构。所以这种场景 TiDB 写入可以满足我们的需求。


在这样的集群上面也会有少量的报表类请求。第一个就是实时计算的场景。第二个在构建搜索引擎时也是采用这样的方案来实现。



我们在金融上有一些付款、收单等凭证相关的消费的数据,我们希望这些数据能够从各个系统里抽取出来,汇总在一起形成数据大盘。这份数据形成后,可以多次使用。比如去做一个运营报表、实时大盘、数据大盘,或者作为一个数据订阅方去使用。数据同步需要介入的系统是非常多的,通过 Binlog 、消息队列或者业务双写这种方式进行同步都可以。

4. 其他场景

以下是我们使用 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 的常见架构应用场景,希望能对大家有所帮助。


发布于: 刚刚阅读数: 2
用户头像

TiDB 社区官网:https://tidb.net/ 2021.12.15 加入

TiDB 社区干货传送门是由 TiDB 社区中布道师组委会自发组织的 TiDB 社区优质内容对外宣布的栏目,旨在加深 TiDBer 之间的交流和学习。一起构建有爱、互助、共创共建的 TiDB 社区 https://tidb.net/

评论

发布
暂无评论
TiDB 常⻅架构应⽤场景_TiDB 社区干货传送门_InfoQ写作社区