使用Redis命令语法错误，或是将命令运用在错误的数据类型键上(如对字符串进行加减乘除等)，从而导致业务数据有问题，这种情况认为是编程导致的错误，应该在开发过程中解决，避免在生产环境中发生；
由于不用支持回滚功能，Redis内部简单化，而且还比较快；
在事务命令入队过程中，发现相关命令逻辑使用错误，可以进行放弃该事务；如果使用错误的Redis命令，且没有放弃事务，最终也会导致事务整体执行失败，这也算是为原子性扳回一局，如下：
放弃事务
命令语法错误导致事务执行失败
说到乐观锁，就和悲观锁一起简单说说对其的理解：
乐观锁：就是非常乐观，做什么事都往好处想； 对于数据库操作，就认为每次操作数据的时候都认为别的操作不会修改，所以不会加锁，而是通过一个类似于版本的字段来标识该数据是否修改过，在执行本次操作前先判断是否修改过，如果修改过就放弃本次操作重新再来；
悲观锁：就是非常悲观，做什么事都觉得不好；对于数据库操作，每次操作数据数据都会认为别的操作会修改当前数据，说以都要对其进行加锁，类似于表锁和行锁。
WATCH通过监视指定Redis Key，如果没有改变，就执行成功，如果发现对应值发生改变，事务就会执行失败，如下图；
那会一直监视指定的Key吗？，答案当然是不会的，以下三种方式可以取消监视：
事务执行之后，不管是否执行成功还好是失败，都会取消对应的监视；
当监视的客户端断开连接时，也会取消监视；
可以手动UNWATCH取消所有Key的监视；
Redis事务优缺点优点：
一次性按顺序执行多个Redis命令，不受其他客户端命令请求影响；
事务中的命令要么都执行(命令间执行失败互相不影响)，要么都不执行(比如中间有命令语法错误)；
缺点：
事务执行时，不能保证原子性；
命令入队每次都需要和服务器进行交互，增加带宽；
注意
当事务中命令语法使用错误时，最终会导致事务执行不成功，即事务内所有命令都不执行；
当事务中命令知识逻辑错误，就比如给字符串做加减乘除操作时，只能在执行过程中发现错误，这种事务执行中失败的命令不影响其他命令的执行。
总结对于Redis事务，其实用的不是很多，大部分喜欢使用Lua脚本进行批量命令的执行，同时还能保证命令执行的原子性。
那为什么要说Redis事务呢？
在之前计划写这篇文章的时候，和一些朋友简单沟通过，大家的确用的不多，基本上都是用Lua脚本；但面试会时不时遇到过Redis事务的问题，最常见的是Redis中的事务和关系型数据库中的事务有什么区别，这是从面试角度出发有这篇文章；
其实Redis 2.6版本之前，还不支持Lua脚本时，Redis事务对于批量按序执行命令的场景也是很用的；就拿当下来说，如果一些业务需批量按序执行命令的，同样可以使用，并非一定要Lua脚本。这是从使用角度来说；
最后从学习角度来说，既然学Redis，就应该尽可能的了解的多一点。 下一篇说说持久化。
一个被程序搞丑的帅小伙，关注"Code综艺圈"，跟我一起学~~~
