Redis的事务机制详解_redis是如何保证事务的

详细介绍了Redis的事务机制。

MULTI、EXEC、DISCARD 和 WATCH 命令是 Redis 中事务的基础，它们允许将多个命令组合在一起以事物的方式执行。

DISCARD命令用于清除所有先前在一个事务中放入队列的命令，然后恢复正常的连接状态。而当某个事务需要按条件执行时，就要使用WATCH命令将给定的键设置为受监控的。

一个最简单的事务从开始到执行大概会经历以下三个阶段：

1. MULTI命令开始事务。
2. 多个命令入队。
3. EXEC执行事务。

如下案例：

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379(TX)> SADD a bb cc
QUEUED
127.0.0.1:6379(TX)> SREM a cc
QUEUED
127.0.0.1:6379(TX)> EXEC
1) (integer) 1
2) (integer) 1
1
2
3
4
5
6
7
8
9

Redis有如下保证：

1. 事务中的所有命令都被序列化并按顺序执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。这保证了这一组命令作为单个隔离操作执行。
2. 要么执行所有命令，要么不执行任何命令。

EXEC 命令会触发事务中所有命令的执行，如果客户端在调用EXEC命令之前出现错误，比如命令语法错误（参数的数量错误、命令名称错误等等），比如达到了某些系统限制（比如内存溢出）等，此时Redis在执行放入队列操作的时候会返回一个错误，客户端将会终止事务，并且丢弃这个事务。

如果成功调用了 EXEC 命令，则会执行所有命令，但是在执行途中可能会遇到某个命令失败，比如对key执行了错误的操作（比如对String类型的数据执行的list的命令），此时Redis不会对此前的命令进行任何回滚，也不会影响后续命令的执行，因此不具备严格的原子性。

使用AOF持久化机制时，Redis 确保使用一个write()函数系统调用将事务的所有操作同时写入磁盘（写入内核缓冲区）。但如果Redis 服务器崩溃或被直接kill掉，则可能只持久化了部分操作。因此，事物的持久性也不能保证。Redis 将在重新启动时检测到这种情况，并会出现错误退出。使用 redis-check-aof 工具可以修复将删除部分事务的aof文件，以便服务器可以重新启动。

总的来说，Redis事务和数据库事务有很多区别，Redis事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已执行指令的回滚，也不会造成后续的指令不执行。

为什么Redis的事务不支持回滚呢？ 从官网能找到答案：

1. Redis开发者觉得没必要支持回滚，这样Redis内部能够保持更简单便捷并且性能更好。
2. Redis开发者觉得失败的命令是由使用者编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。

Redis事务实际上用的并不是很多，另外，Redis的LUA脚本也是事务型的。因此，我们可以通过Redis事务实现的功能，同样也可以通过Redis脚本来实现，而且通常脚本更简单、更快速。Redis开发者说过：如果整个用户群体都只使用Redis脚本，那么将会废弃，甚至最终移除Redis事务。

相关文章：

1. https://redis.io/topics/data-types
2. https://redis.io/topics/data-types-intro
3. https://redis.io/topics/transactions

如有需要交流，或者文章有误，请直接留言。另外希望点赞、收藏、关注，我将不间断更新各种Java学习博客！