In-depth understanding of the use of Spring Redis (ix), the BUG of implementing distributed locks via Redis, and performance testing with database locking

In a multi-node project, it is often related to some method lock control. At this time, the easy-to-use synchronized has been unable to meet the multi-node deployment structure.

Earlier in the project, more of the database's update locks were used: for udpate. But this has a disadvantage, that is, it is prone to bottlenecks in the database, resulting in greater pressure. At the same time, if the statement of the lock table, the table data volume is particularly large, the basic server directly down.

So, decide to bypass the database and use Redis directly to implement distributed locks. Check the information, find some articles, the idea is consistent:

Http://www.jeffkit.info/2011/07/1000/

http://my.oschina.net/u/1995545/blog/366381

In this article, we use the Spring AOP annotation method to implement multi-node locking of the method.

The previous article gave the implementation code. There is no difficulty, note +AOP.

But today, when I was doing stress tests, I found this to be a big problem.

Test environment:

1000 threads, executed 1 times per thread. (This is closer to the real Tomcat environment)

Sleep time and execution time:

* 20ms approximately equals CPU thread switching time, 59998
* 50ms 43177
* 100ms 20555
* 150ms 7014
* 200ms 2970 Performance is fair

However, if you set 200ms, it is possible that some threads, from the very beginning of blocking constantly sleep, to the end of all, only to get the lock. If the program does not end, then the thread has been blocked and cannot predict how long it will take to get the lock. If you go to set the wait for how long time out disconnects, then frequent failure, for the user is certainly unacceptable.

And then we test the database lock.

A table of 70W data,

With the PK row-level lock, the execution time 1163 (in case the lock data needs to exist, the corresponding lock can be added), and if each thread is a separate data row, it is quicker to block each other. SSD SSD ... )

Through the other list lock, one second to perform the feeling that the direct card dead, stop the test

So, waiting through sleep, high concurrency, will cause some threads to get out of control.

Wait notify, however, is for a single node to be used.

You can also do the finest granularity, and then use Redis to lock, which reduces the likelihood of thread blocking.

Summarize:

Either use blocking to schedule the thread,

You can either implement a reactor pattern that is similar to NIO in a distributed environment to dispatch.

Ensure first-in, first-out, even if some slow state, not first come to the contrary, causing poor user experience.

In-depth understanding of the use of Spring Redis (ix), the BUG of implementing distributed locks via Redis, and performance testing with database locking