1. 概述
redis
事务就是一个命令执行的队列,将一系列预定义命令包装成一个整体(一个队列)。当执行时,一次性 按照添加顺序依次执行,中间不会被打断或者干扰。
2. 基本操作
//开启事务 设定事务的开启位置,此指令执行后,后续的所有指令均加入到事务中
multi
//执行事务 设定事务的结束位置,同时执行事务。与multi成对出现,成对使用
exec
//事务定义过程中发现出了问题,怎么办?
//取消事务 终止当前事务的定义,发生在multi之后,exec之前
discard
加入事务的命令暂时进入到任务队列中,并没有立即执行,只有执行exec
命令才开始执行
3. 事务的注意事项
3.1 定义事务的过程中,命令格式输入错误怎么办?
对应语法错误,指命令书写格式有误,整体事务中所有命令均不会执行,包括那些语法正确的命令
3.2 定义事务的过程中,命令执行出现错误怎么办?
能够正确运行的命令会执行,运行错误的命令不会被执行,已经执行完毕的命令对应的数据不会自动回滚,需要程序员自己在代码中实现回滚
4. 锁
多个客户端有可能同时操作同一组数据,并且该数据一旦被操作修改后,将不适用于继续操作 ;在操作之前锁定要操作的数据,一旦发生变化,终止当前操作
如何理解redis是单线程的
Redis 确实是单线程模型,指的是执行 Redis 命令的核心模块是单线程的,而不是整个 Redis 实例就一个线程,Redis 其他模块还有各自模块的线程的
4.1 基本使用
//对 `key` 添加监视锁,在执行`exec`前如果key发生了变化,终止事务执行
watch key1 [key2……]
//取消对所有 key 的监视
unwatch
4.2 基于特定条件的事务执行-分布式锁
业务场景
在商品热卖的时候如何确保最后一件商品不会同时被多人购买(超卖问题)
业务分析
- 使用watch监控一个key有没有改变不能解决问题,因为watch的数据一旦改变就不再对他操作,那在售罄前的卖出操作都不能执行
- 虽然redis是单线程的,但是多个客户端对同一个数据同时操作时如何避免不被同时操作
分布式锁
//加锁
setnx lock-key value
//解锁
del lock-key
设置一个公共锁,已经有锁了则返回设置失败,否则才能设置,实际上就是一个互斥锁,仅有一个线程拥有对他的控制权;
自然的前面的watch锁类似于乐观锁
死锁的解决方案
依赖分布式锁的机制,某个用户操作时对应客户机宕机,并且此时已经获取到锁,如何解决?
- 由于锁操作由用户控制加锁,必定会存在加锁后未解锁的风险
- 需要解锁操作不能仅依赖用户控制,系统级别要给出对应的保底处理方案
解决方案
使用expire为锁key添加时间限定,到时不释放,放弃锁
expire lock-key second
pexpire lock-kay millisenconds
由于操作通常都是微秒或者毫秒级,因此该锁设定时间不宜设置过大。具体时间需要业务测试后确认
- 例如:持有锁的操作最长执行时间127ms,最短执行时间7ms
- 测试百万次最长执行时间对应命令的最大消耗时,测试百万次网络延迟平均耗时
- 锁时间设定推荐:最大耗时* 120%+平均网络延迟*110%
- 如果业务最大耗时<<网络平均延迟,通常为2个数量级,取其中单个耗时较长即可