Redis 事务 `MULTI`/`EXEC`/`DISCARD` 深度：原子性与隔离性

好，咱们开始今天的Redis事务深度剖析！

各位观众老爷，今天我们要聊聊Redis事务里的MULTI/EXEC/DISCARD三兄弟，好好扒一扒它们的原子性和隔离性，保证让你听得懂，学得会，用得上。

开场白：别被“事务”俩字给唬住！

首先，别听到“事务”两个字就觉得高深莫测。其实，事务说白了，就是把一堆操作打包在一起，要么全成功，要么全失败。就像你去银行取钱，先验证密码，再扣钱，最后打印凭条，这三个动作必须一起完成，不然就出大事了。

Redis的事务，本质上也是这个意思。但是！Redis的事务和传统关系型数据库（比如MySQL）的事务，还是有些区别的，尤其是隔离性方面。

第一幕：MULTI/EXEC/DISCARD 上场

Redis事务的三个核心命令，就是MULTI、EXEC、DISCARD。它们负责把你的操作打包起来，然后要么执行，要么放弃。

MULTI: 标志着事务的开始。你告诉Redis：“我要开始搞事情了，准备好了吗？”
EXEC: 执行事务队列中的所有命令。你告诉Redis：“好了，我操作都写完了，开始执行吧！”
DISCARD: 放弃事务。你告诉Redis：“算了算了，我不搞了，刚才的操作都作废！”

举个例子：

MULTI
SET mykey "Hello"
GET mykey
INCR counter
EXEC

这段代码的意思是：

MULTI：开始事务。
SET mykey "Hello"：设置键mykey的值为"Hello"。
GET mykey：获取键mykey的值。
INCR counter：将键counter的值加1（如果counter不存在，则先设置为0，再加1）。
EXEC：执行事务。

如果一切顺利，EXEC会返回一个包含所有命令执行结果的数组。比如：

1) OK
2) "Hello"
3) (integer) 1

这表示SET命令执行成功，GET命令返回"Hello"，INCR命令将counter的值变成了1。

如果想放弃事务，就用DISCARD：

MULTI
SET mykey "Hello"
DISCARD

执行完这段代码后，mykey的值不会被设置为"Hello"，Redis会直接放弃事务。

第二幕：原子性，没那么完美

Redis的事务的原子性，相对来说比较“弱”。怎么理解呢？

命令入队错误： 如果你在MULTI和EXEC之间输入的命令本身就有语法错误，那么整个事务都不会执行。比如：

MULTI
SET mykey "Hello"
GETT mykey  # 错误的命令
INCR counter
EXEC

EXEC会返回一个错误，提示你GETT命令不存在。整个事务会被取消，mykey的值不会被设置，counter的值也不会增加。

运行时错误： 但是，如果命令的语法没有问题，只是在运行时出现了错误（比如对一个字符串进行INCR操作），那么只有这条命令会执行失败，其他命令仍然会执行。

SET mykey "Hello"
MULTI
INCR mykey  # 运行时错误：对字符串进行INCR操作
SET anotherkey "World"
EXEC

EXEC会返回：

1) (error) ERR value is not an integer or out of range
2) OK

可以看到，INCR mykey执行失败，但SET anotherkey "World"执行成功了。这意味着，Redis事务不能保证完全的原子性。它只能保证：

事务中的所有命令要么全部不执行（如果入队时有语法错误）。
事务中的所有命令要么全部执行，要么部分执行失败（如果运行时有错误）。

划重点：和传统数据库事务的区别

传统数据库事务（比如MySQL）如果遇到运行时错误，默认会回滚整个事务，保证数据的一致性。Redis不会这样做。

为什么Redis要这么设计？

主要是为了性能。Redis追求的是速度，如果每次遇到错误都要回滚整个事务，会大大降低性能。而且，Redis的设计哲学是“简单”，它希望开发者自己处理错误情况。

第三幕：隔离性，单线程的优势

Redis的隔离性，相对来说比较强。因为它是一个单线程的服务器。

这意味着，在执行EXEC命令之前，Redis不会处理任何其他的客户端请求。也就是说，一个事务在执行过程中，不会被其他客户端的命令所干扰。

隔离级别：READ_UNCOMMITTED？

有人可能会说，Redis的隔离级别是READ_UNCOMMITTED（读未提交），因为在MULTI和EXEC之间，其他客户端可以读取到未提交的数据。

这个说法其实不完全准确。虽然其他客户端可以读取到未提交的数据，但是它们无法修改这些数据。因为Redis是单线程的，它必须等一个事务执行完毕后，才能处理其他的客户端请求。

举个例子：

客户端A：

MULTI
SET counter 10
GET counter

客户端B：

GET counter  # 在客户端A执行EXEC之前执行

客户端A在执行EXEC之前，客户端B可以读取到counter的值（如果counter之前存在的话）。但是，客户端B无法修改counter的值，直到客户端A执行完EXEC命令。

用代码模拟并发问题（假的）：

因为Redis是单线程的，所以我们无法真正模拟并发问题。但是，我们可以通过一些技巧来模拟一下：

import redis
import time
import threading

r = redis.Redis(host='localhost', port=6379, db=0)

def worker_a():
    r.multi()
    r.set("mykey", "Value from A")
    time.sleep(0.1)  # 模拟耗时操作
    r.set("anotherkey", "Also from A")
    r.execute()
    print("Worker A finished")

def worker_b():
    time.sleep(0.05)  # 确保Worker B在Worker A的MULTI之后执行
    print(f"Worker B reads mykey: {r.get('mykey')}")
    print(f"Worker B reads anotherkey: {r.get('anotherkey')}")
    r.set("mykey", "Value from B")
    print("Worker B finished")

thread_a = threading.Thread(target=worker_a)
thread_b = threading.Thread(target=worker_b)

thread_a.start()
thread_b.start()

thread_a.join()
thread_b.join()

print(f"Final mykey value: {r.get('mykey')}")
print(f"Final anotherkey value: {r.get('anotherkey')}")

虽然我们用了多线程，但是因为Redis是单线程的，所以Worker A的事务会先执行完毕，然后Worker B才会执行。因此，mykey最终的值会是Value from B，anotherkey的值会是Also from A。

表格总结：Redis事务的特性

特性	说明
原子性	命令入队错误：事务全部取消。运行时错误：只有出错的命令不执行，其他命令会执行。
隔离性	因为Redis是单线程的，所以在执行`EXEC`命令之前，不会处理任何其他的客户端请求。一个事务在执行过程中，不会被其他客户端的命令所干扰。
持久性	Redis事务本身不提供持久性保证。持久性是由Redis的RDB和AOF机制来保证的。
应用场景	适合对多个操作进行原子性控制，但对数据一致性要求不是特别高的场景。比如：秒杀系统：可以用事务来扣减库存。计数器：可以用事务来保证计数器的原子性增加。
替代方案	如果需要更强的原子性和隔离性，可以考虑使用Lua脚本或者Redis Modules。

第四幕：Lua脚本，更强大的武器

如果你需要更强的原子性，或者需要更复杂的逻辑，可以考虑使用Lua脚本。

Lua脚本可以直接在Redis服务器上执行，而且是原子性的。也就是说，整个Lua脚本的执行过程中，不会被其他的客户端请求所干扰。

举个例子：

EVAL "local current = redis.call('GET', KEYS[1]) if current then current = tonumber(current) redis.call('SET', KEYS[1], current + ARGV[1]) return current + ARGV[1] else redis.call('SET', KEYS[1], ARGV[1]) return ARGV[1] end" 1 counter 10

这段Lua脚本的意思是：

获取键counter的值。
如果counter存在，则将其转换为数字，然后加上ARGV[1]（这里是10）。
如果counter不存在，则将其设置为ARGV[1]（这里是10）。
返回counter的新值。

这段Lua脚本是原子性的，也就是说，在执行这段脚本的过程中，不会被其他的客户端请求所干扰。

Lua脚本的优势：

原子性： 保证整个脚本的执行过程中，不会被其他的客户端请求所干扰。
高性能： 减少了客户端和服务器之间的网络交互，提高了性能。
灵活性： 可以编写更复杂的逻辑。

Lua脚本的缺点：

学习成本： 需要学习Lua语言。
调试困难： 在Redis服务器上调试Lua脚本比较困难。

第五幕：总结与建议

Redis的事务机制，虽然不如传统数据库那么强大，但是对于很多场景来说，已经足够用了。

记住以下几点：

Redis事务的原子性比较“弱”，只能保证命令入队错误时事务全部取消，运行时错误时只有出错的命令不执行，其他命令会执行。
Redis事务的隔离性比较强，因为它是单线程的。
如果需要更强的原子性和更复杂的逻辑，可以考虑使用Lua脚本。
根据实际需求选择合适的方案，不要过度追求“完美”的事务。

给你的建议：

在编写Redis事务时，尽量避免运行时错误。
如果需要更强的原子性，可以考虑使用Lua脚本。
对数据一致性要求特别高的场景，可以考虑使用其他数据库。
理解Redis的设计哲学，不要把它当成万能的解决方案。

结束语：

好了，今天的Redis事务深度剖析就到这里了。希望大家能够对Redis事务有更深入的理解。记住，技术是死的，人是活的，要灵活运用，才能发挥出最大的价值！

有什么问题，欢迎随时提问！下次再见！

发表回复 取消回复

发表回复取消回复