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

This article is to share with you about the use of Redis, the editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

Set expiration time, release resources

When using Redis to do KMY V storage, you must pay attention to the control of expiration time. Any KMY V storage must set the expiration time, no matter how long it takes. Generally, the operation API that uses the system common timeout by default is provided when encapsulating the Redis operation tool class, so as to avoid the novice not setting the expiration time when using it, resulting in a waste of memory. In addition, through the connection pool Jedis jedis = JedisPool.getResource (); in this way, it is best to use the try/finally block to get the Redis connection, and call jedis.close () in the finally block; return the connection to the connection pool, otherwise you will hold the connection all the time, which may lead to the error that the connection will not be reported at some point in the future. This is also a mistake made by a colleague before that led to the production of bug!

Cache penetration

Do you think Redis caching is foolproof? Just follow that classic operation? (that is, if the request comes, first look at the cache, return it directly, check the database if not, save the cache first if the database has, and then return it, and if the database does not return empty.) is this the correct posture of Redis cache? If you do this, you are likely to overlook one thing, and that is cache penetration. For example, there is a requirement made in the project before-the page advertisement can be configured to automatically go online (I wrote a special article about the step-by-step evolution of this requirement, which is very helpful to Redis novices, and those who are interested can take a look at it). Simply mention it, for example, everyone should have seen it on the page where the payment is completed, such as the result page after the payment is completed, it may pop up a red packet or something. The advertising space at the bottom of the page is a similar demand. Because of the large number of visits to this page, check the data of this advertising space when you enter this page. When the operator does not want to configure advertising recently, is it empty? The database is also empty, and there is no data in the cache, so many requests come, which creates pressure on the database for no reason, what a waste! If it is other business, hackers take advantage of loopholes, specifically ask for data that does not exist in your system, many requests, all hit the database, is likely to kill your database. If you do not think of this when you are doing the demand, then if something goes wrong later, you will be waiting to take the blame.

How to avoid it?

Easy, you can save a null value or an empty json for data that does not exist in the database (in short, you can agree on it yourself), and also put it in Redis, set a short expiration time, and return directly when you come back to pick it up next time. In addition, a Bloom filter can be used for a layer of system-level protection to intercept key that does not exist in the system.

Cache avalanche

Just after talking about cache traversal, let's talk about cache avalanche. For example, if you put user data in the cache, when all the data expires at a certain time, a large number of requests come, and you find that the cache cannot be hit, so you all go to the database, and don't you fail when there are so many requests from the database? The solution is to spread the expiration time of key as far as possible and not to concentrate. Add a random value to a fixed expiration time. For example, if you set the expiration time to 5 hours, you can add a random value of 0-600 seconds.

Cache concurrency

When the cache expires, multiple requests request the same key at the same time, and all find that the cache is empty and check the database. Isn't this a waste? just check the normal one. Check the other requests for slow storage and get them directly from the cache. This is the cache concurrency problem. When there are too many requests, it will have a great impact on the database, and it is also possible to hang up the database, right? How to solve this problem, can you lock the operation of updating the cache and use synchronized? No, because production is distributed and redis distributed locks are required.

For example, when the cached data fails, a thread uses the resource ID as the key to attempt to add a distributed lock, and the successful thread performs the operation of updating the cache to put the checked data into the cache cache, and other threads can use the cached data directly.

Distributed lock

As mentioned above, synchronized fails in the case of cluster deployment, so distributed locks come in handy. There are three common ways to realize distributed lock: based on database, based on Redis, based on Zookeeper.

The point that Redis distributed lock needs to pay special attention to is the expiration time of the lock. For example, using the setnx command of redis, successful setting means that the lock is acquired, and then the expiration time is set. The thread that fails to execute the command indicates that it failed to acquire the lock. Be sure to pay attention to the setting of the expiration time of the lock, there are locking operations, but also have unlocking operations. For example, a temporary group walking event of our project, a group walking competition of 10 people, in the group stage, users can invite friends to join their own group. Our regiment data is stored in Redis, including the number of people in each regiment. When a user initiates a regiment operation, the backend logic will fetch the number of existing members of the regiment from redis. If it is less than 10, you can continue with the following logic. In a concurrent scenario, if the team leader shares the invitation to join the group with many people, the concurrent execution of their requests for membership is likely to result in a group of more than 10 people. Because in concurrent scenarios, the line of code that executes to obtain the current number of regiment members will be obtained by multiple requests. For example, at the critical time, there are already 9 regiment members, and two requests for membership come at the same time. If there is no control, when reading the number of existing regiment members at the same time, the number of read is 9, and then the regiment operation is performed, which will result in a bug of more than 10 members.

Therefore, in the logic of the request to join the League, it is necessary to add a distributed lock and acquire the lock before the subsequent logic can be executed. Because the operation of acquiring the lock uses the setnx command, and there is no mechanism to wait for the lock, we need to add a spin to the logic of acquiring the lock, try to acquire it at regular intervals, and return locking failure after a certain period of time.

Public boolean tryLock (String lockKey,long expireTime) {long waitTime = 0; / / setIfAbsent uses redis's setnx method boolean success= redisTemplate.opsForValue (). SetIfAbsent (lockKey, "jingzouLock", expireTime,TimeUnit.MILLISECONDS); if (success==true) {return success;} else {while (success==false & & waitTime)

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.