How to use Redis to solve high concurrency

NoSQL

Abbreviation for Not Only SQL. NoSQL was proposed to solve the inability of traditional RDBMS to deal with certain problems.

That is, non-relational databases. They do not guarantee the ACID characteristics of relational data. There is generally no correlation between data. They are very easy to implement in terms of expansion and have high performance.

Redis

Redis is a typical representative of nosql and is also a must-use technology for current Internet companies.

Redis mainly uses hash tables to implement key-value pair storage. Most of the time, it is used directly in the form of cache, so that the request does not directly access the disk, so the efficiency is very good, and it can fully meet the needs of small and medium-sized enterprises.

Common data types

• String string

• Hash hash

• List list

• ##sets sets

• Ordered set sort set

String and hash are used more frequently. Each type has its own operation command, which is nothing more than adding, deleting, modifying and checking. I will sort out the specific commands later.

Pain Points

When many requests occur simultaneously in web applications, it may cause errors in data reading and storage, that is, dirty reads and dirty data generation occur.

Under distributed projects, more problems will arise.

Thoughts

When it comes to concurrency, the essence is that multiple requests come in at the same time and cannot be processed correctly.

You can put all requests in a queue, so that the requests can come in one by one in order to execute the business logic. Using message queues is currently a feasible solution. I will compile an article on how to deal with high concurrency message queues next time

Another method is to directly convert parallelism to serialization. Java provides synchronized. That is synchronization, but this is still not a suitable solution in places with strict efficiency requirements or distributed projects. This leads to the use of redis to implement distributed locks to solve concurrency problems.

Distributed lock

In distributed projects, a unique, universal, and efficient identifier is used to represent locking and unlocking.

Redis is very simple to implement, that is, whether a key exists or not indicates whether it is locked or unlocked.

Take the string type as an example:

Integer stock = goodsMapper.getStock();
if (stock > 0) {
    stock =- 1;
    goodsMapper.updateStock(stock);
}

The above is the simplest pseudo code for instant killing. We try to use redis to implement distributed locks.

// 这里是错误代码，只是一个思考过程，请耐心看完哦
String key = "REDIS_DISTRIBUTION_LOCKER"; // 分布式锁名称
String value = jedisUtils.get(key);
if (value != null) { // 未上锁
    // wingzingliu
    jedisUtils.set(key, 1); // 上锁
    Integer stock = goodsMapper.getStock();
    if (stock > 0) {
        stock =- 1;
        goodsMapper.updateStock(stock);
        jedisUtils.del(key); // 释放锁
    }
}

There may be a problem with the above code, that is, when multiple requests come in at the same time, and multiple requests at a certain time all get the value as empty, thread A enters the if and goes to // wingzingliu. Locking, other requests also come in, so dirty data will appear.

The code problem here is that the atomicity issue is not considered.

So we have to use a setNx command of redis. The essence is to set the value, but this is an atomic operation. After execution, it will return whether the setting is successful.

redis> SETNX job "programmer"    # job 设置成功
(integer) 1
 
redis> SETNX job "code-farmer"   # 尝试覆盖 job ，失败
(integer) 0
 
redis> GET job                   # 没有被覆盖
"programmer"

Focus on when there is a value, it will fail and return 0. So our code will be transformed into the following.

// 这里是错误代码，只是一个思考过程，请耐心看完哦
String key = "REDIS_DISTRIBUTION_LOCKER"; // 分布式锁名称
Long result = jedisUtils.setNx(key, 1);
if (result > 0) { // 上锁成功，进入逻辑
    // wingzingliu1
    Integer stock = goodsMapper.getStock();
    if (stock > 0) {
        stock =- 1;
        goodsMapper.updateStock(stock);
 
        System.out.println("购买成功!");
    } else {
        System.out.println("没有库存了!");
    }
    // wingzingliu2
    jedisUtils.del(key); // 释放锁
}

With the above, we can ensure atomicity and process them correctly in order.

But there is another hidden problem, that is, after a thread successfully executes the lock, the program throws an exception between wingzingliu1 and wingzingliu2. Then the program terminates and the lock cannot be released. Other threads They can't even get in.

The solution is to add a try catch finally block and release the lock in finally.

But what if it is down? After the lock is locked, the machine crashes. The finally contents will still not be executed. The lock is not released. Without manual processing, all threads will not be able to enter in the future.

So the expiration time of redis is introduced, and it will be automatically unlocked at a certain time.

// 这里是不够完善的代码，请耐心看完哦
try {
    String key = "REDIS_DISTRIBUTION_LOCKER"; // 分布式锁名称
    Long result = jedisUtils.setNx(key, 1, 30); // 假设处理逻辑需要20s左右，设置了30秒自动过期
    if (result > 0) { // 上锁成功，进入逻辑
        Integer stock = goodsMapper.getStock();
        if (stock > 0) {
            stock =- 1;
            goodsMapper.updateStock(stock);
 
            System.out.println("购买成功!");
        } else {
            System.out.println("没有库存了!");
        }
    }
} catch (Exception e) {
    
} finally {
    jedisUtils.del(key); // 释放锁
}

The above is a relatively complete distributed lock, but there is still a small flaw. It is assumed that a certain request A is processed very slowly. It is expected to take 20s but it takes 35s. When it reaches 30s, the lock expires. Other requests came naturally.

This will not only cause a concurrent execution, but also continue to perform the lock release operation after request A is processed, thus actually handing the lock to the next thread. By analogy, the entire concurrency control will be messed up.

Theoretically, you can set a larger key expiration time, but it is not the best solution. Here comes a concept: locking life.

Lock life extension

As the name suggests, give the lock life extension. The implementation is to extend the lock time when the lock is about to expire. Assume a 30 second lock is used, with a check every 10 seconds to see if the lock still exists. If the lock still exists, keep the lock for 30 seconds. This avoids the possible problem above.

A scheduled task is used here and can be called periodically.

Extension

The value just set for the key is 1. In fact, the request ID can be used to save it, so that you can know which request the lock is from, and you can avoid it when unlocking. Locks on other threads are unlocked. It can be passed by the front end, or generated by the server based on certain rules.

The above is the detailed content of How to use Redis to solve high concurrency. For more information, please follow other related articles on the PHP Chinese website!