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

This article shows you how to prevent oversold goods from snapping up in redis. The content is concise and easy to understand. It will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Use redis's list for testing

The idea is to set up a redis list List, suppose there are ten items, each request first judge the length of the List, less than ten can grab the goods, the user information will be stored in the List. The code is as follows

/ / panic purchase protected function way_list () {$num = $this- > redis- > lLen (); if ($this- > redis- > lLen () > = self::AMOUNTLIMIT) {$this- > writeLog ("panic purchase failure". $num); return;} else {$this- > redis- > rPush ($num); $this- > writeLog ("snap purchase success". $num);}}

Result: failure!

It can be obvious that the quantity is not right and the order is not right.

The following reasons are analyzed. When the code is executed and multi-users request concurrently, when the first user judges that the List length meets the conditions and does not write List, the second user also passes the List length judgment. So it leads to the failure of execution.

This does not take advantage of the atomicity of redis.

So it was improved.

Use incrby for redis. Incrby will set the value of key to increase the specified increment and return the value after the increment. It's an atomic operation. The so-called atomic operation is either success or failure after the implementation of the method.

The idea is to set a key value pair to store the quantity to be snapped up, and each time a user comes in, the value will be added one to judge, if it is less than the number of goods snapped up, the rush purchase will succeed, otherwise it will fail. The code is as follows

Protected function way_string () {/ / determine whether if (! $this- > redis- > exists (self::sold_name)) {$this- > redis- > setnx (self::sold_name,0);} if ($this- > redis- > incrby (self::sold_name,1) > self::AMOUNTLIMIT) {$this- > writeLog ('failure');} else {$this- > writeLog ('success');}}

Result

There was no problem after several stress tests.

Through the ab stress test of apache, there were 500 connection requests and 300 concurrent requests, and there was no oversold behavior.

Summary: the occurrence of oversold is mainly due to the fact that when the user requests, the code is executed in order, which will lead to the execution result that does not meet the expectations. The atomicity of redis can be avoided.

The above content is how to prevent panic buying goods from being oversold in redis. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

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.