Redis中的事务和监视语句

Question

redis.multi() 
current = redis.get('powerlevel') 
redis.set('powerlevel', current + 1) 
redis.exec()

redis.watch('powerlevel') 
current = redis.get('powerlevel') 
redis.multi() 
redis.set('powerlevel', current + 1) 
redis.exec()

如果另一个客户机在我们调用watch之后更改了powerlevel的值，我们的事务将失败。如果没有客户端更改该值，则该集合将工作。我们可以在循环中执行这段代码，直到它起作用为止。

为什么不能在不能被其他命令打断的事务中执行增量？为什么我们需要迭代而不是等到没有人改变值才开始事务？

Answer 1

这里有几个问题。

1）为什么不能在不能被其他命令打断的事务中执行增量？

首先请注意，Redis“事务”与大多数人认为的经典DBMS中的事务完全不同。

# Does not work
redis.multi() 
current = redis.get('powerlevel') 
redis.set('powerlevel', current + 1) 
redis.exec()

如果我们不使用watch/multi/exec，我们将有一个潜在的竞争条件：

# Initial arbitrary value
powerlevel = 10
session A: GET powerlevel -> 10
session B: GET powerlevel -> 10
session A: current = 10 + 1
session B: current = 10 + 1
session A: SET powerlevel 11
session B: SET powerlevel 11
# In the end we have 11 instead of 12 -> wrong

现在让我们添加一个watch/multi/exec块。使用WATCH子句，MULTI和EXEC之间的命令仅在值未更改时执行。

# Initial arbitrary value
powerlevel = 10
session A: WATCH powerlevel
session B: WATCH powerlevel
session A: GET powerlevel -> 10
session B: GET powerlevel -> 10
session A: current = 10 + 1
session B: current = 10 + 1
session A: MULTI
session B: MULTI
session A: SET powerlevel 11 -> QUEUED
session B: SET powerlevel 11 -> QUEUED
session A: EXEC -> success! powerlevel is now 11
session B: EXEC -> failure, because powerlevel has changed and was watched
# In the end, we have 11, and session B knows it has to attempt the transaction again
# Hopefully, it will work fine this time.

因此，您不必迭代直到没有人更改值，而是一次又一次地尝试操作，直到Redis确定值是一致的，并发出成功的信号。