【Redis系列】事务特性

🚀 欢迎来到我的CSDN博客：Optimistic _ chen ✨ 一名热爱技术与分享的全栈开发者，在这里记录成长，专注分享编程技术与实战经验，助力你的技术成长之路，与你共同进步！

🚀我的专栏推荐：

🚀我的承诺： ✅ 文章配套代码：每篇技术文章都提供完整的可运行代码示例

✅ 持续更新：专栏内容定期更新，紧跟技术趋势

✅ 答疑交流：欢迎在文章评论区留言讨论，我会及时回复（支持互粉）

🚀 关注我，解锁更多技术干货！ ⏳ 每天进步一点点，未来惊艳所有人！✍️ 持续更新中，记得⭐收藏关注⭐不迷路 ✨

📌 标签:#技术博客 #编程学习 #Java #C语言 #算法 #程序员

事务

事务这个词我们之前在数据库中也有学习，并且Redis的事务和MySQL的事务在概念上是类似的，都是把一系列操作绑定成一组操作，让这一组操作批量执行（要么全部成功，要么全部失败）

• MySQL事务是真正的数据库事务，为复杂业务提供强一致性保证
• Redis事务本质是命令批量执行，适用于高性能场景下的简单原子操作，需结合 WATCH 实现乐观锁。

Redis事务本质上是在服务器上有一个“事务队列”，每次客户端在事务中进行一个操作，都会把命令发给服务器，放到“事务队列”中（但不会并立即执行），正真收到EXEC命令后，才会在队列中执行所以操作。

所以，Redis的事务功能比MySQL弱化很多，只能保证事务中的这⼏个操作是"连续的", 不会被别的客⼾端"加塞",仅此⽽已

事务操作

MULTI

multi:开启一个事务，执行成功返回OK

在这里插入图片描述

EXEC

exec:真正执行事务

在这里插入图片描述

每次添加一个操作，都会提示“QUEUED”，说明命令进入客户端队列了，真正执行EXEC命令的时候，客户端才会把这些操作发给服务器，去真正执行命令。

在这里插入图片描述

DISCARD

discard:放弃当前事务，此时直接清空事务队列，之前在队列中的操作都不会真正执行到

在这里插入图片描述

WATCH

在执行事务的时候，如果某个事务中修改的值，被别的客户端修改了，此时就容易出现数据不一致的情况

在这里插入图片描述

从输入命令的时间看，客户端1 先 执行set k1 111，客户端 2后 执行set k1 222， 而从实际的执行时间看，客户端2先 执行，客户端 1后执行。

这个时候两个客户端都对k1进行修改，肯定有用户得到不符合预期的结果，所以watch命令就解决了这个问题。watch在该客⼾端上监控⼀组具体的key。

• 当开启事务的时候，如果对watch监控的key进行修改，服务器就会记录当前key的“版本号”
• 在真正提交事务的时候，如果发现当前服务器上的key的版本号已经超过了事务开启时候的版本号，就会让事务执行失败（事务中所有操作都不执行）

在这里插入图片描述

总结

1. 因为redis单线程顺序执行，所以事务期间不会穿插执行其他客户端命令，天然提供隔离性，无需锁机制。
2. 无回滚设计：Redis 认为语法错误应该在开发阶段发现，运行时错误通常是逻辑错误，应该被修复而非回滚
3. 批量操作原子性：MULTI开启事务，批量设置多个键值，EXEC真正批量执行命令
4. watch实现乐观锁并发控制，假设冲突较少，先操作再检查；在保证数据一致性的同时，提供无锁的高并发能力

完结撒花！🎉

如果这篇博客对你有帮助，不妨点个赞支持一下吧！👍 你的鼓励是我创作的最大动力～

✨ 想获取更多干货？ 欢迎关注我的专栏 → optimistic_chen 📌 收藏本文，下次需要时不迷路！

我们下期再见！💫 持续更新中……

悄悄说：点击主页有更多精彩内容哦～ 😊