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

1. Preface

Why build locks? Because building an appropriate lock can maintain data consistency under high concurrency, that is, the data locked by the client when executing coherent commands will not be changed by other clients. At the same time, it can also ensure the success rate of command execution.

When you see this, you can't help but ask, isn't there a transaction operation in redis? Can't transaction operations implement the above functions?

Indeed, transactions in redis can watch to monitor data, so as to ensure the consistency of data during coherent execution, but we must clearly realize that when multiple clients process the same data at the same time, it is easy to cause transaction execution failure, and even lead to data errors.

In a relational database, the user first sends BEGIN to the database server, then performs various consistent write and read operations, and finally the user can choose to send COMMIT to confirm the previous changes, or send ROLLBACK to roll back.

In redis, it starts with a special command MULTI, then the user passes in a continuous command, and ends with EXEC (you can use watch to monitor some key in the process). Further analysis shows that the commands in the redis transaction are pushed into the queue first, and the commands are not executed until the EXEC command appears. If the key monitored by watch changes, the transaction will fail. This means that there is no lock in the Redis transaction, and other clients can modify the relevant data in the transaction, which is why transactions tend to have errors when multiple clients process the same data at the same time.

Back to the top.

2. Simply understand the single-thread IO multiplexing of redis

Redis adopts single thread IO multiplexing model to realize high memory data service. What is single-thread IO multiplexing? From the literal meaning, we can see that redis uses single thread and uses multiple IO. The whole process is simply that the data stream of a command arrives first and executes first.

Please take a look at the image understanding picture below: the picture is a narrow bridge, which can only allow one car to pass, and on the left is the channel for vehicles to enter. Which car arrives first will enter first. That is, which IO stream arrives first will be processed first.

Under Linux, the network IO uses socket sockets to communicate. The ordinary IO model can only listen to one socket, while IO multiplexing can monitor multiple socket at the same time. IO multiplexing avoids blocking on the IO, and a single thread saves the state of multiple socket and then round robin processing.

Back to the top.

3. Concurrent testing

Let's simulate a simple and typical concurrent test, and then draw a problem from this test for further study.

Concurrency testing ideas:

1. Set a string count in redis, use the program to take it out and add + 1, then store it back, and loop it 100, 000 times.

2. Execute this code on both browsers at the same time

3. Take out the count and view the results

Test steps:

1. Establish the test.php file

one

2. Access the test.php file in two browsers

As you can see from the above figure, for a total of two times, count was supposed to be 200000, but in fact, count is equal to more than 130000, far less than 200000. Why?

As can be seen from the previous content, redis uses a single-thread IO multiplexing model. Therefore, we use two browsers for two sessions (A, B). Taking out, adding 1, and saving these three commands are not atomic operations, and which client is the first to arrive and execute when executing the two redis commands.

For example: 1. Count=120 at this time

2. A takes out the count=120, and then the take-out command of B flows to the count=120.

3. Add 1 immediately after An is taken out, and save the count=121 back

4. At this time, B also followed and saved the count=121.

Note:

1. If the number of loops is as large as possible, if it is too small, when the execution of the first browser is finished, the second browser has not yet started.

2. Two browsers must execute at the same time. If you execute the test.php file twice in the same browser, regardless of whether it is executed at the same time or not, the end result is count=200000. Because execution in the same browser belongs to the same session (all commands pass through the same channel), redis executes the first 100, 000 times, followed by the other 100, 000 times.

Back to the top.

4. Transaction resolution and atomic operation resolution

Back to the top.

4.1. Transaction resolution

Changed test.php file

one

The execution result failed, and the table name using transaction could not solve this problem.

Analyze the reasons:

We all know that when redis is turned on, the commands in the transaction are not executed, but the commands are pressed into the queue first, and then when the exec command appears, all commands are blocked and executed one by one.

So when you use the Redis class in PHP for redis transactions, all commands related to redis are not actually executed, but are simply sent to redis for storage.

So the $count circled in the following figure is not actually the data we want, but an object, so there are 11 lines of error in test.php.

View the object count:

Back to the top.

4.2.Atomic operation incr solution

# Update test.php file

one

It takes 14 or 15 seconds for two browsers to execute at the same time, count=200000, which can solve this problem.

Disadvantages:

Just to solve the problem of taking out plus 1 here, in essence, can not solve the problem, in the actual environment, what we need to do is a series of operations, not just take out plus 1, so it is necessary to build a universal lock.

Back to the top.

5. Build distributed locks

The purpose of constructing locks is to eliminate selection competition and maintain data consistency under high concurrency.

When constructing locks, we need to pay attention to a few issues:

1. Prevent the processing holding lock when the process crashes when performing the operation, resulting in a deadlock. Other processes have not been able to get this lock.

2. The lock-holding process automatically releases the lock because it takes a long time to operate, but the own process does not know it, and finally mistakenly releases the locks of other processes

3. After one process lock expires, several other processes try to acquire the lock at the same time, and all acquire the lock successfully

Instead of modifying the test.php file, we will directly establish a relatively standard object-oriented Lock.class.php class file.

# create Lock.class,php file

one

Test results:

Executed in two different browsers, the final result is count=200000, but it takes a relatively long time and takes about 80 seconds. However, under high concurrency, it is acceptable, or even good, to release locks 200,000 times for the same data.

The simple example above is just to simulate concurrent testing and verify. In fact, we can use the lock in Lock.class.php to modify it with our own project to make good use of it. For example, the shopping spree in the mall, the game virtual mall players buy and sell things and so on.

(the above are some of my own opinions. If there are any deficiencies or mistakes, please point them out.)

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.