写点什么

转转业务开发对 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:002797

评论

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

布式系统消息异常该何去何从

架构师修行之路

分布式 异步

spark总结

纯纯

计算机的时钟(三):向量时钟

ElvinYang

一文带你了解微服务架构和设计(多图)

Phoenix

架构 分布式 微服务

LeetCode 169. Majority Element

liu_liu

算法 LeetCo

金沙账号审核不通过维护不给提现风控怎么回事?怎么办

过山太阳

内容审核 提现不了

认证、授权、鉴权和权限控制

哈库拉玛塔塔

spring security 用户权限 鉴权 权限

我们该怎么保护手机屏幕前的父母?

徐说科技

手机 短视频

区块链应用层——生态体系的上层建筑

CECBC

区块链技术 生态体系

HashMap将cpu打满始末

hashmap 线程安全 cpu 100% cpu飙满

以大数据为依托提升基层治理效能

CECBC

大数据 信息化管理

SpringCloud轻松集成Dubbo实现RPC调用

Barry的异想世界

微服务 dubbo nacos RPC spring cloud alibaba

浮点数的秘密

C语言与CPP编程

c c++ 编程语言 浮点数

不草率,你只管下载资料,剩下的交给「哇哦」

小Q

Java 学习 架构 面试 分布式

Golang领域模型-实体

奔奔奔跑

架构 微服务 领域驱动设计 DDD Go 语言

Go: 理解 Sync.Pool 的设计

陈思敏捷

sync sync.pool pool Go 语言

Spring Security 主要类解释

哈库拉玛塔塔

springsecurity

从一段 Dubbo 源码到 CPU 分支预测的一次探险之旅

yes

dubbo cpu

不使用Raft算法,就能简单做集群leader选举

架构师修行之路

分布式 架构师

Java四种引用类型:强引用、软引用、弱引用、虚引用

简爱W

week11--作业

Geek_165f3d

华为与第四范式,正在酝酿一个帮企业跳出AI悖论的“秘密计划”

脑极体

【高并发】面试官:讲讲什么是缓存穿透?击穿?雪崩?如何解决?

冰河

缓存 穿透 击穿 雪崩 签约计划第二季

区块链激励层——区块链生态建设的驱动力量

CECBC

区块链技术 驱动力量

企业中台化落地:从战略分析到战术实践及架构演进过程

Barry的异想世界

架构设计 策略模式 模板方法模式 中台架构 领域驱动设计DDD

CString 类的线程不安全问题

C语言与CPP编程

c c++ 编程语言

我理解的面向对象(ObjectiveSql 实践)

Braisdom

Java ORM框架 ORM

oeasy教您玩转 linux 010212 管道 pipe

o

重新学习了一遍ThreadLocal

熊斌

学习

为什么每个微服务要有自己独立的数据库?

码猿外

数据库 架构 微服务

记录问题 INSERT INTO table ... SELECT ... FROM dual WHERE not exists (...)问题

转山转水

sql SQL语法 sql查询

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