Concurrency issues in redis
I have been using redis as a cache for a long time. Redis runs as a single process, and commands are executed one after another. I thought there would be no concurrency problems, but it wasn’t until I saw the relevant information today that I suddenly realized it.
Specific problem example
There is a key, assuming the name is myNum, and Arabic numerals are stored in it. Assume the current value is 1. If there are multiple connections operating on myNum, there will be concurrency problems. Suppose there are two connections linkA and linkB. Both connections perform the following operations, take out the value of myNum, 1, and then save it back to see the following interaction:
linkA get myNum => 1linkB get myNum => 1linkA set muNum => 2linkB set myNum => 2
After performing the operation, the result Probably 2, which is inconsistent with the 3 we expected.
Look at a specific example:
<?phprequire "vendor/autoload.php";$client = new Predis\Client([ 'scheme' => 'tcp', 'host' => '127.0.0.1', 'port' => 6379,]);for ($i = 0; $i < 1000; $i++) { $num = intval($client->get("name")); $num = $num + 1; $client->setex("name", $num, 10080); usleep(10000);}
Set the initial value of name to 0, and then use two terminals to execute the above program at the same time. The final value of name may not be 2000, but a < ;The value of 2000 proves the existence of our above concurrency problem. How to solve this?
Transactions in redis
There are also transactions in redis, but this transaction is not as perfect as in mysql. It only guarantees consistency and isolation and does not satisfy atomicity. sex and durability.
redis transactions use multi, execcommands
atomicity, redis will execute all commands in the transaction, even if there are executions in the middle There will be no rollback on failure. Kill signals, host downtime, etc. cause transaction execution to fail, and redis will not retry or roll back.
Persistence, the persistence of redis transactions depends on the persistence mode used by redis. Unfortunately, various persistence modes are not persistent.
Isolation, redis is a single process. After starting a transaction, all commands of the current connection will be executed until the exec command is encountered, and then commands of other connections will be processed.
Consistency, after reading the document, I think it’s quite ridiculous, but it seems to be correct.
Transactions in redis do not support atomicity, so the above problem cannot be solved.
Of course redis also has a watch command, which can solve this problem. See the following example, execute watch on a key, and then execute the transaction. Due to the existence of watch, he will Monitor key a. When a is repaired, subsequent transactions will fail to execute. This ensures that multiple connections come at the same time, all monitoring a. Only one can execute successfully, and the others will return failure.
127.0.0.1:6379> set a 1OK127.0.0.1:6379> watch aOK127.0.0.1:6379> multi OK127.0.0.1:6379> incr aQUEUED127.0.0.1:6379> exec1) (integer) 2 127.0.0.1:6379> get a"2"
Example of failure, from the end it can be seen that the value of test was modified by other connections:
127.0.0.1:6379> set test 1OK127.0.0.1:6379> watch testOK127.0.0.1:6379> multiOK127.0.0.1:6379> incrby test 11QUEUED127.0.0.1:6379> exec(nil) 127.0.0.1:6379> get test"100"
How to solve the problem
redis The command in is atomic, so when the value is an Arabic numeral, I can change the get and set commands to incr or incrby to solve this problem. The following code enables two terminals to be executed at the same time. The result is that we Expected 2000.
<?phprequire "vendor/autoload.php";$client = new Predis\Client([ 'scheme' => 'tcp', 'host' => '127.0.0.1', 'port' => 6379,]);for ($i = 0; $i < 1000; $i++) { $client->incr("name"); $client->expire("name", 10800); usleep(10000);}
It is indeed feasible and the effect is not bad. Here is an example
<?phprequire "vendor/autoload.php";$client = new Predis\Client([ 'scheme' => 'tcp', 'host' => '127.0.0.1', 'port' => 6379,]);class RedisLock{ public $objRedis = null; public $timeout = 3; /** * @desc 设置redis实例 * * @param obj object | redis实例 */ public function __construct($obj) { $this->objRedis = $obj; } /** * @desc 获取锁键名 */ public function getLockCacheKey($key) { return "lock_{$key}"; } /** * @desc 获取锁 * * @param key string | 要上锁的键名 * @param timeout int | 上锁时间 */ public function getLock($key, $timeout = NULL) { $timeout = $timeout ? $timeout : $this->timeout; $lockCacheKey = $this->getLockCacheKey($key); $expireAt = time() + $timeout; $isGet = (bool)$this->objRedis->setnx($lockCacheKey, $expireAt); if ($isGet) { return $expireAt; } while (1) { usleep(10); $time = time(); $oldExpire = $this->objRedis->get($lockCacheKey); if ($oldExpire >= $time) { continue; } $newExpire = $time + $timeout; $expireAt = $this->objRedis->getset($lockCacheKey, $newExpire); if ($oldExpire != $expireAt) { continue; } $isGet = $newExpire; break; } return $isGet; } /** * @desc 释放锁 * * @param key string | 加锁的字段 * @param newExpire int | 加锁的截止时间 * * @return bool | 是否释放成功 */ public function releaseLock($key, $newExpire) { $lockCacheKey = $this->getLockCacheKey($key); if ($newExpire >= time()) { return $this->objRedis->del($lockCacheKey); } return true; } }$start_time = microtime(true);$lock = new RedisLock($client);$key = "name";for ($i = 0; $i < 10000; $i++) { $newExpire = $lock->getLock($key); $num = $client->get($key); $num++; $client->set($key, $num); $lock->releaseLock($key, $newExpire);}$end_time = microtime(true);echo "花费时间 : ". ($end_time - $start_time) . "\n";
Execute shell php setnx.php & php setnx.php&, and you will finally get the result:
$ 花费时间 : 4.3004920482635 [2] + 72356 done php setnx.php# root @ ritoyan-virtual-pc in ~/PHP/redis-high-concurrency [20:23:41] $ 花费时间 : 4.4319710731506 [1] + 72355 done php setnx.php
Similarly loop 1w times, remove usleep, and use incr to increase directly, which takes about 2 seconds.
When canceling usleep when obtaining the income, the time not only does not decrease, but increases. The setting of usleep must be reasonable to prevent the process from making useless loops
Summary
To summarize briefly, in fact, redis does not have concurrency problems, because it is a single process, and no matter how many commands are executed, they are executed one by one. When we use it, concurrency problems may occur, such as the pair of get and set.
The above is the detailed content of What is the maximum concurrency of redis?. For more information, please follow other related articles on the PHP Chinese website!