Redis事务

redis事务就是一个命令执行的队列,将一系列定义命令包装成一个整体(一个队列).当执行时,一次性按照添加顺序依次执行,中间不会被打断或干扰.
一个队列中,一次性,顺序性,排他性的执行一系列命令.
事务的基本操作

• 开启事务
  multi
  作用:设定事务的开启位置,此指令执行后,后续的所有指令均加入到事务中(队列中)
• 执行事务
  exec
  作用:设定事务的结束位置,同时执行事务,与multi成对出现,成对使用

加入事务的命令暂时进入到任务队列中,并没有立即执行,只有执行exec命令才能执行

• 取消事务
  discard
  作用:终止当前事务的定义,发生在multi之后,exec之前

事务的工作流程

注意:在redis中已经执行完毕的命令对应的数据不会自动回滚,需要程序员自己在代码中实现

锁
基于特定条件的事务执行-锁
同一批数据,可能会有多个人去修改,会使数据发生混乱,为防止该情况,可以加上监控,没动过就动,动过就不能再动了,也就是锁.

• 对key添加监控锁,在执行exec前如果key发生了变化,终止事务进行
  watch key…
• 取消对所有key的监视
  unwatch
  注意watch是在开启事务之前监视,不能在开启事务之后监视

分布式锁
现在有一种情况是,防止对一个数据的重复减少.只是监控是否改变并不能满足业务需求,所以我们需要一个公共的锁.我锁上之后其他人都不能动整个数据.

• 使用setnx设置一个公共锁
  setnx lock-key value
  利用setnx命令的返回值特征,有值则返回设置失败,无值则返回设置成功

  • 对于返回设置成功的,拥有控制权,进行下一步的具体业务操作
  • 对于返回设置失败的,不具有控制权,排队或等待

  操作完毕通过del操作释放锁
  注意:上述解决方案是一种设计概念,依赖规范保障,具有风险性

分布式锁改良
现在又出现一种情况,比如说现在某个客户端加了分布式锁之后,宕机了,由于我们手动添加分布式锁的时候只能自己去解除锁.这里我们就给锁加一个时间限制

• 使用expire为锁key添加时间限定,到时不释放,放弃锁
  expire lock-key second
  pexpire lock-key milliseconds

由于操作通常都是微秒或者毫秒级,因此该锁定时间不宜过大,具体时间需要业务测试后确认

• 例如:持有锁的操作最长执行时间127ms,最短执行时间7ms
• 测试百万次最长执行时间对应命令的最大耗时,测试百万次网络延迟平均耗时
• 锁时间设定推荐:最大耗时120%+平均网络延迟110%
• 如果操作耗时与网络延迟耗时相差较大,取其中单个耗时较长的那个