Achieving High Concurrency with ApsaraDB for RDS

By Alibaba Cloud ApsaraDB Team

During Alibaba’s 2018 Double Eleven Shopping Festival, Proxy and Jushita, an Alibaba Cloud ApsaraDB for RDS product, supported a peak of several millions of QPS. There are often cases that tens of thousands of people competing for the same coupon or many people buying the same commodity simultaneously, which can lead to a database pain point known as high concurrency.

As one of the most important safeguards of Double Eleven every year, the Alibaba Cloud ApsaraDB for RDS department deals with high concurrency through parameter optimization, link access, elastic scaling, and architecture design. This allows the Alibaba e-commerce platform to support scenarios such as flash sales, ensuring a smooth Double Eleven experience for all users.

So how are the corresponding technologies implemented? This article will reveal the secrets of the Alibaba Cloud RDS database technologies behind the Double Eleven shopping festival.

Parameter Optimization

When dealing with “high concurrency” scenarios, some specific database parameters become the key to ensuring rapid response to and smooth handling of the “high concurrency” issues. Some of the most important parameters are:

1. loose_rds_max_tmp_disk_space: Controls the size of temporary files that MySQL can use.
2. loose_rds_threads_running_high_watermark: Controls the number of MySQL concurrent queries, commonly used for flash sales.
3. loose_tokudb_buffer_pool_ratio: Controls the amount of buffer memory that the TokuDB engine can use.
4. loose_max_statement_time: Controls the maximum execution time of queries in MySQL.

For example, the parameter settings and effects in the flash sales scenario are as follows:

loose_rds_threads_running_high_watermark

When a flash sale starts, we can see that the number of connections instantly increases by 10 times.

Before adjusting the parameters, we can see that the RUN value is very high, which will cause an alarm of the database.

After adjusting the parameters, the UPD value and the RUN value improves dramatically.

Link Access

In terms of link access, we provide a more secure database proxy access mode that users can turn on/off at any time as needed. The specification of the database proxy is automatically managed by the RDS system. It can be adaptively adjusted according to the load size while ensuring resource isolation among tenants. The database proxy is transparent to and has no effect on the app. It does not require manual intervention, which greatly reduces the O&M costs.

As shown in the following figure:

The database proxy is located between the application (Client) and the database engine, and is automatically maintained by the RDS system. All database requests and responses are processed by the proxy.

Currently, the database proxy supports the following features:

1. Transparent switchover: When an RDS instance fails or is scaled up/down, the database proxy ensures smooth instance switchover and reduces the impact on the app.
2. Read/write splitting: The database proxy provides a transparent read-write splitting feature without modifying the code of the app. Queries are distributed to the RDS read-only instances to reduce the load on the master database.

1. Short connection optimization: Sudden high concurrent short connections (common in PHP applications) are buffered at the proxy layer. This reduces the impact on the DB layer, reduces the RDS CPU load and new connections per second (CPS), and ensures stable database operation.
2. Anti-brute-force attack: The proxy protects the account and password of the RDS instance from brute force cracking.

Elastic Scaling

There are two database upgrade types: local upgrade and cross-server upgrade.

Local Upgrade

Cross-Server Upgrade

Cross-server upgrade requires the migration of backup data and logs

FAQs About Database Upgrade

1. Why does it take a long time to upgrade sometimes?
2. This may be caused by cross-server migration. The migration time is determined by the database size and the system pressure.
3. Why does it take a longer time for cross-zone migration and database version upgrade?
4. Both cases involve cross-server migration.
5. Why is space upgrade fast?
6. Space upgrade does not require restarting or migrating the database.
7. What’s the best time for elastic scaling?
8. We recommend that you upgrade your database during the off-peak period and after the last backup task is completed.

Architecture Design

In response to the growing volume of Double Eleven purchasing and warehousing data, RDS designed a new architecture for each supported database.

As shown in the following table, in terms of engine selection, ApsaraDB for RDS currently supports 4 relational database engines, providing comprehensive solutions, such as disaster tolerance, backup, recovery, and monitoring:

RDS has a built-in read/write splitter, which makes it more convenient for users to use.

In addition, security has always been the biggest concern for sellers and buyers. During the shopping festival, you don’t want your product information or purchase information to be exposed to security risks. To address this concern, RDS has multiple security protections and designs in place:

The RDS team has also re-optimized the database performance, so that sellers and buyers do not have to be worried about the performance and security of the database. This allows them to fully enjoy the Double Eleven Global Shopping Festival.

To learn more about Alibaba Cloud ApsaraDB’s family of databases, visit www.alibabacloud.com/product/apsaradb

Reference:https://www.alibabacloud.com/blog/achieving-high-concurrency-with-apsaradb-for-rds_594297?spm=a2c41.12446743.0.0Database