How to solve the timeout and oversold problems in the flash sale scenario in Redis

Timeout

1.Redis connection timeout reason

(1) Configuration issues in the virtual machine

When we test the remote connection to see whether the redis connection is successful, the console The following errors may be reported.
As shown below:

#I get a headache every time I see the red text on the console. . .

The display in the console probably means that the connection timeout caused the failure.
The following three reasons for connection failure are summarized:

• The firewall in Linux is not closed and causes failure.

• redis needs to be opened.

• bind 127.0.01 in redis.conf needs to be commented out, and then protected-mode no needs to be modified.

If you encounter the above problems in the future, please look it up yourself.

(2) Simulate the timeout in high concurrency during redis successful connection

As shown in the figure:

2. Solution

You may find connection timeout problems when using jdbc in MySQL, so we use database connection pools to solve the problem, such as druid, c3p0, etc. In the same way, we can also use the database connection pool in redis.
Save the consumption caused by each connection to the redis service and reuse the connected instances.

Manage connection behavior through parameters

Go directly to the Notepad code!

Link pool parameters:

• MaxTotal: Control how many jedis instances a pool can be allocated through pool.getResource() Obtain; if the value is -1, it means no limit; if the pool has been allocated MaxTotal jedis instances, the status of the pool at this time is exhausted.

• maxIdle: Controls the maximum number of jedis instances in idle state in a pool;

• MaxWaitMillis: Indicates when borrowing a jedis instance, the maximum number of milliseconds to wait. If the waiting time is exceeded, JedisConnectionException will be thrown directly;

• testOnBorrow: Whether to check connection availability (ping()) when obtaining a jedis instance; if If true, the obtained jedis instances are all available;

Oversold

1. Flash kill oversold phenomenon

In high concurrency scenarios , multiple threads update the inventory concurrently, resulting in a negative inventory situation.

Look at pictures and imagine:

2. Solution

(1) Use optimistic locking to eliminate users and solve the overselling problem

Above picture:

//增加乐观锁
jedis.watch(qtkey);
 
//3.判断库存
String qtkeystr = jedis.get(qtkey);
if(qtkeystr==null || "".equals(qtkeystr.trim())) {
	System.out.println("未初始化库存");
	jedis.close();
	return false ;
}
 
int qt = Integer.parseInt(qtkeystr);
if(qt<=0) {
	System.err.println("已经秒光");
	jedis.close();
	return false;
}
 
//增加事务
Transaction multi = jedis.multi();
 
//4.减少库存
//jedis.decr(qtkey);
multi.decr(qtkey);
 
//5.加人
//jedis.sadd(usrkey, uid);
multi.sadd(usrkey, uid);
 
//执行事务
List<Object> list = multi.exec();
 
//判断事务提交是否失败
if(list==null || list.size()==0) {
	System.out.println("秒杀失败");
	jedis.close();
	return false;
}
System.err.println("秒杀成功");
jedis.close();	

##Principle of the scheme:

(1) When the user purchases, the inventory is monitored through watch. If the inventory changes after watch monitoring, the exception will be caught and the operation of decrementing the inventory by one will be given up.

(2) If no changes are monitored in the inventory and the quantity is greater than one, the inventory is reduced by one and the task is executed.
Disadvantages

When Redis tries to complete a transaction, it may repeatedly try to re-execute it due to the failure of the transaction

It is very important to ensure that the inventory of goods is correct, but simply Using a mechanism like WATCH puts too much pressure on the server

(2) Using the watch multi setnx command of reids to implement

Why do you need to build the lock yourself?

Although there are similar SETNX commands that can implement the lock function in Redis, the mechanism provided by other locks is not complete

And setnx does not have some advanced features of distributed locks, so we still have to pass it through Build manually.

(1) Create a redis lock

In Redis, you can build a lock by using the SETNX command: rs.setnx(lock_name, uuid value)

What the lock does It is to set a randomly generated 128-bit UUID to the value of the bit key to prevent the lock from being acquired by other processes.

(2) Release the lock

The deletion operation of the lock is very simple. You only need to judge and verify the uuid result obtained by the key value of the corresponding lock.

Meet the conditions (judge the uuid value) Just delete it in redis through delete, rs.delete(lockname)
In addition, when other users hold the same lock, due to the different uuid, other people's locks will not be released by mistake after verification.

(3) Solve the problem that the lock cannot be released

In the previous locks, there was also such a problem. For example, a process suddenly crashed after holding the lock, which would cause the lock to be unable to be released
and other processes could not hold the lock and continue working. In order to solve this problem Question, you can add the lock timeout function when acquiring the lock.

The above is the detailed content of How to solve the timeout and oversold problems in the flash sale scenario in Redis. For more information, please follow other related articles on the PHP Chinese website!