这就是上面提到的，在事务开始后，用户可以输入事务要执行的呼吁；在呼吁入事务行列前，会对呼吁举办查抄，假如呼吁不存在可能是呼吁参数差池，则会返回错误可客户端，而且修改客户端状态。
当后头客户端执行 EXEC 呼吁时，处事器就会直接拒绝执行此事务了。
所以说，Redis 事务其实是支持原子性的！纵然 Redis 不支持事务回滚机制，可是它会查抄每一个事务中的呼吁是否错误。
可是我们要留意一个点就是：Redis 事务不支持查抄那些措施员本身逻辑错误。譬喻对 String 范例的数据库键执行对 HashMap 范例的操纵！
我很附和 Redis 作者的想法：
首先，MySQL 和 Redis 的定位纷歧样，一个是干系型数据库，一个是 NoSQL。
MySQL 的 SQL 查询是可以相当巨大的，并且 MySQL 没有事务行列这种说法，SQL 真正开始执行才会举办阐明和查抄，MySQL 不行能提前知道下一条 SQL 是否正确。所以支持事务回滚长短常有须要的~
可是，Redis 利用了事务行列来预先将执行呼吁存储起来，而且会对其举办名目查抄的，提前就知道呼吁是否可执行了。所以假如只要有一个呼吁是错误的，那么这个事务是不能执行的。
Redis 作者认为根基只会呈此刻开拓情况的编程错误其实在出产情况根基是不行能呈现的（譬喻对 String 范例的数据库键执行 LPUSH 操纵），所以他以为没须要为了这事务回滚机制而改变 Redis 追求简朴高效的设计主旨。
Linux公社的RSS地点：https://www.linuxidc.com/rssFeed.aspx