Concurrency issues in redis
I have been using redis as a cache for a long time, and redis is a single process. When running, the commands are executed one after another. I always thought that there would be no concurrency problems. It was not until I saw the relevant information today that I suddenly realized it (recommended: redis video tutorial)
Specific problem examples
There is a key, assuming the name is myNum, and Arabic numerals are stored in it. Assume that the current value is 1, and there are multiple connections operating on myNum. At this time, There will be concurrency issues. 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 => 1 linkB get myNum => 1 linkA set muNum => 2 linkB set myNum => 2
After executing the operation, the result Probably 2, which is inconsistent with the 3 we expected.
Look at another specific example:
<?php require "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 <2000 Value, this also 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, and only ensures consistency and Isolation, does not satisfy atomicity and durability.
Redis transactions use multi and exec commands
Atomicity, redis will execute all commands in the transaction once, and will not roll back even if there is an execution failure in the middle. Kill signals, host downtime, etc. cause transaction execution to fail, and redis will not retry or roll back.
Persistence, the durability 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 an 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, it will monitor key a. When a After being corrected, subsequent transactions will fail to execute. This ensures that multiple connections come in at the same time, all monitoring a. Only one can execute successfully, and the others all return failures.
127.0.0.1:6379> set a 1 OK 127.0.0.1:6379> watch a OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> incr a QUEUED 127.0.0.1:6379> exec 1) (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 1 OK 127.0.0.1:6379> watch test OK 127.0.0.1:6379> multi OK 127.0.0.1:6379> incrby test 11 QUEUED 127.0.0.1:6379> exec (nil) 127.0.0.1:6379> get test "100"
How to solve my problem
The commands in redis are 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 opens two terminals at the same time After execution, the result is 2000 that meets our expectations.
<?php require "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); }
The method mentioned by @manzilu
The method mentioned by manzilu in the comments was checked after checking the information. 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
After reading so much, To briefly summarize, 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.
For more redis-related articles, please pay attention to the redis database tutorial column.
The above is the detailed content of Solving redis concurrency problems. For more information, please follow other related articles on the PHP Chinese website!