我是Redis的新手，在官方网站上阅读它的交易时，我对一件事感到困惑。
- 显示
要么处理所有的命令，要么不处理，所以Redis事务也是原子的。
即使一个命令失败，队列中的所有其他命令也会被处理-
所以它们是相互对立的，不是吗?
这是关于不同的事情。Redis有管道-客户端可以一次向Redis发送许多命令。管道内部可以批处理事务。当事务失败时，事务中的所有命令都将被丢弃，但在EXEC命令之后的任何流水线(队列)命令无论如何都会被执行。
更多信息请参见http://redis.io/topics/pipelining和http://redis.io/topics/transactions
已处理的命令和失败是有区别的。在SQL中，如果任何命令失败，整个事务将被回滚，就好像它们都没有完成一样。在redis中，一个命令失败不会阻止其他命令的处理或被处理，每个命令都独立地失败或成功。
所以如果你增加一个计数器，然后尝试设置一个不同的键值，它失败了，增加仍然发生，没有回滚。因此所有的命令都被处理，即使一个命令失败。
简单地说，Redis TRANSACTION拥有事务应该具有的任何特性，除了它不能在失败期间回滚。因为redis的作者认为失败中的回滚函数是不必要的，所以失败只能由编程错误引起。
也许我应该告诉你，multi系列命令实现的redis事务不是一个好的选择，因为它是一种过时的功能(作者认为Lua是一个更好的方法，使multi完全没有必要)。使用redis Lua要好得多!
引用自redis作者:
从定义上讲，Redis脚本是事务性的，所以你可以用Redis事务做的所有事情，你也可以用脚本做，通常脚本会更简单更快。这种重复是由于在Redis 2.6中引入了脚本，而事务早就存在了。然而，我们不太可能在短时间内删除对事务的支持，因为从语义上来说，即使不诉诸Redis脚本，仍然可以避免竞争条件，特别是因为Redis事务的实现复杂性是最小的。然而，在不久的将来，我们将看到整个用户群都只使用脚本，这并非不可能。如果发生这种情况，我们可能会弃用并最终删除事务。
你应该好好看看Redis文档的Lua章节。这确实是一个更好和更强大的解决方案，除了需要你了解一些Lua。
如果你想知道更多
我认为redis交易的定义是"自动的"。有点像"线性"
参考https://en.wikipedia.org/wiki/Linearizability
这种瞬间发生或不可分割发生的特性导致使用术语atomic来替代较长的"线性可化"(linearizable)。
在这种情况下，redis确保事务的执行不被其他命令干扰(或不可分割)，并且事务中的命令可以线性地一个接一个地执行。关于redis为什么允许部分事务成功，这应该是一个围绕"回滚"而不是原子性的设计主题。