redis多個執行緒操作單個key場景的併發問題
redis多個執行緒操作單個key場景的併發問題
2016年10月18日 10:00:18 琅琊山二當家 閱讀數：13262
版權宣告：微信公眾號 java架構獅 歡迎轉載 請註明出處 https://blog.csdn.net/AlbertFly/article/details/52846190
redis是單執行緒的，
出併發問題只可能是邏輯上有漏洞，
比如先取再寫 , 可以採用某種方式規避
比如multi /exec 事務
比如
Redis Exec 命令用於執行所有事務塊內的命令。
redis Exec 命令基本語法如下：
redis 127.0.0.1:6379> Exec127.0.0.1:6379> Exec可用版本
>= 1.2.0
返回值
事務塊內所有命令的返回值，按命令執行的先後順序排列。 當操作被打斷時，返回空值 nil 。
例項
# 事務被成功執行 redis 127.0.0.1:6379> MULTI OK redis 127.0.0.1:6379> INCR user_id QUEUED redis 127.0.0.1:6379> INCR user_id QUEUED redis 127.0.0.1:6379> INCR user_id QUEUED redis 127.0.0.1:6379> PING QUEUED redis 127.0.0.1:6379> EXEC 1) (integer) 1 2) (integer) 2 3) (integer) 3 4) PONG # 監視 key ，且事務成功執行 redis 127.0.0.1:6379> WATCH lock lock_times OK redis 127.0.0.1:6379> MULTI OK redis 127.0.0.1:6379> SET lock "huangz" QUEUED redis 127.0.0.1:6379> INCR lock_times QUEUED redis 127.0.0.1:6379> EXEC 1) OK 2) (integer) 1 # 監視 key ，且事務被打斷 redis 127.0.0.1:6379> WATCH lock lock_times OK redis 127.0.0.1:6379> MULTI OK redis 127.0.0.1:6379> SET lock "joe" # 就在這時，另一個客戶端修改了 lock_times 的值 QUEUED redis 127.0.0.1:6379> INCR lock_times QUEUED redis 127.0.0.1:6379> EXEC # 因為 lock_times 被修改， joe 的事務執行失敗 (nil)redis 127.0.0.1:6379> MULTI OK redis 127.0.0.1:6379> INCR user_id QUEUED redis 127.0.0.1:6379> INCR user_id QUEUED redis 127.0.0.1:6379> INCR user_id QUEUED redis 127.0.0.1:6379> PING QUEUED redis 127.0.0.1:6379> EXEC 1) (integer) 1 2) (integer) 2 3) (integer) 3 4) PONG # 監視 key ，且事務成功執行 redis 127.0.0.1:6379> WATCH lock lock_times OK redis 127.0.0.1:6379> MULTI OK redis 127.0.0.1:6379> SET lock "huangz" QUEUED redis 127.0.0.1:6379> INCR lock_times QUEUED redis 127.0.0.1:6379> EXEC 1) OK 2) (integer) 1 # 監視 key ，且事務被打斷 redis 127.0.0.1:6379> WATCH lock lock_times OK redis 127.0.0.1:6379> MULTI OK redis 127.0.0.1:6379> SET lock "joe" # 就在這時，另一個客戶端修改了 lock_times 的值 QUEUED redis 127.0.0.1:6379> INCR lock_times QUEUED redis 127.0.0.1:6379> EXEC # 因為 lock_times 被修改， joe 的事務執行失敗 (nil)
’外可以用lua 指令碼做原子性順序執行類似 multi/exec
奔跑的Man天生的黑------redis併發問題
redis中的併發問題
使用redis作為快取已經很久了，redis是以單程序的形式執行的，命令是一個接著一個執行的，一直以為不會存在併發的問題，直到今天看到相關的資料，才恍然大悟~~
具體問題例項
有個鍵，假設名稱為myNum，裡面儲存的是阿拉伯數字，假設現在值為1，存在多個連線對myNum進行操作的情況，這個時候就會有併發的問題。假設有兩個連線linkA和linkB，這兩個連線都執行下面的操作，取出myNum的值，+1，然後再存回去，看看下面的互動：
linkA get myNum => 1
linkB get myNum => 1
linkA set muNum => 2
linkB set myNum => 2執行完操作之後，結果可能是2，這和我們預期的3不一致。
再看一個具體的例子：
<?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);
}設定name初始值為0，然後同時用兩個終端執行上面的程式，最後name的值可能不是2000，而是一個<2000的值，這也就證明了我們上面的併發問題的存在，這個該怎麼解決呢？
redis中的事務
redis中也是有事務的，不過這個事務沒有mysql中的完善，只保證了一致性和隔離性，不滿足原子性和永續性。
redis事務使用multi、exec命令
原子性，redis會將事務中的所有命令執行一遍，哪怕是中間有執行失敗也不會回滾。kill訊號、宿主機宕機等導致事務執行失敗，redis也不會進行重試或者回滾。
永續性，redis事務的永續性依賴於redis所使用的持久化模式，遺憾的是各種持久化模式也都不是持久化的。
隔離性，redis是單程序，開啟事務之後，會執行完當前連線的所有命令直到遇到exec命令，才處理其他連線的命令。
一致性，看了文件，覺得挺扯的，但是貌似說的沒有問題。
redis中的事務不支援原子性，所以解決不了上面的問題。
當然了redis還有一個watch命令，這個命令可以解決這個問題，看下面的例子，對一個鍵執行watch，然後執行事務，由於watch的存在，他會監測鍵a，當a被修該之後，後面的事務就會執行失敗，這就確保了多個連線同時來了，都監測著a，只有一個能執行成功，其他都返回失敗。
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"失敗時候的例子，從最後可以看出，test的值被其他連線修改了：
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"我的問題如何解決
redis中命令是滿足原子性的，因此在值為阿拉伯數字的時候，我可以將get和set命令修改為incr或者incrby來解決這個問題，下面的程式碼開啟兩個終端同時執行，得到的結果是滿足我們預期的2000。
<?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);
}@manzilu 提到的方法
評論中manzilu提到的方法查了下資料，確實可行，效果還不錯，這裡寫了個例子
<?php
require "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";
執行shell php setnx.php & php setnx.php&，最後會得到結果：
$ 花費時間 ： 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同樣迴圈1w次，去掉usleep，使用incr直接進行增加，耗時在2s左右。
而獲取所得時候取消usleep，時間不但沒減少，反而增加了，這個usleep的設定要合理，免得程序做無用的迴圈
總結
看了這麼多，簡單的總結下，其實redis本事是不會存在併發問題的，因為他是單程序的，再多的command都是one by one執行的。我們使用的時候，可能會出現併發問題，比如get和set這一對。
2016-8-22 20:31:30