PHP 如何在Redis中实现事物(事物提交和事物回滚)

傷城~ 2023-10-18 09:42 96阅读 0赞

讲了这么多Redis的使用，今天我们来讲下Redis的事物  
1.首先，我们来看一下Redis中事物相关的指令,  
命令原型 命令描述  
MULTI 用于标记事务的开始，其后执行的命令都将被存入命令队列，直到执行EXEC时，这些命令才会被原子执行.

EXEC 执行在一个事务内命令执行了WATCH命令，那么只有当WATCH所监控的keys没有被修改的前提下，EXEC命令才能执行事务队列中的所有命令，那么只有  
当WATCH所监控的keys没有被修改的前提下，EXEC命令才能执行事务队列中的所有命令，否则EXEC将放弃当前事务中的所有命令。

DISCARD 回滚事务队列中的所有命令，同时再将当前连接的状态恢复为正常状态，即非事务状态。如 果WATCH命令被使用，该命令将UNWATCH所有的keys.

WATCH key\[key...\] 在MULTI命令执行之前，可以指定待监控的keys，然而在执行EXEC之前，如果被监控的keys发生修改，EXEC将放弃执行该事务队列中的所有指令。

UNWATCH 取消当前事务中指定监控的keys，如果执行了EXEC或DISCARD命令，则无需再手工执行 该命令了，因为在此之后，事务中所有的keys都将自动取消，  
和关系型数据库中的事物相比，在redis事物中如果有某一条命令执行失败，其后的命令仍然会被继续执行。

我们可以通过MULTI命令开启一个事务，有关系型数据库开发经验的人可以理解为BEGIN TRANSACTION语句，在该语句之后执行的命令都将被视为事务之内的操作，最后我  
们可以通过执行EXEC/DISCARD命令来提交/回滚该事务内的所有操作。这两个Redis命令可被视为等同于关系型数据库中的COMMIT/ROLLERBACK语句。

在事物开启之前，如果客户端与服务端之间出现通讯故障并导致网络断开,其后所有带执行的语句都将不会被服务器执行，然而如果网络中短事件是在客户端执行EXEC命令之后，那么该事务中所有命令都会被服务器执行。

当使用Append-Only模式时，Redis会通过调用系统函数write将该事物内的所有写操作在本次调用全部写入磁盘。然而如果在写入的过程中会出现系统崩溃，如电源故障导致的宕机，那么此时也许只有部分数据被写入到磁盘，而另外一部分数据却已经丢失，Redis服务会在重新启动时执行一系列必要的一致性检测，一旦发现类似问题，就会立即退出并给出相应的错误提示。此刻，我们就要充分利用Redis工具包中提供的Redis-check-aof工具，该工具可以帮助我们定位到数据不一致的错误，并将已经写入的部分数据进行回滚。修复之后我们就可以再次重新启动Redis服务器。

WATCH 命令  
WATCH为MULTI执行之前的某个key提供监控(乐观锁)的功能，如果key的值发生了变化，就会放弃事务的执行。

当事务EXEC执行成功之后，就会自动UNWATCH。  
下面我们根据一个命令行指令来看一下：  
(1)第一步：  
127.0.0.1:6379> redis-cli -h 127.0.0.1 -p 6379 //命令拼接redis服务器  
ok  
127.0.0.1:6379> get test //获取test的键值  
"hello world"  
127.0.0.1:6379> multi //生成事务  
ok  
127.0.0.1:6379> set test "hello mygod" //修改指令  
QUEUED  
127.0.0.1:6379>exec //提交事务  
1) OK  
127.0.0.1:6379>

从上面的命令执行，我们可以看出，当我们生成事务后，执行set指令时，反馈的信息是QUEUED，最后我们再执行  
exec，这些命令才会真正的执行。在这里可能还会有人说事务中还有一个rollback操作，但是redis里面好像并没有发现，的确，redis里面是没有rollback操作的,下面我们再进行一个例子的演示：  
127.0.0.1:6379>multi  
ok  
127.0.0.1:6379>set test "my name is god"  
QUEUED  
127.0.0.1:6379>lpush testName 99  
QUEEUED  
127.0.0.1:6379>exec  
1)OK  
2)(error) WRONGTYPE Opertion against a key holding the wrong kind of value  
127.0.0.1:6379>

在上面的例子中故意用lpush命令执行string ,可想而知自然不会执行成功，但从结果来看，你看到了，一个OK一个Error，这就违反了事务的原子性，  
redis仅仅是个数据结构服务器，多简单的一件事情，退一万步来说，很明显的错误指令它会直接返回的，比如我故意把lpush 写成了lpush1:  
127.0.0.1:6379>multi  
OK  
127.0.0.1:6379> set test "woqunimeimeide"  
QUEUED  
127.0.0.1:6379> lpush1 testName 44  
(error) ERR unknow command 'lpush1'  
127.0.0.1:6379>

上面可以看到，命令终止了你的任何输入。

下面我们探索一下Redis事务的原理：  
关于事务操作的源代码，大多数都在redis源码中的multi.c文件中，接下来我会一个一个简单剖析一下：  
1.multi  
在redis的源码中，它大概是这么写的：  
void multiCommand(redisClient \*c)  
\{  
if(c->flags & REDIS\_MULTI)\{  
addReplyError(c,"MULTI calls can not be nested");  
return;  
\}  
c->flags |= REDIS\_MULTI;  
addReply(c,shared.ok);  
\}

2.生成命令  
在redisClient 中，里面有一个multiState命令：  
typedef struct redisClient\{  
。。。  
multiState mstate; /\* MULTI/EXEC state \*/  
\}redisClient;

从注释中我们看到了命令和multi/exec肯定有关系，接下来我很好奇的看看multiState的定义：  
typedef struct multiState\{  
multiState \*command; /\*\* Array of MULTI commands \*/  
int count ; /\*Total number of MULTI comands\*/  
int minreplicas; /\*MINREPLICAS for synchronous as unixtime \*/  
time\_t minreplicas\_timeout /\*MINREPLICAS timeout as unixtime\*/  
\}multiState;

从multiState这个举例中，你可以看到下面有一个\*commad命令，从注释中我们可以看到它其实指向一个数组，这个数组就是若干条在指令，下面还有一个count，可以看到是实际的command的总数。

3.watch  
为了方便说一下后面的exec,这里想说一下watch 大概是怎样实现的，在multi.c源码中是这样写的：  
typedef struct watchedKey \{  
robj \*key;  
redisDb \*db;  
\} watchedKey;

void watchCommand(redisClient \*c) \{  
int j;

if (c->flags & REDIS\_MULTI) \{  
addReplyError(c,"WATCH inside MULTI is not allowed");  
return;  
\}  
for (j = 1; j < c->argc; j++)  
watchForKey(c,c->argv\[j\]);  
addReply(c,shared.ok);  
\}

/\* Watch for the specified key \*/  
void watchForKey(redisClient \*c, robj \*key) \{  
list \*clients = NULL;  
listIter li;  
listNode \*ln;  
watchedKey \*wk;

/\* Check if we are already watching for this key \*/  
listRewind(c->watched\_keys,&li);  
while((ln = listNext(&li))) \{  
wk = listNodeValue(ln);  
if (wk->db == c->db && equalStringObjects(key,wk->key))  
return; /\* Key already watched \*/  
\}  
/\* This key is not already watched in this DB. Let's add it \*/  
clients = dictFetchValue(c->db->watched\_keys,key);  
if (!clients) \{  
clients = listCreate();  
dictAdd(c->db->watched\_keys,key,clients);  
incrRefCount(key);  
\}  
listAddNodeTail(clients,c);  
/\* Add the new key to the list of keys watched by this client \*/  
wk = zmalloc(sizeof(\*wk));  
wk->key = key;  
wk->db = c->db;  
incrRefCount(key);  
listAddNodeTail(c->watched\_keys,wk);  
\}  
这段代码中最大的核心点就是：

/\* This key is not already watched in this DB. Let's add it \*/  
clients = dictFetchValue(c->db->watched\_keys,key);

关于这个key的所有client ，最后还会塞入到redisclientde watched\_keys字典中，如下代码：

/\* Add the new key to the list of keys watched by this client \*/  
wk = zmalloc(sizeof(\*wk));  
wk->key = key;  
wk->db = c->db;  
incrRefCount(key);  
listAddNodeTail(c->watched\_keys,wk);

如果画图大概就是下面这样：

其中watched\_key是个字典结构，字典的键为上面的key1,key2....,,value为client的链表，这样的话，就可以非常的清楚知道某个key中是被哪些client监视着的。

4.exec  
这个命令大概做了两件事：  
<1>:判断c-flags = REDIS\_DIRTY\_EXEC 打开与否，如果是的话，取消事务discardTransation(c)，也就是说这个key已经被别的client修改了。  
<2>:如果没有修改，那么就for循环执行command\[\]中命令，如图所示的两处信息：

接下来是一段在php中使用Redis事务的案例：

//关于redis事务的案例  
header("content-type:text/html;charset=utf-8");  
$redis = new redis();  
$redis->connect('localhost', 6379);  
//$result = $redis->connect('localhost', 6379);

//$redis = Yii::app()->redis;  
$redis->set("testName","33");  
//$mywatchkey = $redis->get("mywatchkey");

$mywatchkey = $redis->get('testName');  
//($test);exit;

$rob\_total = 100; //抢购数量  
if($mywatchkey<$rob\_total)\{  
$redis->watch("testName");  
$redis->multi();

//设置延迟，方便测试效果。  
sleep(5);  
//插入抢购数据  
$redis->hSet("testName","user\_id\_".mt\_rand(1, 9999),time());  
$redis->set("testName",$mywatchkey+1);  
$rob\_result = $redis->exec();  
if($rob\_result)\{  
$mywatchlist = $redis->hGetAll("testName");  
echo "抢购成功！<br/>";  
echo "剩余数量：".($rob\_total-$mywatchkey-1)."<br/>";  
echo "用户列表：<pre>";  
var\_dump($mywatchlist);  
\}else\{  
echo "手气不好，再抢购！";exit;  
\}  
\}

在上例是一个秒杀的场景，该部分抢购的功能会被并行执行  
通过已销售数量(mywhtchkey)的监控，达到了控制库存，避免超卖的作用。  
WHTCH是一个乐观锁，有利于减少并发中的冲突，提高吞吐量。

乐观锁和共享锁  
乐观锁(Optimistic Lock)又叫做共享锁，每次别人拿数据的时候都认为别人不会修改数据，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读得应用类型，这样会提高吞吐量。

悲观锁(Pessimistic Lock)又叫做排它锁（x锁），每次拿刀数据的时候都认为别人会修改数据，所以每次在拿到数据的时候都会上锁，这样别人想拿到这个数据就会block直到  
它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁，都是在操作之前先上锁。

最后我们介绍一下Redis事务错误处理：  
如果一个事务中的某个命令执行出错，Redis将会怎么处理呢?要回答这个问题，我们首先需要知道是什么原因导致命令执行出错：

1.语法错误：  
语法错误表示命令不存在或者参数错误  
这种情况需要区别Redis版本，Redis2.65之前的版本会忽略错误的命令，执行其他正确的命令，2.65之后的版本会忽略这个事务中的所有命令，都不执行，就比如上面的例子(使用的Redis版本是2.8的)；  
2.运行错误：  
运行错误表示命令执行过程中出现错误，就比如用GET命令去获取一个散列表类型的键值。  
这种错误在命令执行之前Redis是无法发现的，所以在事务里这样的命令都会被Redis接受并执行.如果事务里有一条命令执行错误，其他命令依旧会执行(包括出错后的命令)。

\---------------------  
作者：想念-忘记了  
来源：CSDN  
原文：https://blog.csdn.net/dannyiscoder/article/details/78285549?utm\_source=copy  
版权声明：本文为博主原创文章，转载请附上博文链接！

来源:[https://blog.csdn.net/dannyiscoder/article/details/78285549][https_blog.csdn.net_dannyiscoder_article_details_78285549]

[https_blog.csdn.net_dannyiscoder_article_details_78285549]: https://blog.csdn.net/dannyiscoder/article/details/78285549