写点什么

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

评论

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

如何判断LED显示屏的质量优劣

Dylan

技术 质量 LED显示屏 led显示屏厂家 市场

星火闪耀,与AI同行丨华为开发者大会2024社区活动重磅上线!

华为云开发者联盟

华为云 华为云开发者联盟 华为开发者大会2024 企业号2024年6月PK榜

文献解读-农业系列-第七期|《高粱驯化的基因组足迹和多种最终用途的育种选择》

INSVAST

基因数据分析 生信服务

宽睿数字平台兼容TDengine 等多种数据库,提供行情解决方案

TDengine

数据库 时序数据库

你必须得认真体验下 TDengine Cloud 了!抢 600 元体验券

TDengine

数据库 tdengine

软件测试学习笔记丨Vue路由-Router

测试人

软件测试

从云科技 “六边形战士” 数据基建“搬砖人”

从云科技

数据安全 数据基建 数据流通安

理解 Bearer Token 及其功能性

Apifox

后端 身份认证 Token API API 安全

全国AI产品榜发布:百度文库蝉联第一

科技热闻

拯救学弟学妹计划之【论文帮手】是如何实现的?

AppBuilder

“新E代弯道王”MAZDA EZ-6亮相2024重庆国际车展

极客天地

活动|NFTScan 联合 Google Cloud 香港举办线下交流活动

NFT Research

活动 Google Cloud NFTScan #Web3

得物SRE K8s 故障诊断:从 CPU 高负载到挂载泄露根源揭示

得物技术

Linux 容器 性能优化 稳定性 企业号2024年6月PK榜

2024年区块链技术开发全面解析:代币、DApp、NFT、链游与交易所的最新动态

区块链软件开发推广运营

交易所开发 dapp开发 区块链开发 链游开发 代币开发

高效处理风电时序数据,明阳集团的 TDengine 3.0 应用实录

TDengine

如何更好的回答面试问题

老张

面试 面试经验

OpenHarmony专属的智能问答助手“小瓦AI答”上线了

极客天地

从学术到开源:探索北京邮电大学电子工程学院研究生的开源之旅

TDengine

数据库 时序数据库

数据资产化浪潮来临,从云构筑数据资产安全基座

从云科技

数据安全 数字中国建设峰会 数据资产运营 数据安全一体机

【天池科普】1. 为啥人人都要学AI

阿里云天池

阿里云 AI Agent

原腾讯云副总裁张纾翔加入矩阵起源,共筑人工智能新篇章

MatrixOrigin

数据库 腾讯云 AI

快准稳的文档解析工具,帮助构建性能优越的金融领域知识库问答产品

合合技术团队

金融 合合信息 智能问答 文档解析

从云科技入选《API安全市场指南报告》

从云科技

API 数据安全 从云科技

数据安全,让“藏粮于技”水到渠成

从云科技

物联网 数据安全 统一身份认证 零信任 数据流通

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