How TiDB Handles Flash Sale Scenarios

Translated
1

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: Tidb如何应对秒杀场景

| username: 近墨者zyl

To improve efficiency, please provide the following information. A clear problem description will help resolve the issue faster:

【TiDB Usage Environment】

【Overview】 Scenario + Problem Overview
In a flash sale scenario with a large number of sessions modifying a single row of data, such as the stock of a particular product or the total amount of a financial product, TiDB performs poorly.

【Background】 Actions Taken
Rate limiting on the application side.

【Phenomenon】 Business and Database Phenomenon
Version 2.0 uses optimistic locking, resulting in a large number of failed transactions.

【Problem】 Current Issue
I would like to know how TiDB should design the table structure and handle this scenario under pessimistic locking from version 4.0 onwards to achieve higher concurrency when modifying a single row of data.

【Business Impact】

【TiDB Version】

【Application Software and Version】

【Attachments】 Relevant Logs and Configuration Information

  • TiUP Cluster Display Information
  • TiUP Cluster Edit Config Information

Monitoring (https://metricstool.pingcap.com/)

  • TiDB-Overview Grafana Monitoring
  • TiDB Grafana Monitoring
  • TiKV Grafana Monitoring
  • PD Grafana Monitoring
  • Corresponding Module Logs (including logs from 1 hour before and after the issue)

For questions related to performance optimization or troubleshooting, please download and run the script. Please select all and copy-paste the terminal output results for upload.

2
| username: wuxiangdong | Original post link

Handling the database alone is probably not enough; it’s still necessary to incorporate Redis and MQ.

3
| username: OnTheRoad | Original post link

It definitely needs to add Redis caching.

4
| username: xfworld | Original post link

The database is just one part of the process. When dealing with a massive number of requests, you definitely can’t rely solely on the database.

5
| username: 人如其名 | Original post link

This hot account issue is difficult to handle not just for TiDB, but also for traditional databases. Distributed transactions combined with locks will definitely cause a significant drop in performance. It’s best to perform updates on hot accounts in a single-threaded manner. Implement queue control on the frontend.

6
| username: WalterWj | Original post link

Go to cache

7
| username: 近墨者zyl | Original post link

Thank you all for your replies. Deploying Redis cache on top of the database is inevitable… However, it’s very difficult to modify the applications that are already online, so we can only rely on traffic control…

8
| username: system | Original post link

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.