linux学习进展 Redis事务 乐观锁/悲观锁 持久化
Redis事务
1. 什么是 Redis 事务？
Redis 事务允许一次性执行多个命令，这些命令会按顺序串行化执行，在执行过程中不会被其他客户端的命令打断。
生活场景比喻：
传统数据库事务：像银行转账 - 要么全部成功（A扣款，B收款） - 要么全部失败（都不执行） Redis 事务：像购物清单 - 把要买的东西列出来，然后一次性结账 - 但结账时如果某件商品有问题，只跳过那件商品，其他照常购买2. Redis 事务的核心命令
| 命令 | 作用 | 关键点 |
|---|---|---|
| MULTI | 开启事务 | 之后的命令不会立即执行，而是加入队列 |
| EXEC | 执行事务 | 一次性执行队列里所有命令，结束事务 |
| DISCARD | 放弃事务 | 清空队列，所有命令都不执行 |
| WATCH | 监控 Key | 监控的 key 被修改，事务自动失败（实现乐观锁） |
| UNWATCH | 取消监控 | 取消对所有 key 的监控 |
3. 基本事务使用
简单事务示例：
# 开启事务 127.0.0.1:6379> MULTI OK # 将多个命令加入队列 127.0.0.1:6379> SET user:1001:name "张三" QUEUED 127.0.0.1:6379> SET user:1001:age 25 QUEUED 127.0.0.1:6379> INCR user:id_counter QUEUED # 执行事务 127.0.0.1:6379> EXEC 1) OK 2) OK 3) (integer) 101事务执行流程：
MULTI → 开始事务 命令1 → 命令入队，返回 QUEUED 命令2 → 命令入队，返回 QUEUED 命令3 → 命令入队，返回 QUEUED EXEC → 按顺序执行所有命令，返回结果数组4. 事务中的错误处理
Redis 事务有两种错误情况：
4.1 入队时错误（语法错误）
127.0.0.1:6379> MULTI OK 127.0.0.1:6379> SET key1 "value1" QUEUED 127.0.0.1:6379> SET key2 # 语法错误，缺少value (error) ERR wrong number of arguments for 'set' command 127.0.0.1:6379> SET key3 "value3" QUEUED 127.0.0.1:6379> EXEC (error) EXECABORT Transaction discarded because of previous errors. # 整个事务都不会执行！4.2 执行时错误（运行时错误）
127.0.0.1:6379> MULTI OK 127.0.0.1:6379> SET key1 "value1" QUEUED 127.0.0.1:6379> INCR key1 # key1的值不是数字，执行时会出错 QUEUED 127.0.0.1:6379> SET key2 "value2" QUEUED 127.0.0.1:6379> EXEC 1) OK # SET key1 成功 2) (error) ERR value is not an integer or out of range # INCR 失败 3) OK # SET key2 成功（继续执行！）重要特点：Redis 事务在执行时遇到错误不会回滚，会继续执行后续命令！
Redis 事务 vs 数据库事务
| 对比项 | Redis 事务 | MySQL 数据库事务 |
|---|---|---|
| 遵循标准 | 不严格遵循 ACID | 完全遵循 ACID 四大特性 |
| 原子性 | 不满足语法错全不执行，运行错部分成功，无回滚 | 完全满足要么全部成功，失败全部回滚 |
| 一致性 | 弱一致性 | 强事务一致性 |
| 隔离性 | 串行执行，简单隔离 | 支持 4 种隔离级别（读未提交～串行化） |
| 持久性 | 依赖 RDB/AOF 持久化，事务本身不保证 | 提交后立刻落盘，强持久 |
| 回滚机制 | 无事务回滚 | 支持ROLLBACK手动回滚 |
| 异常处理 | 出错继续往下执行 | 出错直接整体回 |
| 使用场景 | 简单批量命令、缓存操作 | 金融、订单、支付等高一致性业务 |
| 实现方式 | 命令队列排队执行 | 事务日志 + 锁机制 |
5. WATCH 命令 - 乐观锁
什么是乐观锁？
在事务执行前监视一个或多个键，如果在事务执行期间这些键被其他客户端修改，则事务执行失败。
使用示例：
# 客户端1 127.0.0.1:6379> SET balance 100 OK 127.0.0.1:6379> WATCH balance # 开始监视balance OK 127.0.0.1:6379> MULTI OK 127.0.0.1:6379> INCRBY balance 50 QUEUED # 此时客户端2修改了balance # 客户端2：127.0.0.1:6379> SET balance 200 # 客户端1继续执行 127.0.0.1:6379> EXEC (nil) # 返回nil表示事务执行失败，因为balance被修改了完整的乐观锁模式：
# 使用循环实现重试机制 while true; do WATCH balance current_balance = GET balance MULTI SET balance (current_balance - 10) result = EXEC if result != nil break # 成功执行 end # 失败重试 endredis的持久化
Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘中，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化的功能。
1.RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文件直接读到内存中。
Redis会单独创建（fork）一个子进程来进程持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上一次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进程大规模数据的恢复，且对数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失
rdb保存的文件是dump.rdb
触发机制
1.save的规则满足的情况下，会自动触发rdb操作
2.执行flushall命令，会触发rdb操作
3.对出redis时，也会触发rdb操作
4.备份会自动生成也给dump.rdb文件
如何恢复rdb文件
只需要将rdb文件放在redis的启动目录下就可以。redis启动时会自动检查dump.rdb文件恢复其中的数据
优点
适合大规模的数据恢复
对数据的完整性要求不高
缺点
需要一定的时间间隔进行操作，如果redis意外宕机，最后一次持久化后的操作数据就没有了
fork进程的时候，会需要占用一定的内存空间
2.AOF
将所有写操作的命令都记录下来，类似history，恢复时将所有的命令都执行一遍！
AOF保存的文件是appendonly.aof
如果这个aof文件被恶意修改，这个时候redis是启动不起来的，我们需要修复这个aof文件！
redis提供的一个工具 redis-check-aof --fix 来修改aof文件
优点
1. 每一次修改都同步，文件的完整性比较好
2.每秒同步一次，可能会丢失1s的数据
缺点
1. 相对于数据文件来说，aof远远大于rdb
2.修复的速度比rdb慢
3.AOF的运行效率也比rdb慢