前言
Redis的事务是一组命令的集合，这些命令可以单独操作来执行。在Redis中，事务不是严格意义上的事务，只是用于帮助用户在一个步骤中执行多个命令。事务的本质是一组命令的集合，支持一次性执行多个命令，且所有命令都会被序列化。在事务执行过程中，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。因此，Redis事务可以视为一次性、顺序性、排他性的执行一个队列中的一系列命令。
Redis和MySQL事物的区别
- 弱化的原子性: redis 没有"回滚机制"只能做到这些操作"批量执行",不能做到"一个失败就恢复到
初始状态" - 不保证一致性:不涉及"约束”也没有回滚,MySQL的一致性体现的是运行事务前和运行后,结果都
是合理有效的,不会出现中间非法状态. - 不需要隔离性: 也没有隔离级别,因为不会并发执行事务(redis 单线程处理请求)
- 不需要持久性: 是保存在内存的.是否开启持久化,是redis-server 自己的事情,和事务无关,
Redis 事务本质上是在服务器上搞了⼀个 “事务队列”. 每次客⼾端在事务中进⾏⼀个操作, 都会把命令先发给服务器, 放到 “事务队列” 中(但是并不会⽴即执⾏)
开启事务的事物的时候，此时客户端输入命令，就会发给服务器并且进入这个队列中，而不是执行。
使用事务的时机
究竟什么时候次啊使用事务呢？
其实很简单，当我们需要多个事务打包执行的时候，我们就需要使用事务机制，举个简单例子。看下下图：
一般来说，超时卖货，我们要解决卖货的同时，还要去解决定时获取商品个数的办法，在多线程，我们是通过加锁的方式。但是在这里，我们可以通过事务的机制去解决。
使用这样的方式，就可以不用加锁，也可以解决这个场景的问题。
事务操作
我们一般使用事务的操作。有以下三个命令
开启事务:MULTI
执行事务:EXEC
放弃当前事务:DISCARD
事物的场景操作1
开启事务，不提交事务，另外一个客户端是否能访问。
看到结果了吗。显然事务不提交，是没有意义的。
事物场景操作2
开启事务，提交事务，另外一个客户端是否能访问。
提交了事物之后，显然是能够查看到的。
总结来说：
- Redis 保证一个事务中的所有命令要么都执行，要么都不执行。如果在发送EXEC命令
前客户端断线了，则Redis会清空事务队列，事务中的所有命令都不会执行。而一旦客户
端发送了EXEC命令,所有的命令就都会被执行,即使此后客户端断线也没关系,因为Redis
中已经记录了所有要执行的命令。 - 除此之外，Redis的事务还能保证一个事务内的命令依次执行而不被其他命令插入。
试想客户端A需要执行几条命令，同时客户端B发送了一条命令，如果不使用事务，则客
户端B的命令可能会插入到客户端A的几条命令中执行。如果不希望发生这种情况，也可
以使用事务。
Watch命令介绍
在执⾏事务的时候, 如果某个事务中修改的值, 被别的客⼾端修改了, 此时就容易出现数据不⼀致的问
题。
换句话说，WATCH这个命令，就是监控某个key事务执行之前，发生了改变，我们接下来模拟一下这个场景。
客户端1：先增加一个key
客户端2：用相同的操作
这时候客户端1执行时间，你觉的key是100 ？还是300？
我们来实际操作一下就知道了
事实证明，病美欧出现预期的效果。111 并没有变成 222。
此时这个WATCH 命令的作用就来了。
- 当开启事务的时候, 如果对 watch 的 key 进⾏修改, 就会记录当前 key 的 “版本号”. (版本号是个简单的整数, 每次修改都会使版本变⼤. 服务器来维护每个 key 的版本号情况)
- 在真正提交事务的时候, 如果发现当前服务器上的 key 的版本号已经超过了事务开始时的版本号, 就会让事务执⾏失败. (事务中的所有操作都不执⾏)。
具体看下面操作。
这种机制使得 Redis 能够支持一种简单的乐观锁策略。然而，需要注意的是，WATCH 命令并不能完全替代传统的锁机制，因为它不能处理复杂的并发场景。在某些情况下，可能需要结合其他技术（如 Redis 的 Lua 脚本或 Redis 的分布式锁实现）来实现更复杂的并发控制。
总的来说，WATCH 命令提供了一种在 Redis 事务中检测并处理 key 值变化的方法，从而确保事务的原子性。
