写点什么

转转业务开发对 TiDB 的使用心得

  • 2019-11-17
  • 本文字数:2139 字

    阅读完需:约 7 分钟

转转业务开发对 TiDB 的使用心得

首先为大家介绍 TiDB 是怎么引入转转的,包括背景和具体引入过程。



TiDB 是 18 年引入转转的。原因是转转业务使用 MySQL 时遇到了一些问题,于是转转数据库负责人冀浩东就主张引入 NewSQL 数据库。


我想简单和大家分享一下 TiDB 引用、试用、内部推广的过程。


转转引入 TiDB 想解决 MySQL 的这些问题:数据量大,如何快速水平扩展存储;大数据量下,如何快速 DDL;分库分表造成业务逻辑非常复杂;常规 MySQL 主从故障转移会导致业务访问短暂不可用。


配合 DBA 启动调研后,最终选择 TiDB。



选型过程:


首先是调研测试,分为功能测试和性能测试;


然后找一个业务验证,选择一个场景去测试,看是否符合需求;


最后是业务上线。首先是涉及到数据迁移,用的比较多的是双写,之后切流量。



我们对 TiDB 做了一些测试,左边的这组数据是读写情况比较均匀的时候 TiDB 的性能表现,每上一个台阶并发数会高一些。右边是读多写少,比较符合互联网的应用场景,这块明显比读写均匀要好很多了,这是对 TiDB 的一个摸底。



接下来是业务场景。我们选择了电商场景下非常重要的 IM 业务来做试接入。选择 IM 的原因第一是非常相信 TiDB 这个产品,第二是相信我们自己的判断。IM 实际上是一个比较复杂的系统,比如说群消息、用户、联系人,我们就又疯狂了一把,选择了最复杂的业务——联系人。选择它的原因是根据测试数据发现 TiDB 在读写均匀的情况下性能会下降。联系人的收发都伴随着许多读写,属于读写比较均匀的业务,如果这个业务都没问题,大部分场景应该都可以适应。我们验证的步骤是:第一步是构造数据从线上扒一份数据拉到线下,再自己写数据去模拟线上流量。


看右边的三个图,最上面只有 MySQL 时的情况,很多毛刺。接入 TiDB 后延时变高,但是平滑,对业务体验更好。如果从性能角度来说, TiDB 在单个场景下很难比得过 MySQL,但在吞吐量大的情况下,不管写入怎么样,TiDB 都很平滑,这就是我们选择 TiDB 很重要的一个原因。



测试合格之后就是上线,数据迁移先主从同步,再双写迁移。


我们的方法是:先拉一份从库到 TiDB,再保持主从同步,当数据追齐之后开双写(我们一般用 MQ),之后可以观察一下,没问题切读流量,一点点分比例切,最后再把写切过去,这样业务就基本上线。



接下来和大家说一下我们使用 TiDB 时遇到的一些问题和应对办法。



首先向大家介绍一个场景,手机推送。需要我们维护一个用户 — 设备 ID 的映射关系,因为推送是基于设备 ID 的,业务场景是 UID — 设备 ID — 第三方服务。


数据变更场景有 1 个账号登录多个手机也有 1 个手机登录多账号的情况。之前用 MySQL 的时候的时候,有的手机取不到设备号,我们会写个默认值。迁到 TiDB 后发现了一个奇怪的场景,默认值这条记录会被频繁并发更新。我们的解决方式是业务进行优化,过滤默认值数据,但根本原因在锁这块。




还有一个是乐观锁的问题。比如商品状态的流转场景,发布者发布商品后状态是 0,发布者可以把商品下架,状态从 0 变成 1。但是买家想买商品的话,拍下后状态从 0 变成 2。我们来看一下这两张表的事务:


第一个事务 Begin,我想把它下架既状态设成 1,同时用 where id=1 and status=0 做条件,才能下架成功,同时判断我影响的行数是不是 1 条,是的话就 Commit


第二个线程是买家,他想把状态更新成 2,他也判断是不是影响了 1 条行数,是的话就 Commit。



MySQL 的处理方式是:


假设这一时刻,线程 1 执行到左图蓝箭头处,线程 2 执行到右图蓝箭头处,线程 2 想提交 update 时就会被锁住。等线程 1 Commit 之后线程 2 发现影响记录不是 1 条, 线程 2 更新失败,商品下架不能购买。



TiDB 的处理方式是:


因为 TiDB 不是行级锁,是乐观锁,先 Commit 看能不能成功。左边 Commit 成功,右边就会因为有冲突 Commit 失败。


我们遇到的问题场景是:万一我需要发 MQ 或做 RPC 记录怎么办?买家买下商品后生成订单要 RPC,但是事务 Commit 失败了,RPC 回滚不了。



TiDB 在开启一个事务的时候,我的一段读写操作都是有缓存的,所以在提交的时候才去判断是否成功。



这里想和大家聊的是事务的实现方式 — 两阶段提交。



假设 TiDB 的处理方式是:TS1 线程 1 开始,TS2 线程 2 开始,TS3 线程 1 提交,TS2 线程 2 提交。谁先开始不重要,关键是谁先提交。


它的实现方式其实就是 L 列和 W 列,我也尝试去研究了一下,但是发现真的很复杂,我尽量简化模型。


假设我有一个表,它有一个 status。我为了实现这个事务会给它额外两列,一个 lock 一个 write。lock 列可以锁一些行,write 列可以写一些更新的信息。 线程 1 尝试提交的那一刻先尝试加锁, 如果发现数据没被加锁,则判断 W 列的时间戳是不是大于 X,如果大于就有冲突,都没问题就加锁。加完锁以后,就要写数据,写完之后更新时间戳 T3,提交事务,然后释放锁。


第一步先 Prewrite,加锁写数据,然后再 Commit 提交变更。


TS4 是 2 事务提交时间,2 事务开始时间小于 TS3,提交时发现 TS2 < TS3,有冲突,这个事务就不能提交。




知道这个原理之后我们怎么做呢?在数据库层并发可能会出问题时,业务就把它串行化处理



最后一个部分是对未来的展望。



业务方面想把 TiDB 与 MySQL 互补, 根据数据量和应用场景选择和使用 TiDB。



作者介绍


陈东,转转基础架构部负责人


本文转载自 AskTUG


原文链接


https://asktug.com/t/tidb/1024


2019-11-17 08:002832

评论

发布
暂无评论
发现更多内容

现代化可观测性平台(2)

俞凡

架构 最佳实践 可观测性

技术干货|热门仿真平台HyperMesh CFD功能详解:几何和网格(Part 3)

Altair RapidMiner

制造业 仿真 几何变换 altair Hypermesh

现代化可观测性平台(3)

俞凡

架构 最佳实践

如何方便的编辑数学公式?好用的公式编辑器软件推荐 mathtype免费下载

阿拉灯神丁

公式算法 函数式 数学工具 MathType LaTeX 编辑器

苹果电脑玩魔兽世界需要什么配置?MacBook玩魔兽世界卡顿丢包怎么办

阿拉灯神丁

游戏 CleanMyMac X 苹果电脑 国外服务器 魔兽世界单机

QQ小程序已发布,但无法被搜索的解决方案

北桥苏

小程序

替换OpenTSDB和HBase,宝武集团使用IoTDB助力钢铁设备智能运维

Apache IoTDB

一键去除ppt底版logo!推荐2个做ppt必备的实用技巧!

职场工具箱

职场 PPT 在线白板 办公软件 AI生成PPT

Mysql高可用架构方案

不在线第一只蜗牛

MySQL

文献解读-DNAscope: High accuracy small variant calling using machine learning

INSVAST

基因数据分析 生信服务 DNAscope 基准与方法研究 Sentieon

多源异构数据源融合怎么做!一文解读(1)

RestCloud

数据挖掘 ETL 数据集成 多源异构数据融合

【JIT/极态云】技术文档--扩展表

武汉万云网络科技有限公司

全媒体数字化转型,业务和技术双管齐下

FinFish

数字化转型 小程序容器 传媒企业 融媒体转型

大模型,智能家居的春秋战国之交

脑极体

AI

业界领先性能|焱融全闪 F9000X 荣获 AI 存储金奖

焱融科技

人工智能 全闪存储

【Spring】配置文件优先级

虚实的星空

spring

2024大湾区网络安全大会成功举办,天翼云AOne筑牢教育安全防线

科技热闻

【JIT/极态云】技术文档--事件介绍

武汉万云网络科技有限公司

iPad备份软件哪个好?好用的苹果备份软件推荐

阿拉灯神丁

ipad imazing iTunes 备份 & 恢复 数据备份工具

让空间计算触手可及,VR手套何以点石成金?

江湖老铁

中国信通院《央国企数智化转型发展报告(2025)》征集参编单位

信通院IOMM数字化转型团队

数字化转型 数智化 IOMM 央国企数智化转型

淘宝上货接口(淘宝发货接口)

tbapi

淘宝API接口 淘宝发货接口

文心一言API密钥:获取步骤指南

幂简集成

API 文心一言

【教程】第五章:标签页 & 区块 —— 丰富视图,精彩纷呈

NocoBase

开源 低代码 教程 无代码

转转业务开发对 TiDB 的使用心得_数据库_陈东_InfoQ精选文章