Redis single data multi-source ultra-high concurrency solution

Redis is currently the most popular KV cache database. It is simple and easy to use, safe and stable, and has a very wide range of applications in the Internet industry.

This article mainly shares with you the solutions and solutions of Redis under the ultra-high concurrent access of single data and multiple sources.

Preface

Redis mainly solves two problems:

When encountering a business scenario with tens of millions of daily users and millions of people online at the same time , if the front-end access is directly loaded into the back-end database, it may overwhelm the underlying database and cause the business to stop. Or as the number of query conditions increases and the combination conditions become more complex, the response time of the query results cannot be guaranteed, resulting in a decline in user experience and loss of users. In order to solve high-concurrency, low-latency business scenarios, Redis came into being.

Let’s take a look at two scenarios

This is a business scenario for online house hunting. There are so many query conditions that the backend must be complex. Query SQL, is it necessary to use Redis in this scenario?

The answer is no. Due to the low concurrency of the online house search business, customers are not so demanding on business response time. Most requests can be directly queried temporarily through dynamic SQL. Of course, in order to improve the user experience, some hot query results can be pre-cached into Redis to improve the user experience.

Let’s take a look at this scenario again

#The film checking system for video applications has almost the same business scenario as the housing search system, but the concurrency is higher By several orders of magnitude, this scenario is very suitable for using Redis as a cache to increase concurrent access, reduce response time, and meet hundreds of thousands or even millions of concurrent access requirements. It can be seen that the fundamental factors in deciding whether to use Redis are concurrency and latency requirements.

Let’s take a look at how Redis solves the concurrent access requirements in extreme Internet scenarios.

Caching solution under ultra-high concurrent access

This is a typical media cache architecture diagram. The publishing system updates the media library from time to time, through The distributed cache service synchronizes each latest article to the Redis cache, and the front-end application finds the corresponding data source access through the routing layer. The data of each cache service is out of sync. When a hotspot event occurs, the routing layer may route access from unreachable areas to the cache server where the hotspot data is located, causing an instantaneous traffic surge. In extreme cases, it may cause server downtime and business damage. So how to solve this irregular traffic burst scenario?

Here are a few ideas:

Break up the hotspot keys with prefixes to achieve hot data replication

Add local cache to the routing layer , improve caching capabilities through multi-level caching

The cache layer provides data copies and improves concurrent access capabilities

The first solution can effectively dissipate hot data, but hot events occur randomly from time to time. The operation and maintenance pressure is high and the cost is high. This is just a solution to a headache and a pain in the ass.

The second solution can improve caching capabilities by adding local cache. However, how large the local cache should be set, how high the refresh frequency is, and whether the business can tolerate dirty reads are all issues that cannot be avoided.

The third solution can add read-only replicas to achieve data replication, but it will also bring about high costs and high load on the main database.

The above architecture diagram is an optimized solution. It pulls multiple branches of read-only slave libraries through the main library, and divides independent caches for different request sources. Serve. For example, mobile applications are fixedly routed to the APP data resource group, and WEB access is routed to the WEB data resource group, etc., and each resource group can provide N read-only copies to improve concurrent access capabilities under same-origin access. This architecture can improve the resource isolation capabilities of different access sources and improve the stability and availability of services under multi-source access.

The problems with this solution are also obvious:

The read and write performance of the main library is poor

There are many read-only copies and the cost is high

The read-only link is passed It is long, difficult to manage and maintain, and has high operation and maintenance costs

The most exaggerated example of our customers has used a 1-master-40-read-only architecture to meet similar business scenarios.

How does Alibaba Cloud Redis solve this ultra-high concurrent access problem?

Alibaba Cloud has launched a performance-enhanced version of Redis. By improving the concurrent processing capabilities of network IO, it has greatly improved the read and write performance of Redis single node. Compared with the community version, the performance has been improved. 3 times. Due to maintaining the single Worker processing mode, it is 100% compatible with the Redis protocol. The above access capability of one million QPS for a single data can be easily achieved. The media scenario introduced in this article can achieve 2 million QPS for a single data by activating a performance-enhanced version of 1 master and 5 read-only instances, effectively alleviating industry pain points such as traffic surges and ultra-high concurrent access caused by sudden hot events. Compared with the self-built community version with 1 master and 40 reads, the Alibaba Cloud Redis performance enhanced version with the same performance standards has a 1 master and 5 read-only architecture, which is more stable, more convenient to manage, and more convenient to use.

The above is the detailed content of Redis single data multi-source ultra-high concurrency solution. For more information, please follow other related articles on the PHP Chinese website!