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

This article introduces the relevant knowledge of "Redis concurrency problem". Many people will encounter such a dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Redis concurrency problem

Redis is a single-process single-thread mode, using queue mode to change concurrent access into serial access. Redis itself does not have the concept of lock, and Redis does not compete for multiple client connections, but problems such as connection timeout, data conversion errors, blocking, and client closure occur when Jedis clients access Redis concurrently, all of which are caused by client connection confusion. There are two solutions to this:

1. From the client point of view, in order to ensure that each client communicates with Redis in a normal and orderly manner, the connection is pooled, and the internal lock synchronized is used to read and write Redis on the client.

two。 From the server point of view, the lock is realized by using setnx.

For the first, the application needs to handle the synchronization of resources on its own, and the methods you can use are more common, you can use synchronized or lock;, the second setnx command that requires Redis, but you need to pay attention to some problems.

SETNX command (SET if Not eXists)

Syntax:

SETNX key value

Features:

Set the value of key to value if and only if key does not exist; if the given key already exists, SETNX does not take any action.

Time complexity:

O (1)

Return value:

If the setting is successful, return 1.

Setting failed and 0 was returned.

Mode: using SETNX for locking (locking)

SETNX can be used as a lock primitive (locking primitive). For example, to lock the keyword (key) foo, the client can try the following:

SETNX lock.foo

If SETNX returns 1, the client has acquired the lock, and the unix time set by key specifies when the lock expires. The client can then release the lock through DEL lock.foo.

If SETNX returns 0, key is already locked by another client. If the lock is non blocking lock, we can choose to return the call or enter a retry loop until the lock is successfully acquired or the retry timeout (timeout).

However, it has been proved that only using SETNX locking has a competitive condition, which can lead to errors under certain circumstances.

Handling deadlocks (deadlock)

The above locking algorithm has a problem: what if the lock cannot be released due to client failure, crash, or other reasons?

This condition can be detected by detection-- because the locked key holds the unix timestamp, and if the timestamp of the key value is less than the current timestamp, the lock is no longer valid.

However, when multiple clients simultaneously detect whether a lock has expired and try to release it, we cannot simply rudely delete the deadlock key and lock it with SETNX, because the race condition (race condition) has already been formed:

C1 and C2 read the lock.foo and check the timestamp, and SETNX returns 0 because it is locked by C3, but C3 crashes (crashed) after it is locked.

C1 sends a DEL command to lock.foo.

C1 sends SETNX to lock.foo and succeeds.

C2 sends the DEL command to lock.foo.

C2 sends SETNX to lock.foo and succeeds.

Error: both C1 and C2 have acquired the lock because of competitive conditions.

Fortunately, the following algorithms can avoid the above problems. Let's see what our smart C4 client will do:

C4 sends SETNX commands to lock.foo.

Because crashed C3 still locks lock.foo, Redis returns 0 to C4.

C4 sends a GET command to lock.foo to see if the lock on lock.foo expires. If not, sleep (sleep) for a period of time and try again later.

On the other hand, if the unix timestamp in lock.foo is older than the current timestamp, C4 executes the following command:

GETSET lock.foo

Because of GETSET, C4 can check the return value of GETSET to determine that the old value stored before lock.foo is still the expiration timestamp, and if so, C4 acquires the lock.

If other clients, such as C5, perform GETSET operations and acquire locks faster than C4, then C4's GETSET operation returns an unexpired timestamp (the timestamp set by C5). C4 had to retry from the first step.

Note that even if C4's GETSET operation modifies key, it will have no impact on the future.

It is assumed that the value corresponding to the lock key has no actual business significance, otherwise there will be problems, and in fact, its value should not be used in the business.

To make this locking algorithm more robust, the client that acquires the lock should always check the expiration time to prevent the lock from being unlocked accidentally due to the execution of commands such as DEL, because the failure of the client is very complex, not just a crash, but it is also possible that the client has been blocked for a long time because of some operation, and then the DEL command is tried to execute (but the lock is in the hands of another client at this time).

GETSET command

Syntax:

GETSET key value

Features:

Sets the value of the given key to value and returns the old value of key (old value). Returns an error when key exists but is not a string type.

Time complexity:

O (1)

Return value:

Returns the old value of a given key, or nil when key has no old value, that is, if key does not exist.

This is the end of "Redis concurrency issues". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.