本文主要是介绍Reids 事务，命令，场景，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
性质
原子性：事务中的所有命令要么全部执行，要么全部不执行。相比于 MySQL 中的原子性，Redis的还是稍微比较吝啬的。MySQL 中的是事务所有命令要么全部成功，要么全部不执行。在MySQL中，如果不是全部执行成功则会进行回滚操作。Redis中是没有的。
不具备一致性：redis 中没有约束，也没有回滚机制，事务执行过程中的某个修改操作出现失败，就可能引发不一致的情况。
不具备持久性：redis本身就是内存数据库，数据是存在内存中的。虽然 redis 有持久化机制。但是这个持久化机制和事务是没有关系的。
不涉及隔离性：reids为一个单线程模型的服务器程序。所有的请求/事务都是"串化"执行的。
开启事务的时候，此时客户端输入的命令，就会发送给服务器并且进入到一个队列中（不是立刻执行）。当收到执行事务的时候，此时主线程就会把队列中的任务按照顺序执行。
命令
开启事务
MULTI执行事务
EXEC放弃当前事务
DISCARD监控 key 是否在执行事务前发生改变
WATCHwatch 的实现类似与乐观锁（在加锁之前有一个预期，预期锁冲突的概率比较低，悲观锁反之）
假设有一个 key 111。第一个客户端进行 watch key （会给 key 分配一个版本号，假设为 1） ，然后 multi（开启事务）进行 set key 222。当其他的客户端对这个 key 进行修改，这个版本号就会变大（假设变成了2）。然后在第一个客户端进行 exec 执行命令的时候就会进行判定，判断这个版本号是否和原来分配的一样，一样的话说明当前这个 key 在这个事务执行的过程中，没有别的客户端进行修改，于是就进行设置 key 为 222。反正，失败，返回 nil。
场景
超卖：防止超量卖出，redis 为单线程，通过事务处理多个客户端进行买东西。
第一个客户端
开启事务
get count
if count > 0decr count
执行事务第二个客户端
开启事务
get count
if count > 0decr count
执行事务redis 服务器在队列中收到这些请求，当到执行事务的步骤时，才开始执行第一个事务（第二个排队），当到第二个事务时候拿到的 count 已经是 -- 后的了
这篇关于Reids 事务，命令，场景的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
