Shulou(Shulou.com)06/01 Report--

Preface

Redis is a key-value storage system, and now it is more and more used in various systems. In most cases, it is used as a cache because of its high performance. Here are some usage scenarios that Redis often encounter. There is no more to say below, let's take a look at the detailed introduction.

Redis characteristics

The usage scenario of a product must be based on the characteristics of the product, first list the characteristics of Redis:

Excellent read and write performance, persistent data types, rich single-threaded data, automatic expiration, publish and subscribe distributed

Here we talk about the application of Redis through several scenarios and different dimensions.

High performance is suitable for caching

Caching is the most common application scenario for Redis, and all of it is used this way, mainly because of the excellent read and write performance of Redis. And gradually replace memcached as the preferred server-side caching component. Moreover, Redis supports transactions internally, which can effectively ensure the consistency of data when in use.

When used as a cache, there are generally two ways to save data:

1. Before reading, read Redis first. If there is no data, read the database and pull the data into Redis.

2. When inserting data, write Redis at the same time.

Plan 1: it is easy to implement, but there are two things to pay attention to:

1. Avoid cache breakdown. The database does not have the data that needs to be hit, so Redis has no data all the time, and has been hitting the database all the time. )

2. The real-time performance of the data is relatively poor.

Scheme 2: the data is real-time, but it is not easy to deal with it uniformly during development.

Of course, the two ways are applicable according to the actual situation. For example: scheme 1 is suitable for scenarios where the real-time requirements of data are not particularly high. The second scheme is suitable for data storage with dictionary table and small amount of data.

The rich data format has higher performance and rich application scenarios.

One of the great advantages of Redis over other caches is that it supports multiple data types.

The data type describes the string string. The simplest KMurv stores hashhash format, and the value is field and value, which is suitable for scenarios such as ID-Detail. List simple list, sequential list, support the first or last insertion of data set unordered list, fast search speed, suitable for intersection, union, difference processing sorted set ordered set

In fact, through the characteristics of the above data types, you can basically think of the appropriate application scenarios.

String-- is suitable for the simplest KMTV storage, similar to memcached storage structure, SMS CAPTCHA, configuration information, etc., using this type to store. Generally speaking, hash-- key is ID or only marked, and value corresponds to the details. Such as commodity details, personal information details, news details and so on. Because list is ordered, list-- is more suitable for storing some ordered and relatively fixed data. Such as provincial, municipal and regional tables, dictionaries and so on. Because list is orderly, it is suitable to sort according to the time of writing, such as the latest * *, message queue, etc. Set-- can be simply understood as the mode of ID-List, such as which friends one person has in Weibo. The best thing about set is that it can provide intersection, union and difference operation to the two set. For example: find two people's common friends and so on. Sorted Set-- is an enhanced version of set, with the addition of a score parameter that automatically sorts according to the value of score. It is more suitable for data such as top 10 that is not sorted according to the time of insertion.

As mentioned above, although Redis does not have as complex data structures as relational databases, it can also be suitable for many scenarios, more than normal cached data structures. Understanding the appropriate business scenarios for each data structure can not only improve development efficiency, but also effectively take advantage of the performance of Redis.

Single thread can be used as a distributed lock

When it comes to the difference between Redis and Memcached, we talk more about data structure and persistence. In fact, there is another big difference:

Redis is single-threaded and multiplexed to improve processing efficiency. Memcached is multithreaded, and CPU thread switching is used to improve processing efficiency.

So this single-threaded feature of Redis is actually a very important application scenario, and the most commonly used one is distributed locks.

Systems with high concurrency are deployed with multiple servers, and each technical framework has a good way to deal with data locks, such as. Net lock,java 's synchronized, which can deal with the data pollution caused by threads by locking an object. But after all, you can only control the threads of this server, distributed deployment.

In the future, the problem of data pollution will be more difficult to deal with. The single-threading feature of Redis fits this requirement very well. The pseudo code is as follows:

/ / while locklock expiration time is generated to avoid deadlock now = int (time.time ()) lock_timeout = now + LOCK_TIMEOUT + 1 lock = redis_client.setnx (lock_key, lock_timeout) / / Business doing () / / release lock now = int (time.time ()) if now < lock_timeout: redis_client.delete (lock_key)

The above is a pseudo code that only describes the process, in fact, the overall logic is very simple, as long as the deadlock situation is taken into account, it is easier to deal with. Redis as a distributed lock, because of its performance advantages, will not become a bottleneck, generally there will be a bottleneck is the real business processing content, or try to narrow the scope of the lock to ensure system performance.

Automatic expiration can effectively improve development efficiency.

Redis can set expiration time for data, and this feature is also widely used. Expired data cleaning does not need to be concerned by users, so the development efficiency is relatively high, of course, the performance is also relatively high. The most common ones are SMS CAPTCHA, time-dependent product display, and so on. You don't have to check the time like the database. Because it is relatively easy to use, I will not repeat it.

Distributed and persistent effectively deal with massive data and high concurrency

The initial version of Redis officially only supports standalone or simple master and slave, and most applications develop cluster middleware on their own. However, as the application becomes more and more widespread, users' demand for distribution is getting louder and louder, so Redis 3.0 officially added distributed support, mainly in two aspects:

Redis server master-slave hot standby to ensure system stability Redis shards to cope with massive data and high concurrency

And although Redis is a memory cache, data is stored in memory, but Redis supports a variety of ways to persist data and write to hard disk. All, the stability of Redis data is also very guaranteed. Combined with Redis's cluster scheme, some systems have applied Redis as a kind of NoSql data storage.

Example: the combination of second kill and Redis

Second kill is a common marketing mode in Internet systems. As developers, they are the least willing to do this, because non-technical personnel can not understand the technical difficulty, which leads to some deviation in resource coordination. In fact, the problems that often occur in second killing include:

Too high concurrency causes the program to block. Inventory can not be effectively controlled, resulting in oversold.

In fact, there are basically two solutions to solve these problems:

The data is cached as much as possible to block the direct interaction between the user and the database. It is controlled by locks to avoid overselling.

Now explain, if you do a second kill now, then, how should Redis be used together?

Preheat the data in advance, put it into the Redis goods list, put the detailed data of Redis List goods into Redis hash to save, set the expiration time of goods inventory data, Redis sorted set to save the user's address information, Redis set to save the order generation deduction inventory through Redis manufacturing distribution lock, inventory synchronization to deduct the delivery data after order generation, generate Redis list, and then synchronize the Redis data with the database after the message queue processing is finished.

The above solution is a combination of a simple second kill system and Redis. Of course, it is possible to introduce http cache or replace message docking with MQ, and there will also be business omissions. I just hope to attract more attention.

Summary

The above is the whole content of this article, I hope that the content of this article for your study or use of work has a certain reference learning value, if you have any questions, you can leave a message to communicate, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.