Tidb如何应对秒杀场景

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:
【 TiDB 使用环境】

【概述】 场景 + 问题概述
秒杀场景,大量会话,对一行数据进行修改,比如某一个商品的库存,或者某一个理财产品的总金额,Tidb表现很差

【背景】 做过哪些操作
应用端限流

【现象】 业务和数据库现象
2.0版本是乐观锁,出现大量失败的事务

【问题】 当前遇到的问题
我想知道4.0以后,在悲观锁下,Tidb针对这种场景,应该如何设计表结构,应该如何应对,让并发修改一行的数据的这种场景,能够有更大的并发量

【业务影响】

【TiDB 版本】

【应用软件及版本】

【附件】 相关日志及配置信息

  • TiUP Cluster Display 信息
  • TiUP CLuster Edit config 信息

监控(https://metricstool.pingcap.com/)

  • TiDB-Overview Grafana监控
  • TiDB Grafana 监控
  • TiKV Grafana 监控
  • PD Grafana 监控
  • 对应模块日志(包含问题前后 1 小时日志)

若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

db单独处理,估计扛不住,还是要加入redis,mq

1 个赞

肯定需要加redis缓存的。

数据库只是一个环节,业务针对海量的请求处理,肯定不能只依靠数据库了…

这种热点账户问题别说tidb,传统数据库都很难搞定。分布式事务+锁 性能肯定急剧下降的。热点账户的update要单线程操作才最好,前端做队列控制吧。

上缓存

谢谢大家的回复,数据库上层部署redis缓存是必然的了。。。但是上线的应用改造很困难,只能剩下流控了。。。

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。