Redis 事务的特性
Redis 事务（Transaction）是一组命令的集合，可以一次性、顺序地执行多个命令，并且在执行过程中不会被其他客户端的请求打断。Redis 事务的特性主要包括以下几点：
- 原子性（Atomicity）：事务中的所有命令都会按顺序执行，但 Redis 事务不支持回滚，即如果某个命令执行失败，不会影响之前已执行的命令。
- 隔离性（Isolation）：事务在执行过程中，不会受到其他客户端的并发干扰，所有命令按顺序执行，不会被其他命令插入。
- 一致性（Consistency）：Redis 不支持回滚，但如果某个命令写入了错误的数据，会影响数据的正确性，因此一致性需要业务逻辑保证。
- 持久性（Durability）：如果 Redis 开启了 AOF（Append-Only File）或 RDB（Redis Database）持久化机制，事务的修改可以持久化到磁盘，否则数据只存在于内存中。
Redis 事务的使用
Redis 事务的基本使用方式如下：
- 开启事务：使用
MULTI命令开启事务。 - 命令入队：在
MULTI之后，所有输入的命令都会进入队列，而不会立即执行。 - 执行事务：使用
EXEC命令执行所有入队的命令。 - 放弃事务：使用
DISCARD命令取消事务，清空事务队列。
示例代码：
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> SET key1 value1
QUEUED
127.0.0.1:6379> SET key2 value2
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) OK
如果 EXEC 之前执行 DISCARD，事务队列会被清空，不执行任何命令。
Redis 事务的适用场景
Redis 事务适用于一些简单的原子操作场景，例如：
- 批量执行多个命令：如一次性设置多个 key 或删除多个 key。
- 确保操作的有序性：事务中的命令会按顺序执行，不会被其他命令打断。
- 配合
WATCH实现乐观锁：WATCH监视某个 key，在EXEC执行前如果该 key 发生变化，事务会被取消，适用于类似数据库的 CAS（Compare-And-Swap） 操作。
示例：
127.0.0.1:6379> WATCH counter
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> INCR counter
QUEUED
127.0.0.1:6379> EXEC
(integer) 1 # 如果 counter 没有被其他客户端修改，则成功执行
如果 counter 在 EXEC 之前被其他客户端修改，事务会被取消。
事务的局限性
- 不支持回滚：如果事务中某条命令执行失败，已执行的命令不会回滚。
- 单线程执行：Redis 是单线程的，事务中的所有命令都会按照顺序执行，不会被其他命令打断，但不会提高执行效率。
- 不支持部分执行：如果
EXEC失败，整个事务都不会执行，但如果事务中的某个命令失败，不影响其他命令执行。
在实际开发中，Redis 事务适用于以下场景：
1. 计数器的原子更新
适用于高并发场景，如点赞、浏览量、订单编号等计数操作。例如，一个网站的文章浏览量可以使用 Redis 事务进行更新：
WATCH article:1001:views
MULTI
INCR article:1001:views
EXEC
这样可以保证在高并发情况下，计数操作不会出现丢失更新的问题。
2. 抢购/秒杀系统
在电商系统中，Redis 事务可以用于限量抢购，防止超卖。例如：
WATCH stock:product_123
MULTI
GET stock:product_123 # 读取库存
DECR stock:product_123 # 扣减库存
EXEC
如果 stock:product_123 在 EXEC 之前被其他用户修改，事务将会失败，从而避免超卖。
3. 账户余额转账
在金融系统中，Redis 事务可以用于保证转账操作的原子性：
WATCH balance:user_1 balance:user_2
MULTI
DECR balance:user_1 100 # 从用户1账户扣款
INCR balance:user_2 100 # 给用户2账户加款
EXEC
如果 EXEC 之前 balance:user_1 或 balance:user_2 发生变化，事务会取消，避免出现数据不一致的问题。
总结
Redis 事务通过 MULTI、EXEC、DISCARD 和 WATCH 来实现，适用于批量执行命令、保证操作的顺序性和实现乐观锁机制。但由于不支持回滚，在需要强一致性的场景下，建议配合 Lua 脚本或其他机制来确保数据的完整性。
