Redis 事务

一、Redis事务的概念：

Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。
总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

上图说明：
假如现在有两个客户端，对同一条数据进行操作，客户端1set了一条数据，完了之后另外一个客户端2更改了这个数据，但是客户端1去get数据时发现获取的值跟自己set的值不一样，是客户端2set的值
针对这样的问题，提出了redis事务

二、redis事务提出的逻辑：

基于上面的问题，那我在一个客户端操作的时候，把所有的指令一次性按照顺序排他的放在一个队列中，执行完了之后再让其他的客户端操作

三、redis事务的基本操作

• 开启事务

   multi 
  

  作用：设定事务的开启位置，此指令执行后，后续的所有指令均加入到事务中

• 执行事务

  exec 
  

  作用：设定事务的结束位置，同时执行事务。与multi成对出现，成对使用

  注意：加入事务的命令暂时进入到任务队列中，并没有立即执行，只有执行exec命令才开始执行
  

  但是你在命令入队列的时候，发现你有些命令指令输入错误，你不想执行了，这个时候，你不想提交事务了

• 取消事务

  discard
  

  作用：终止当前事务的定义，发生在multi之后，exec之前

  遇到multi指令，创建队列，遇到discard指令销毁队列
  

  若在事务队列中存在命令性错误（类似于java编译性错误），则执行EXEC命令时，所有命令都不会执行
  
  若在事务队列中存在语法性错误（类似于java的1/0的运行时异常），则执行EXEC命令时，其他正确命令会被执行，错误命令抛出异常。
  
  注意：已经执行完毕的命令对应的数据不会自动回滚，需要程序员自己在代码中实现回滚。

四、事务的执行流程

五、redis锁

业务场景
天猫双11热卖过程中，对已经售罄的货物追加补货，4个业务员都有权限进行补货。补货的操作可能是一系 列的操作，牵扯到多个连续操作，如何保障不会重复操作？

业务分析

• 多个客户端有可能同时操作同一组数据，并且该数据一旦被操作修改后，将不适用于继续操作
• 在操作之前锁定要操作的数据，一旦发生变化，终止当前操作

也就是说当有很多个业务员同时对补货key进行操作的时候，我们对这个补货Key进行监控，如果有变动说明有其他的业务员（客户端）已经对补货key这个进行了操作，那么其他人不需要修改，如果没有变动事务执行成功

• 对 key 添加监视锁，在执行exec前如果key发生了变化，终止事务执行

  watch key1 [key2……] 
  

• 取消对所有 key 的监视

  unwatch
  

使用watch检测balance，事务期间balance数据未变动，事务执行成功

使用watch检测balance，在开启事务后（标注1处），在新窗口执行标注2中的操作，更改balance的值，模拟其他客户端在事务执行期间更改watch监控的数据，然后再执行标注1后命令，执行EXEC后，事务未成功执行。

• 一但执行 EXEC 开启事务的执行后，无论事务使用执行成功， WARCH 对变量的监控都将被取消。
• 故当事务执行失败后，需重新执行WATCH命令对变量进行监控，并开启新的事务进行操作。

六、redis分布式锁

业务场景：
还是上面补货的问题，现在业务员现在已经补货完了，商品热卖，3秒内销售一空，怎么避免最后一件商品不被多人同时购买？
如果使用上面的锁机制(watch)，监控这个补货key有没有改变，那是不行的，一旦补货key一变化事务就执行失败，这样的话其他的用户也不能在后面买到，所以这样也是行不通的
虽然redis是单线程的，但是多个客户端对同一数据同时进行操作时，如何避免不被同时修改？

基于这样的问题，提出了redis分布式锁，你加一把锁，每一个用户过来的时候都需要获取这把锁，只有获取这把锁的时候才能操作成功，没有获取锁的话，操作失败。

redis分布式锁的解决方案

• 使用 setnx 设置一个公共锁

  setnx lock-key value 
  

利用setnx命令的返回值特征，有值则返回设置失败，无值则返回设置成功

• 对于返回设置成功的，拥有控制权，进行下一步的具体业务操作
• 对于返回设置失败的，不具有控制权，排队或等待
  操作完毕通过del操作释放锁

但是如果一个用户获取了这把锁一直不释放，那怎么办呢？后面的用户一直等嘛？
解决方案

• 使用 expire 为锁key添加时间限定，到时不释放，放弃锁

   expire lock-key second pexpire lock-key milliseconds 
  

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

• 例如：持有锁的操作最长执行时间127ms，最短执行时间7ms。
• 测试百万次最长执行时间对应命令的最大耗时，测试百万次网络延迟平均耗时
• 锁时间设定推荐：最大耗时120%+平均网络延迟110%
• 如果业务最大耗时<<网络平均延迟，通常为2个数量级，取其中单个耗时较长即可