Redis:对比一下Redis和MySQL的事务

QAQ。。水稻前两天研究完MySQL的事务,今天看到了Redis,也产生了兴趣。准备下手看看

小白:水稻哥,你在看啥呢,这么专注

水稻:在看Redis的事务,有点收获

小白:真的吗?科普一下呗!

水稻:嗯,从与MySQL的不同点开始说,Redis的事务不支持事务的原子性,事务内的一组操作并不支持异常回滚。这里分为两种情况

  • 语法异常:类比java编译时异常,事务中出现语法错误,譬如set误写成sett等。在提交的时候就能检查出来,整个事务都不会执行
  • 业务异常:类比java的运行时异常,譬如将list的命令操作在string上。命令提交的时候检测不出来,可以正常提交,错误的命令不能执行,其他的命令正常执行,不会回滚

小白:Redis为什么这么豪横

水稻:搜索官方文档可以发现

  • 根本原因可能还是Redis的定位是缓存。不加入回滚逻辑可以使它简洁,快速
  • 官方解释是:运行时的异常不应该发生在生产环境,就是Redis不应为程序员的bug买单
  • Redis可以以脚本的形式支持事务的执行。历史原因,先出现了事务,后出现的脚本。暂时不打算撤销事务的功能,它提供了无脚本也能支持简单事务的功能,但是如果随着后续脚本方案的流行可能会在后续版本移除事务功能

小白:厉害了。我还听说过Discard和Watch命令?能说说吗

水稻:

  • Discard支持在事务内部主动撤销事务,该命令会清空事务队列。
  • Watch命令则是提供一种CAS乐观锁的机制,可以变相的支持事务的隔离性,可以事先监听关注的key,其他事务如果在当前事务执行前修改了监听的key,那么当前事务就会被取消。程序要做的就是监听到失败的结果,然后进行重试。
    • 举个栗子??
    • 第一个客户端 开启事务multi get k1 ,set k2 aaa 
    • 第二个客户端 开启事务multi del k1 , exec  
    • 第一个客户端 提交事务exec , 会发现k2是可以set成功的
    • 如果在第一个客户端开启事务之前监听k1的变化,那么k2是会set失败的

小白:懂了!!懂了

水稻:相互学习!!!  

    

Redis:对比一下Redis和MySQL的事务

上一篇:SpringBoot设置mysql的ssl连接


下一篇:mtsql的操作符